GNOME Bugzilla – Bug 766422
videoaggregator: rtspsrc ! compositor produces no output
Last modified: 2016-05-20 15:09:51 UTC
It seems that videoaggregator doesn't work if the source if rtspsrc. This seems that it is because the buffers has no duration is the first timestamp isn't running time 0. in particular the running time of the first input buffer is beyond the end time of the first output buffer. Test pipeline: gst-launch-1.0 uridecodebin uri=rtspt://streaming1.osu.edu/media2/ufsap/ufsap.mov ! compositor ! xvimagesink Relevant debug line: 0:00:05.902285075 28417 0x1e0c370 DEBUG videoaggregator gstvideoaggregator.c:1149:gst_videoaggregator_fill_queues:<compositor0:sink_0> buffer duration is -1, start_time >= output_end_running_time. No previous buffer, need more data Patch upcoming.
*** Bug 766420 has been marked as a duplicate of this bug. ***
Created attachment 327862 [details] [review] videoaggregator: Don't wait if input buffer is after output If the input buffer is after the end of the output buffer, then waiting for more data won't help. We will never get an input buffer for this point. This fixes compositing of streams from rtspsrc.
Review of attachment 327862 [details] [review]: ::: gst-libs/gst/video/gstvideoaggregator.c @@ +1148,2 @@ GST_DEBUG_OBJECT (pad, "buffer duration is -1, start_time >= " "output_end_running_time. No previous buffer, need more data"); Perhaps update the trace too ?
Created attachment 327867 [details] [review] videoaggregator: Don't wait if input buffer is after output If the input buffer is after the end of the output buffer, then waiting for more data won't help. We will never get an input buffer for this point. This fixes compositing of streams from rtspsrc.
Review of attachment 327867 [details] [review]: Do we have the same problem in audioaggregator, did you check? ::: gst-libs/gst/video/gstvideoaggregator.c @@ -1148,3 @@ GST_DEBUG_OBJECT (pad, "buffer duration is -1, start_time >= " - "output_end_running_time. No previous buffer, need more data"); - need_more_data = TRUE; The problem here is that now you might aggregate for the current output time without having a buffer for this pad. While the buffer for the current time of this pad might just arrive immediately afterwards and we just didn't get it yet because the late buffer was on the pad first. Maybe this should only happen on timeout?
Audioaggregator is fine This is the case "if (start_time >= output_end_running_time)", so I understand that means that buffer on this pad is entirely after the "end time" of the output buffer, not before, so you won't get an _older_ buffer than the one that is currently on your pad.
Ah so that's when the buffer is after the current time... and we were waiting for more data then instead of just outputting to get closer the that buffer. Go ahead then :)
Merged into master: commit e357e372e17fa5870be8e58a4bd52b512317c693 Author: Olivier Crête <olivier.crete@collabora.com> Date: Sat May 14 11:56:59 2016 +0200 videoaggregator: Don't wait if input buffer is after output If the input buffer is after the end of the output buffer, then waiting for more data won't help. We will never get an input buffer for this point. This fixes compositing of streams from rtspsrc. https://bugzilla.gnome.org/show_bug.cgi?id=766422 and 1.8: commit 7ed830268078f8e0abfac228755d7965bfb01e7b Author: Olivier Crête <olivier.crete@collabora.com> Date: Sat May 14 11:56:59 2016 +0200 videoaggregator: Don't wait if input buffer is after output If the input buffer is after the end of the output buffer, then waiting for more data won't help. We will never get an input buffer for this point. This fixes compositing of streams from rtspsrc. https://bugzilla.gnome.org/show_bug.cgi?id=766422