GNOME Bugzilla – Bug 796862
Videomixer fails with assert if its sink pad offset is set to negative value and the absolute value of offset is greater than pipeline running time
Last modified: 2018-11-03 15:31:57 UTC
Expected behavior: Setting pad offset to negative value usually results in media stream being "shifted forward" by the amout of offset. Observed behavior: If setting pad offset to negative value which absolute value is greater than the pipeline running time videomixer fails with assert. Pipeline structure: $ gst-launch-1.0 videotestsrc ! videomixer ! ximagesink How to reproduce: Have pipeline running for N seconds then set videomixer's pad offset to -(N+1) seconds (e.g. to skip some video frames). I have an example application which reproduces this problem. Regards, Yury ============================= GStreamer console output: ============================= ERROR:videomixer2.c:961:gst_videomixer2_fill_queues: assertion failed: (start_time != -1 && end_time != -1) ============================= Application backtrace: =============================
+ Trace 238669
An offset is being applied to videomixer's sink pad.
Could you also try with the "compositor" element instead, it replaces videomixer.
Created attachment 373147 [details] Test application pipeline I’m running
I’ve drop-in replaced ‘videomixer’ with ‘compositor’. The problem persists. Please see test application pipeline I’m running (testapp_pipeline.png, attachment 373147 [details]). ============================= GStreamer console output: ============================= ERROR:gstvideoaggregator.c:1192:gst_video_aggregator_fill_queues: assertion failed: (start_time != -1 && end_time != -1) ============================= Application backtrace: =============================
+ Trace 238670
More information on what I’m trying to achieve. The application is processing several video streams in parallel (reading VP8 video from rtp stream files). All streams get decoded then routed to ‘videomixer’ (or ‘compositor’ as Tim-Philipp Müller suggested) to create single video stream with grid-like layout, each video in separate grid cell (position). At some point at pipeline playback there is application-level (out-of-band) ‘pause’ event of arbitrary duration. This event signifies that some portion of media has to be skipped. To implement the pause I update all ‘videomixer’ (or ‘compositor’) sink pads offset to negative value abs()-equal to the ‘pause’ duration. This (from my understanding) commands ‘videomixer’ to discard some video frames treating those being ‘late’. If pause happens to occur early in pipeline playback and pause duration is longer than current pipeline running time then ‘videomixer’ (and ‘compositor’) element does an assert as described above. Can you please hint me if the approach ‘pause’ handling I’m implementing is a reasonable one? (The ‘videotestsrc->‘videomixer’ (compositor)->’ximagesink’ pipeline above is a simplified pipeline to demonstrate the problem I face.)
>> if the approach ‘pause’ handling I’m implementing is a reasonable one In other words, is this a proper (correct) use of videomixer's pad offset? Are there any limitations on sink pad offset values (both positive and negative) besides (1) possibility of int64_t overflow and (2) application-specific validity of buffer timesetamp values?
I didn't look at the details here, but whatever you set as pad offset should never ever cause assertions anywhere. If anything it should cleanly error out, but here it should actually just work if I understand correctly what you're doing. What should happen is that all values before the pipeline running time are simply dropped/clipped (they're in the past after all).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/492.