Stop using deprecated pkt_pts

[jlaine]

Only use frame.pts, frame.pkt_pts is obsolete.

Also stop detecting the presence of av_frame_get_best_effort_timestamp,
it's guaranteed to be present now that we require ffmpeg >= 3.0. Not
that we use it anyway..

[jlaine]

OK looks like I got carried away, this broke ffmpeg 3.0 support

[mikeboers]

So, you want to drop 3.0 support? 😉

3.0 was Feb. 2016. <- this does not work.
3.1 was Jun. 2016.
3.2 was Nov. 2016. <- this works.

[mikeboers]

We could also detect what version of FFmpeg we're building against, and leave out that part if > 3.0.

I'd love if we could get to something that is ABI compatible with everything we support, so it could survive an upgrade to FFmpeg, you know?

[jlaine]

3.0 and 3.1 seem like somewhat unpolished releases in terms of API, it looks like a raft of deprecations landed in 3.2.. I'm starting to wonder what the sane baseline is.

To review where we stand, the recent switch to ffmpeg >= 3.0 means:

• the Ubuntu LTS we support "out of the box" is Ubuntu 18.04 which has ffmpeg 3.4. Ubuntu 17.10 is also fine as it has ffmpeg 3.3.

• the Debian release we support is stretch which carries ffmpeg 3.2.

In short, it would seem that maintaining 3.0 / 3.1 support doesn't really broaden our reach..

[mikeboers]

Unfortunately, my largest client has a lot of stuff on CentOS 7, which appears to be ffmpeg 3.1.2.

[jlaine]

OK, then would ffmpeg 3.1 be acceptable? It would seem that's the version that introduced AVCodecParameters which seems to be the preferred alternative to passing AVCodecContext around:

https://www.ffmpeg.org/doxygen/3.1/structAVCodecParameters.html

[mikeboers]

I'm currently knee deep in a build problem at aforementioned large client. I'm likely going to be rebuilding FFmpeg at the 4.0 level.

So, 3.2 is acceptable for me personally.

My earlier comment about 3.1 for CentOS may be in error. I can't even find it in the repos on these machines. Likely because I don't know what I'm doing...

[mikeboers]

I'm now on 4.0 on my workstation, and the render farm of my large client.

My home server is 3.4.4, and that is installed via default sources on Ubuntu 18.

Shall we just call 3.2? I mean... None of us are really paid for supporting this at all, so supporting a nearly 2-year old FFmpeg seems just fine to me.

[mikeboers]

Debian Stretch is 3.2, and Debian Buster will be 4.0.

[jlaine]

I'm perfectly fine with setting 3.2 as the baseline, it allows for a number of cleanups. Maybe push out a 0.5.4 version before we make the break?

If we are reshuffling the CI setup I would suggest dropping 3.3 and instead testing 3.2 / 3.4 / 4.0 across our supported pythons.

[mikeboers]

Why drop 3.3? It is still listed at https://ffmpeg.org/