After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744111 - record two stream from v4l2src simultaneously in one container
record two stream from v4l2src simultaneously in one container
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-06 21:02 UTC by briner
Modified: 2016-03-31 01:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gstreamer pipe not working (603 bytes, application/octet-stream)
2015-02-06 21:02 UTC, briner
Details
gstreamer pipe working with fake source (756 bytes, application/octet-stream)
2015-02-06 21:04 UTC, briner
Details

Description briner 2015-02-06 21:02:46 UTC
Created attachment 296304 [details]
gstreamer pipe not working

Hello,

I'm having trouble to encode two streams (x264enc) into one container(mp4).

If we use videotstsrc as the source everythings works (attachment:briner_fakesrc.pipe)

If we use two webcams as the source, the webcams are not recording together (attachment:briner_2webcams.pipe) :
What I specificaly means by not working is that when the video0 record (image is not frozen) then video1 do not record (image is frozen). It keeps the same for some seconds and then vidoo0 is frozen and video1 is not frozen.

After talking with the mailing list: http://lists.freedesktop.org/archives/gstreamer-devel/2015-January/051225.html
it seems that :
----
Looking again at the logs, search for the "x264enc[01]:sink> calling 
chainfunction" regex and you will see that only one v4l2src is running 
at a time. These are the log entries showing the buffers pushed to the 
x264enc elements, and only one is receiving buffers, which means that 
only one v4l2src element is capturing at a time. Unfortunately this is 
all I could get, you should try debugging it further to understand why 
this is happening.
----

I provided them an output of my pipe with a GST_DEBUG=6 of my pipe and the video. Both are dowloadable from https://mega.co.nz/#F!MwxyzbgR!_woGyEj1-SdViEkOAjeEhw

cED
Comment 1 briner 2015-02-06 21:04:05 UTC
Created attachment 296305 [details]
gstreamer pipe working with fake source
Comment 2 briner 2015-02-06 21:39:57 UTC
oups, I forgot to mention the version of gstreamer used:
gst-inspect-1.0 --version
  # gst-inspect-1.0 version 1.2.4
  # GStreamer 1.2.4
  # https://launchpad.net/distros/ubuntu/+source/gstreamer1.0
Comment 3 Thiago Sousa Santos 2015-02-13 03:25:09 UTC
did you try a newer version? 1.4 or git?

Also, can you check if

gst-launch-1.0 v4l2src ! queue ! videoconvert ! timeoverlay ! videoconvert ! autovideosink v4l2src ! queue ! videoconvert ! timeoverlay ! videoconvert ! autovideosink

To check if they flow at the same time? Remember to set each v4l2src to a different device.
Comment 4 briner 2015-02-18 20:54:24 UTC
hello,

I've tried what you told me: use two streams to see if it flows well. It does work perfectly.

I've tested the following pipes:

gst-launch-1.0 \
  v4l2src device=/dev/video1 \
    ! queue \
    ! videoconvert \
    ! timeoverlay \
    ! videoconvert \
    ! autovideosink \
  v4l2src device=/dev/video2 \
    ! queue \
    ! videoconvert \
    ! timeoverlay \
    ! videoconvert \
    ! autovideosink

and as said, it works.
Comment 5 briner 2015-02-18 21:30:16 UTC
what you ask me to test works, but my pipe still does not work.

cED
Comment 6 Thiago Sousa Santos 2015-03-09 16:53:29 UTC
Did you try putting queues before the encoder?
Can your system encode the 2 streams in realtime?

I can only reproduce the issue here when the CPU gets too busy encoding, causing delays for returning the thread back to capturing.
Comment 7 Nicolas Dufresne (ndufresne) 2016-03-31 01:40:05 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!