[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Sasi Inguva]

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.buitenhuis at gmail.com> wrote:

> On 11/14/2017 2:15 AM, Sasi Inguva wrote:
> > Signed-off-by: Sasi Inguva <isasi at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>