[FFmpeg-devel] [PATCH] ffmpeg: remove unused and errorneous AVFrame timestamp check

[Hendrik Leppkes]

On Tue, Oct 4, 2016 at 8:41 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
>> On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik Leppkes wrote:
>>> Decoders have previously not used AVFrame.pts, and with the upcoming
>>> deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
>>> interpration of timestamps.
>>
>> I probably misunderstand the commit message but
>> If code is changed in a user application that cannot really lift
>> some blockage from changing a lib.
>> a lib can only change in an incompaible way with (deprecation and)
>> major version bump.
>>
>
> The lib never did what this code suggests it did, not that I remember
> (so at least not for a long long time).
>

Of course that could still mean that some other apps "copied" the
ffmpeg code and try to read this field - but is this a scenario we can
really control?

The pts field in AVFrame is currently unused for decoding, nothing
sets it (except cuvid and openh264 or so, but those set it the same
way it would be set in the future, so no changes there), ffmpeg.c
trying to read it is a remnant from a long time ago (quick blame pins
it at 2012 when decoding was changed to decode_audio4).
I couldn't actually confirm if at that time (audio) decoders did even
set AVFrame.pts, considering pkt_pts already existed then.

So is starting to set a field that was previously (at least through 2
or so major bumps) unused a API break?
Its always possible some app still tries to read it, but because its
never set it didn't cause any problems so far.

The alternative is of course to keep using pkt_pts, and keep pts
unused for decoding, but I'm not entirely convinced there is a break
here.

- Hendrik