GNOME Bugzilla – Bug 795561
Playbin3 pipeline is pending during prerolling
Last modified: 2018-11-03 12:06:20 UTC
Dear All Playbin3 pipeline is pending during trick play (flush seeking) with -2x. All buffers come to decoder but, it is not pushed out to downstream even if EOS comes. And pipeline does not complete preroll state (seek-done). I think below commit affects this symptom. ==> ce65017 decodebin3/urisourcebin: Switch to actual EOS events internally
Created attachment 371410 [details] [review] decodebin3: Send GAP event to downstream when it is not in ALL EOS state
Dear All To avoid this symptom, send GAP event to decoder. Please review may patch. Thanks.
Do you have a test file that could reproduce this ? Or it happens with all sources/files ?
Created attachment 372256 [details] Test Stream
Created attachment 372257 [details] Test Stream 2
Created attachment 372258 [details] Test Stream 3
Created attachment 372259 [details] Test Stream 4
Created attachment 372260 [details] Test Stream 5
Created attachment 372261 [details] Test Stream 6
(In reply to Edward Hervey from comment #3) > Do you have a test file that could reproduce this ? Or it happens with all > sources/files ? Hello Edward Hervery Please attached test streams. They are played without video in VLC and GStreamer v1.12. I mean below patch is merged before. ==> ce65017 decodebin3/urisourcebin: Switch to actual EOS events internally Thanks.
Created attachment 372262 [details] [review] playbin3: Send GAP event to finish preroll when playsink is in asynchronous state
Hello Edward Hervery It is not easy to detect when async-done should be finished for initial load, pause/resume, seek and trick. This patch is temporary and to send gap event when async-start/done can not be finished under 250 ms. Thanks.
All those files you provided have MPEG-4 Video, and that seems to be the root cause. mpeg4videoparse never seems to get a proper config, and therefore drops everything without pushing anything. I would much prefer we detect (and fix) such root cause issues instead of adding workarounds in decodebin3 (which as you realized isn't easy either :D ). We definitely shouldn't hang like this. What should happen is that mpeg4videoparse (or baseparse) should detect that it isn't producing data and pushing GAP events downstream which ... then brings us to the other baseparse bug : https://bugzilla.gnome.org/show_bug.cgi?id=791584
-- 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-base/issues/444.