qtav usage of libav

[Gilles Caulier]

Le dim. 18 sept. 2022 à 17:51, Steven Robbins <steve at sumost.ca> a écrit :
>
> On Sunday, September 18, 2022 10:33:16 A.M. CDT Gilles Caulier wrote:
> > Not really. But as ffmpeg API has changed between 4 and 5, and as QtAV
> > API is mostly a wrapper around ffmpeg, this can be relevant.
> >
> > Remember that AV* classes from QtAV are based historically on libav,
> > and now, in fact ffmpeg, as libav is a dead project.
>
> You mean libav as in https://libav.org/ ?
> I wasn't aware of that.
>
> > When I reviewed QtAV code for digiKam integration I saw a lot of
> > pre-compiler wrapping between libav and ffmpeg API, for regression
> > compatibility. Typically code must continue to compile with all libav
> > API, but in fact we don't care.
>
> So are you saying that it is OK to remove libav compatibility code now?

Well typically, yes, as we only use ffmpeg only for now. But if you
look in pre compiler rules, it's a huge puzzle.

Look all the comments from this file for ex :
https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/video/qtav/ffmpeg/AVCompat.h

This is the main header where switch from libav and ffmpeg API are
hardcoded, to be sure that both work fine divergent API... Good luck
to not break something and run-time...

This is why i don't touch it for the moment, until ffmpeg 5 port will
be validated.

>
> To be clear: I'm NOT planning any such thing at present.  Right now I'm
> focused on writing tests that expose the bugs (with ffmpeg5), then fixing them.
> But, hypothetically, if I get through all that ... would it be of interest to
> remove unused code in qtav?

yes, sure this thi the goal for the long time... But be careful of the
regression tests...

Gilles