GNOME Bugzilla – Bug 760513
baseparse: Need push remaining data in adapter when switching to pass through mode
Last modified: 2018-11-03 12:31:59 UTC
When we are trying to play some h264/avi streams, with our own parser plugin linked with h264parse and then avdec_h264, there will be some corrupt video be observed. while using avidemux link with h264parse, it plays well. After doing some investigation. - avdec_h264 only support alignment au format. - and avidemux output caps not specify the alignment as "au" So h264parse will do the parse to convert alignment to "au" - however, when using our own parser plugin, the output plugins already set the video as alignment "au", so that h264parse work in pass through mode. But it seems the h264parse's output lost the sps/pps data in the begging, which cause the video decoding error for some frames. So it maybe bugs in h264parse pass through mode, suppose in pass through mode, the output should be the same as when h246parse not linked in the pipeline. I'm not sure if this issue has been raised before, so I recorded the issue here Thanks a lot ~
Created attachment 319081 [details] [review] the patch for gstbase to fix missing buffer when switch to pass through mode
further checking the pass through mode in h264parse. It seems the root cause of above issue is that: previously h264parse set passthrough flag at the negotiate in the set_caps (if input format and alignment match negotiated output). but there is a commit e8908f5aeef952566f6bccde743c7735d3f8c6ef , to set passthrough until at least one keyframe has been parsed (in case the stream contains SEI messages that supplement the output caps - for example by providing stereoscopic information). That means the passthrough flag will be set not in the first buffer, and if the passthough flag is not set, the chain in buffer in gstbaseparse will be pushed into adapter, however, when it switches to passthrough mode, there are still data in the adapter which are not pushed to downstream. And there will be no chance to push the remaining data in adapter in pass through mode ever after. Resolution: In pass through mode , should check the adapter and if there still remaining data, need push them to downstream. Please see attache patch for the fix. Thanks Lyon
This seems plausible. I'd love to have a test case for this, e.g. some input data from your other element in form of gdppay ! filesink. I wonder if we should do this at the moment we're deciding to switch to passthrough mode instead of doing it in the chain function. You can use gst_adapter_take_buffer() by the way, then _clear() is not needed.
Created attachment 339780 [details] gdppay of our demux output Hi, Tim Please see attached file for the test case Using the command line below to get the output: gst-launch-1.0 filesrc location=H264_BP40_640x480_25_1657_NoAudio.avi ! 'video/x-msvideo' ! aiurdemux ! 'video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)byte-stream, width=(int)640, height=(int)480, framerate=(fraction)25/1' ! gdppay ! filesink location=./gdppay_aiur_out.dat
(In reply to Tim-Philipp Müller from comment #3) > This seems plausible. I'd love to have a test case for this, e.g. some input > data from your other element in form of gdppay ! filesink. > > I wonder if we should do this at the moment we're deciding to switch to > passthrough mode instead of doing it in the chain function. do you mean do this in the videoparser when set_passthrough(), then will it be easier for handle it in baseparse than in the videoparse subclass (coz there maybe several parsers need to be modifier?) > You can use gst_adapter_take_buffer() by the way, then _clear() is not > needed.
-- 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/gstreamer/issues/149.