ffmpeg/avconv bitstream filter options

[dinkypumpkin]

On 17/04/2012 18:31, Jon Davies wrote:
> I had a bug report relating to the ubuntu precise builds I've put
> together, the relevant bit of which is as follows:
>
> avconv version 0.8.1-4:0.8.1-0ubuntu1, Copyright (c) 2000-2011 the Libav
> developers
>   built on Mar 22 2012 05:29:10 with gcc 4.6.3
> Input #0, aac, from
> '/home/mark/Podcasts/Saturday_Drama/Saturday_Drama_-_Mountain_of_Light_b00sqgdw_default.partial.aac':
>   Duration: 01:01:35.85, bitrate: 131 kb/s
>     Stream #0.0: Audio: aac, 44100 Hz, stereo, s16, 131 kb/s
> Unrecognized option 'absf'
> Failed to set value 'aac_adtstoasc' for option 'absf'
> INFO: Command exit code 1 (raw code = 256)

I checked this Libav version on Debian Wheezy, and it works as before if 
avconv is invoked as "ffmpeg" (there is a wrapper installed).  If 
invoked directly as "avconv", you get the warning above.  I don't have 
Ubuntu Precise to hand at the moment, but I would expect it to work the 
same. If you can confirm this behaviour, would it work for the PPA build 
to call ffmpeg rather avconv, at least for the initial release?

> it appears that recent versions of both ffmpeg and avconv have changed
> the options for applying bitstream filters  (see
> http://ffmpeg.org/ffmpeg.html#toc-Bitstream-Filters).

That change has been around for a while, but up until now backwards 
compatibility has been maintained.  This glitch happened last year with 
the "original" FFmpeg, but backwards compatibility was quickly restored. 
  As of the last release (0.10.2), it still works as before (I think 
-absf is just converted to -bsf:a internally).

> For ubuntu precise, due out in a matter of days, I'm going to have to
> change get_iplayer to support the new option formats, the question
> that arises is whether we should
> (a) change get_iplayer to support a more recent version of
> ffmpeg/avconv universally and drag windows, mac and older linux users
> into the new world, together with newer builds of the tools
> (b) treat this as a special case for ubuntu precise for now
> or
> (c) make it possible to support both the old and new option formats
> adding yet another option to get_iplayer to set this
>
> any thoughts?
> Jon

If the above suggestion doesn't work for you and you need to change 
get_iplayer, then I would say treat it as a special case for now.  This 
is only a problem with the Libav fork, and only in their latest release 
0.8.1, and thus is only an issue for Wheezy/Precise, and then only if 
you want to call "avconv".  Before I get too far out on that limb: have 
other distros besides Debian/Ubuntu adopted Libav?

Since this breaking change has been pushed out in a release on a popular 
platform, get_iplayer will probably need to adapt eventually.  Even if 
the "ffmpeg" wrapper  provides a solution for Wheezy/Precise, it will 
eventually disappear.  Besides, the original FFmpeg may ditch the old 
syntax at some point.

Since time is short, perhaps you could just branch get_iplayer and make 
the minimum changes required for Precise.  We can go back and reconcile 
at a later date.  I think we could lose the two-pass ffmpeg entirely 
(see below), but that seems like too much to bite off in the week or so 
before Precise is launched, as would trying to do an across-the-board 
upgrade of get_iplayer and tools.

Before changing get_iplayer, perhaps the place to start is to determine 
whether or not that filter is even necessary.  It was put in to get 
around a problem with iTunes, but I recently checked that very thing in 
response to another thread.  In the most recent version of iTunes the 
problem was no longer in evidence.  I don't know if that is down to 
changes in get_iplayer, ffmpeg or iPlayer, but the problem is gone.  If 
that observation holds up to further testing, I think it would be 
reasonable to simplify that bit of get_iplayer and tell users to update 
to the latest iTunes if necessary.  There may be a few Leopard users 
unhappy at the news, but that's the breaks.

If we do need to retain the filter and update to using the new argument 
syntax, the version of ffmpeg installed with get_iplayer would need to 
be updated.  It's still at 0.8, and I haven't bothered changing it 
since: a) there was no need; b) our source for builds (zeranoe.com) 
hasn't made any builds from the release branches since 0.8.  It's no 
problem to update with the installer, but we would need to coordinate 
that change with the release of get_iplayer itself.

Perhaps a more future-proofed approach might to give get_iplayer the 
means to switch invocations of ffmpeg/avconv based on the name (ffmpeg 
vs. avconv).  For the immediate future, we can probably assume that 
anything invoked as "ffmpeg" would accept the old syntax, and anything 
invoked as "avconv" would accept the new syntax.  Seems kind of 
hack-ish, but it might be a reasonable brute-force solution.