For H264 files with no bitstream restriction flag, we aren't able to guess the delay correctly. Especially if it's MOV container, because for MOV container we just probe the 1st frame and stop in avformat_find_streaminfo .
When we are decoding , we increase the has_b_frames value from zero to 1 or 2, when we eventually encounter B-frames in H264 decoder, but that is too late and we have already dropped 1 or 2 frames. Lot of other fields in codecpar are being set from the demuxer like channel_layout, sample_rate etc. On Tue, Nov 14, 2017 at 10:06 AM, Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > On 11/14/2017 2:15 AM, Sasi Inguva wrote: > > Signed-off-by: Sasi Inguva <is...@google.com> > > --- > > libavformat/mov.c | 48 ++++++++++++++++++++++++++++++ > ++++++++++ > > tests/fate/mov.mak | 5 +++++ > > tests/ref/fate/mov-guess-delay-1 | 3 +++ > > tests/ref/fate/mov-guess-delay-2 | 3 +++ > > 4 files changed, 59 insertions(+) > > create mode 100644 tests/ref/fate/mov-guess-delay-1 > > create mode 100644 tests/ref/fate/mov-guess-delay-2 > > Going to play the part of wm4 here. > > This seems like one giant hack to me (and potentially yet more slowness > during init/index). > > Should we *really* be populating codecpar with a heuristic guess and > should we *really* be putting this in one specific demuxer? > > Seems pretty gross to me. > > - Derek > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
