[Pkg-kde-extras] Bug#807853: k3b: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: forwarded -1 https://git.reviewboard.kde.org/r/122569

Hi Pino,

On 09.01.2016 01:33, Pino Toscano wrote:
> In data venerdì 8 gennaio 2016 21:50:33, Andreas Cadhalpun ha scritto:
>> Could you please post links to upstream discussion about this or mark
>> the bug as forwarded?
> 
> I saw these two patches:

Thanks, marking the bug as forwarded accordingly.

> https://git.reviewboard.kde.org/r/122569/

I can confirm that this patch fixes compilation with current FFmpeg git.
But it's slightly wrong:
ifdef HAVE_FFMPEG_AVCODEC_DECODE_AUDIO4
#  if LIBAVCODEC_BUILD < AV_VERSION_INT(55,28,1)
    av_free(d->frame);

Since libavcodec 54.28.0 this should be av_frame_free(&d->frame).
Otherwise it can leak memory.

#  else
    av_frame_free(&d->frame);
#  endif
#endif

> https://git.reviewboard.kde.org/r/122601/

This one is trivially correct and also part of the above one.

If you want to avoid having this problem again next year (or the year after
that), you also need to replace the newly deprecated av_free_packet with
av_packet_unref, which is available since libavcodec 55.25.100 / 55.16.0:
--- k3b-2.0.3a.orig/plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp
+++ k3b-2.0.3a/plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp
@@ -378,7 +378,11 @@ int K3bFFMpegFile::fillOutputBuffer()
 #endif
 
         if( d->packetSize <= 0 || len < 0 )
+#if LIBAVCODEC_VERSION_MAJOR >= 56
+            ::av_packet_unref( &d->packet );
+#else
             ::av_free_packet( &d->packet );
+#endif
         if( len < 0 ) {
             kDebug() << "(K3bFFMpegFile) decoding failed for " << m_filename;
             return -1;

Anyway, do you know how to runtime test this code path?

> they refer to the master branch of k3b, but the code in
> plugins/decoder/ffmpeg/ is the same in both the 2.0 branch (from where
> the 2.0.x releases like the latest 2.0.3a are taken) and master.
> Would it be possible for you to check them, and maybe also comment on
> the reviewboard?

I'm no KDE developer, so I don't have a login on that review board.

>>> Let me take this opportunity to "reverse the issue": is your upstream
>>> aware that the continuous API breaks in each new stable series only
>>> waste time on the users' side?
>>
>> I sense frustration in these words, but let's get the facts straight:
>>  * The last four stable series (2.5.*-2.8.*) didn't break the API.
> 
> Possibly, but IIRC only 2.7 was used back in Debian, so what 2.5 and 2.6
> did is generally not relevant for me. Before it was libav, yes, but from
> a Debian maintainer POV it was "whatever provided libav* libraries".

I just wanted to be exact here. And it's still mainly Libav were the
deprecations (and the nice new APIs) come from, which get merged into FFmpeg.
The difference here is that FFmpeg has more stable releases. ;)
You could have said "API breaks once a year" and would have been mostly
correct. [1]

>>  * Adapting to the new APIs is no waste of time, rather maintenance cost,
>>    also improving the API using program in the process, as the old APIs
>>    were deprecated for a reason.
> 
> The ffmpeg decoding plugin in k3b is doing the same job for the latest
> 6+ years, so at least to me all these API changes look like they brought
> nothing.

Maybe, but e.g. an mpv developer will see this quite differently.

> And well, changing the code to newer APIs that don't bring
> anything new to what was already done is a cost that, as developer, I'd
> rather not pay.

Well, tell that e.g. the Qt/Gtk developers, or try your luck with the LLVM
developers, who like to gratuitously move headers around every half
a year...
At least FFmpeg has a reasonable deprecation period (usually > 2 years).
Keeping all old API forever is just not feasible for many important
libraries.

And while we're at that, someone should probably fix all those deprecation
warnings coming from Qt...

> There is not an active k3b upstream,

That's the real problem, I'm afraid.
Seriously, the patches on the review board are almost a year old...

But why is k3b not developed anymore?
Are there better alternatives?

> so I'm afraid the new ffmpeg
> support code should be as much as conservative as possible (that is,
> support the new version but keep supporting older ones as done now).

I don't see what that has to do with having no active upstream.

What are the oldest libavcodec/libavformat versions used for compiling this?

Or are you seriously claiming anyone still uses this code with a libavformat
version from before 2005?
(I'm referring to LIBAVFORMAT_BUILD < 4629.)

Best regards,
Andreas


1: http://abi-laboratory.pro/tracker/timeline/ffmpeg/