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

[wm4]

On Fri, 30 Sep 2016 11:12:31 +0200 (CEST)
Marton Balint <cus at passwd.hu> wrote:

> On Fri, 30 Sep 2016, wm4 wrote:
> 
> > 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  
> >
> > Not a reasonably to reproduce test case as it requires installing
> > OpenAL and possibly has specific hardware requirements.
> >
> > Will push this patch in 24 hours unless other problems are pointed out.  
> 
> This seems like a very simple to fix bug in openal.
> 
> I will send a patch series soon.

Thanks, it's appreciated + I will review it.