GNOME Bugzilla – Bug 769521
rtspmedia unit test failure: 'gst_rtsp_media_n_streams (media) == 2' failed
Last modified: 2017-11-21 07:53:53 UTC
Running suite(s): rtspmedia 85%: Checks: 7, Failures: 1, Errors: 0 gst/media.c:434:F:general:test_media_multidyn_prepare:0: Assertion 'gst_rtsp_media_n_streams (media) == 2' failed The test doesn't fail every time. The best way to reproduce is launch as 'make gst/media.forever'.
I was able to reproduce this with git master, but it took about 10-15 minutes of .forever for me to fail. Haven't been able to get it to fail with GST_DEBUG debug logging enabled yet, you?
Created attachment 333065 [details] log of another error 1 (In reply to Tim-Philipp Müller from comment #1) > I was able to reproduce this with git master, but it took about 10-15 > minutes of .forever for me to fail. Haven't been able to get it to fail with > GST_DEBUG debug logging enabled yet, you? No, I haven't, but when I tried I got: 85%: Checks: 7, Failures: 1, Errors: 0 gstcheck.c:79:F:general:test_media_dyn_prepare:0: Unexpected critical/warning: adding flushing pad 'src_1' to running element 'tee3', you need to use gst_pad_set_active(pad,TRUE) before adding it. and 85%: Checks: 7, Failures: 1, Errors: 0 gst/media.c:76:F:general:test_launch:0: Assertion 'g_str_equal (str, "npt=5-")' failed logs in attachment
Created attachment 333066 [details] log 2
still happens on master.
Essentially it's a race between: * payloaders adding their dynamic pads * pipeline being prerolled If the pipeline is prerolled, "new" pads will be ignored (and streams won't be created). The pipeline manages to preroll because the moment *any* payloader emits no-more-pads ... it removes the fakesink and causes the pipeline to preroll. Maybe we should wait for *all* dynamic elements to have posted no-more-pads before doing that ?
Sounds reasonable
Created attachment 364030 [details] [review] rtsp-media: Handle multiple dynamic elements If we have more than one dynamic payloader in the pipeline, we need to wait until the *last* one emits 'no-more-pads' before switching to PREPARED. Failure to do so would result in a race where some of the streams wouldn't properly be prepared
Comment on attachment 364030 [details] [review] rtsp-media: Handle multiple dynamic elements commit 2386e91c3642f3a83de6a74c981e0b9ac85a3dd1 (HEAD -> master, origin/master, origin/HEAD) Author: Edward Hervey <edward@centricular.com> Date: Mon Nov 20 09:32:07 2017 +0100 rtsp-media: Handle multiple dynamic elements If we have more than one dynamic payloader in the pipeline, we need to wait until the *last* one emits 'no-more-pads' before switching to PREPARED. Failure to do so would result in a race where some of the streams wouldn't properly be prepared https://bugzilla.gnome.org/show_bug.cgi?id=769521
And backported to 1.12 also.
Too good to be true, it still fails sometimes.
Created attachment 364063 [details] [review] rtsp-media: Don't unblock with remaining dynamic payloaders If we still have some dynamic paylaoders which haven't posted no-more-pads yet, don't go to PREPARED if one of the streams blocked. The risk was that we would end up not exposing/using all specified streams. The downside is that if you have _multiple_ _live_ _dynamic_ payloaders then it will take a bit more time to start. But only if those 3 conditions are present.
Review of attachment 364063 [details] [review]: lgtm
Comment on attachment 364063 [details] [review] rtsp-media: Don't unblock with remaining dynamic payloaders commit 6371f2fc294ef427351a470532c27bfe2caa9acb (HEAD -> master, origin/master, origin/HEAD) Author: Edward Hervey <bilboed@bilboed.com> Date: Mon Nov 20 18:30:19 2017 +0100 rtsp-media: Don't unblock with remaining dynamic payloaders If we still have some dynamic paylaoders which haven't posted no-more-pads yet, don't go to PREPARED if one of the streams blocked. The risk was that we would end up not exposing/using all specified streams. The downside is that if you have _multiple_ _live_ _dynamic_ payloaders then it will take a bit more time to start. But only if those 3 conditions are present. https://bugzilla.gnome.org/show_bug.cgi?id=769521