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

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160929/f025373d/attachment.sig>