[FFmpeg-devel] [PATCH 2/3] ffmpeg: use new decode API

[wm4]

On Thu, 29 Sep 2016 23:35:49 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Sep 29, 2016 at 08:25:18PM +0200, wm4 wrote:
> > This is a bit messy, mainly due to timestamp handling.
> > 
> > decode_video() relied on the fact that it could set dts on a flush/drain
> > packet. This is not possible with the old API, and won't be. (I think
> > doing this was very questionable with the old API. Flush packets should
> > not contain any information; they just cause a FIFO to be emptied.) This
> > is replaced with checking the best_effort_timestamp for AV_NOPTS_VALUE,
> > and using the suggested DTS in the drain case.
> > 
> > The fate-cavs test still fails due to dropping the last frame. This
> > happens because the timestamp of the last frame goes backwards
> > (ffprobe -show_frames shows the same thing). I suspect that this
> > "worked" due to the best effort timestamp logic picking the DTS
> > over the decreasing PTS. Since this logic is in libavcodec (where
> > it probably shouldn't be), this can't be easily fixed. The timestamps
> > of the cavs samples are weird anyway, so I chose not to fix it.
> > 
> > Another strange thing is the timestamp handling in the video path of
> > process_input_packet (after the decode_video() call). It looks like
> > the code to increase next_dts and next_pts should be run every time
> > a frame is decoded - but it's needed even if output is skipped.
> > ---
> >  ffmpeg.c            | 178 +++++++++++++++++++++++++++++++++++++---------------
> >  ffmpeg.h            |   3 +
> >  tests/ref/fate/cavs |   1 -
> >  3 files changed, 129 insertions(+), 53 deletions(-)  
> 
> with this and patch 1/3
> the following infinite loops
> ./ffmpeg  -f openal -i ''  -t 0.1 file.wav
> 

Give me a way to reproduce without OpenAL or anything libavdevice. I
feel like I suffered enough already for this shit.