GNOME Bugzilla – Bug 768125
baseparse: Provide a way to skip (filler) data without causing a DISCONT
Last modified: 2016-10-20 09:43:10 UTC
This can be reproduced by just playing back the file or running the validate.file.playback.change_state_intensive.GH1_00094_1920x1280_MTS validate test We get plenty of "illegal short term buffer state detected" errors from ffmpeg This seems to be because the output of h264parse is not valid and changed at some point. Will try to run some regression tests later to figure out where it comes from.
* With a full origin/1.6 checkout of all modules, the problem doesn't appear. * With a origin/master checkout of all modules except for -bad (origin/1.6), the problem does appear The problem might actually be in baseparse.
The commit that "introduced" the issue is in base: commit eb1ebf226ff8c29ea976169f81135219f1ab412b Author: Edward Hervey <edward@centricular.com> Date: Sat Jun 4 09:49:00 2016 +0200 videodecoder: Drain decoder on DISCONT buffers This is actually triggered because the original h264 stream contains strings of extra zero bytes at various places, which causes baseparse to mark the following buffer as DISCONT... and it does that between the various header buffers and the first keyframe :(
Panasonic AVC-I? :) We should skip those (invalid!) zero bytes in h264parse without introducing disconts
An alternative would be to take those filler bytes and finish a drop-able frame. That would circumvent the issues afaics.
That would also possibly solve bug #764372 ;) But see there for why we currently drop the padding.
One way forward would be to add a GstBaseParseFrameFlags ex :GST_BASE_PARSE_FRAME_FLAG_FILLER_DATA If the handle_frame implementation returns a non-zero skipsize and that flag is set, then the discont flag is not set.
Without changing vfuncs (aka adding new ones), this seems like the best approach. However it does not allow for skipping filler and non-filler data at the same time, but that should be done different anyway probably. This flag would only have an effect when finishing a frame, right? Not when skipping without?
Created attachment 330602 [details] [review] h264parse: Drop filler data When skipping data, check if they are filler bytes. If so, drop the data instead of skipping. We don't want to output filler bytes, but they shouldn't cause a discontinuity.
Comment on attachment 330602 [details] [review] h264parse: Drop filler data commit c19d1b46c36ee0e8f8cfcb03b026e8997d70c1c4 Author: Edward Hervey <edward@centricular.com> Date: Wed Jun 29 18:36:56 2016 +0200 h264parse: Drop filler data When skipping data, check if they are filler bytes. If so, drop the data instead of skipping. We don't want to output filler bytes, but they shouldn't cause a discontinuity. https://bugzilla.gnome.org/show_bug.cgi?id=768125