GNOME Bugzilla – Bug 745409
h264parse: broken output when caps change and stream-format=byte-stream
Last modified: 2015-03-04 11:13:30 UTC
I am not sure what is causing problems here. It may be h264parse, or baseparse. I have a source that produces packetized h264 data, with caps "video/x-h264, stream-format=byte-stream, alignment=au, width=.., height=..". When the video quality (adaptive streaming) changes, and I send new caps, then some frames will be broken. If I do not include width & height in the caps, so the quality change does not result in new caps, then playback goes smoothly. I have engineered a gst-launch pipeline that allows reproducing this problem: gst-launch-1.0 souphttpsrc location=http://www.digitalprimates.net/dash/streams/gpac/mp4-main-multi-mpd-AV-NBS.mpd ! dashdemux bandwidth-usage=0.3 ! queue2 ! qtdemux ! h264parse ! video/x-h264, stream-format=byte-stream, alignment=au ! h264parse ! avdec_h264 ! queue2 ! autovideosink The explanation of the test pipeline: - dashdemux bandwidth-usage=0.3 - I noticed that this bug reproduces on given content easily when the quality is changed to 720p. I use bandwidth-usage to make quality not to switch automatically to 1080p after first segment. - h264parse ! video/x-h264, stream-format=byte-stream, alignment=au ! h264parse - the first parser and capsfilter is only required in order to make the (second) h264parse to obtain data in stream-format=byte-stream. This is required. If I do not enforce byte-stream format, this bug does not reproduce. If I enforce byte-stream, but remove the second h264parse, this bug does not reproduce. So I guess that the h264parse with byte-stream input is a source of the bug. In order to reproduce, please run my pipeline. The video has hardcoded information about quality- if you see that it switched though 360p, 720p and 1080p without artifacts, then restart. You should see artifacts when switching to 720p, and when switching from 720p to 1080p. If the playback switches instantly to 1080p, without going through the intermediate qualities, maybe fiddling with bandwidth-usage property on dashdemux will be helpful.
Created attachment 298254 [details] The screenshot of the artifacts I attach the screenshot. It always looks like bad scaling of the frame, green bars and green noise below the badly scaled video.
Sometimes it also causes crash, when switching to 1080p quality: Caught SIGSEGV
+ Trace 234760
And to make everything very clear, my autovideosink plugs in xvimagesink, though the artifacts can be reproduced with any sink (cluttersink seems to freeze sometimes during quality switch though).
Created attachment 298440 [details] [review] h264parse: reset the parser information when caps changes This prevents it from going into passthrough after receiving 2 byte-stream caps (different ones) as it would keep the have_pps and have_sps set to true and would just go into passthrough without updating its caps. This patch makes it reset its stream information to restart properly when new caps are received.
Comment on attachment 298440 [details] [review] h264parse: reset the parser information when caps changes Shouldn't it reset more than just the streaminfo if caps are changing? Otherwise seems to make sense
Created attachment 298452 [details] [review] h264parse: reset the parser information when caps changes Updated to reset all data related to the stream format, only timestamping data is kept when a new caps is received
I confirm that the latest patch fixes my original problem, as well as the testcase pipeline that I posted. Will this patch be merged to GStreamer 1.6?
Thanks for the review and confirmations, the fix will be available in the next releases (1.5 and 1.6). I couldn't reproduce your crash, please reopen or file a new bug if it still crashes. commit 14f6fcdbd89f1934700b26f3e3afa54c654cbabb Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Tue Mar 3 11:42:09 2015 -0300 h264parse: reset the parser information when caps changes This prevents it from going into passthrough after receiving 2 byte-stream caps (different ones) as it would keep the have_pps and have_sps set to true and would just go into passthrough without updating its caps. This patch makes it reset its stream information to restart properly when new caps are received. https://bugzilla.gnome.org/show_bug.cgi?id=745409
I couldn't reproduce the crash with the fix. Though the crash was not reproducing on my original testcase (my custom player), was reproducing only on the xvimagesink test pipeline, was not reproducing on cluttersink, and was probably very tightly related to the artifacts. Although the callstack didn't suggest the sink, I suppose it was sink-specific and had the same root cause as the artifacts.