[Audacity-cvs] FFmpeg 0.5 WAS: lib-src/ffmpeg/libavutil avutil.h...

[Reinhard Tartler]

Please keep the CC in tact, and feel free to forward my mails to the
audacity mailing lists.

LRN <lrn1986 at gmail.com> writes:

> Reinhard Tartler wrote:
>>>> Also we now have the position that user can click on the AMR WB 
>>>> export filter (no comments in the filter text), see a message that
>>>> FFmpeg needs configuring, install it, and then the WB export filter 
>>>> has disappeared. That is going to lead to support issues (it will 
>>>> look like our bug). 
>>>>   
>>>>       
>>> H-m-m...didn't thought of that. We should comment-out that export option
>>> then, until it is supported by Opencore AMR and libav*.
>>>     
>>
>> you could try to dlopen() libavcodec *and* try to load the amr codec
>> using avcodec_find_codec() or avcodec_find_encoder_by_name() or
>> something. Dependening on this check a sensible diagnostic message can
>> be printed out.
>>   
> That is exactly what Audacity does. Thing is, it shows these
> FFmpeg-dependable export types even if libav* is not hooked up - just to
> show the user that the support for that actually exist, so that the user
> will be motivated to obtain libav* and use these features. But when the
> user does that, the [advertised] amr-wb export suddenly disappears,
> because it is not implemented yet. That's confusing (for users). The
> only viable alternative is to comment it out.

How about greying it out, probably in a way that a popup or other
declarative help text explain why it is greyed out? Possible
explanations:

 - please install a ffmpeg with amr support

 - your ffmpeg installation does not support amr.

This would make diagnostics easier and confuse less users.

> Of course, it is possible to add special code to preserve it, but tell
> the user that it is not available, but that's still disappointing for
> the user. With libamr at least there *was* a possibility for the user
> to build amr-enabled libav*, or get it illegally from somewhere. With
> Opencore it's simply not there.

I don't see why it would be more difficult to build ffmpeg against
opencore amr compared to build against libamr. Can you please elaborate
here?

>>>> I'm not quite clear here. I thought I saw that the non-open AMR
>>>> libraries had been removed from FFmpeg 0.5. If that's true, then I
>>>> presume even user who self builds FFmpeg won't now have AMR 
>>>> WB encoding ability. Or, if someone builds or has an older FFmpeg 
>>>> system library and compiles Audacity, does Audacity still work with
>>>> that older library?
>>>>   
>>>>       
>>> No. Due to interface changes libav* prior to 0.5 is not supported
>>> anymore (i *could* have made it to support more than one version, but
>>> that's silly).
>>>     
>>
>> Why would that be silly? Please reconsider this decision, Linux distros
>> and other downstreams of ffmpeg like gstreamer-ffmpeg are currently
>> tracking the 0.5 branch and have no plans to track trunk again. Having a
>> common ffmpeg baseline seriously lowered the bug filing rate in ubuntu
>> of crasher bugs in libavcodec.
> FFmpeg is a moving target. It had no releases for years. This 0.5 came
> as a complete surprise for me.

The 0.5 release was specifically done because of downstream asking for a
non-moving target. Or put it the other way, it was created to avoid this
particular problem. Let's please use it, or at least until a real
technical reason occurs.

if it is just a method that was formery static is now public, well, I
think we can backport that change into the debian packages.

> However, what you're saying is that you are going to push this onto *my*
> head. I.e. instead of you worrying about multiple versions of ffmpeg
> available, *i* (or someone else who maintains Audacity-ffmpeg) will have
> to worry that Audacity should work with more than one version.

I'm not sure I understand. I don't ask for supporting multiple versions
of ffmpeg, I'm asking for supporting the version that linux distros
commongly use (or are at least supposed to use). and that is the 0.5
release branch, not trunk.

> Maybe they will indeed go for 0.5.1, etc, and we'll have stable releases
> more often. But i'm not sure...
> OK, ok, it's just me being lazy at the moment. Happy now? :)

OK, thanks for reconsidering.

> P.S. gst-ffmpeg needs ffmpeg only for its builtins. And it actually
> *disables* some ffmpeg codecs that are deemed incomplete. As for new
> ones, such as Opencore amr, they are integrated separately (AFAIK there
> are patches sitting in bugzilla that implement Opencore amr support in
> gst-plugins-ugly). That is why gst-ffmpeg is happy with 0.5, i think.

The reason is that distros prefer to build ffmpeg downstream
applications against a common version of ffmpeg for security,
maintenance and (partly) memory saving reasons. gst-ffmpeg was formerly
compiled against a random snapshot of ffmpeg that was included there,
and used against the system ffmpeg which shipped a random different
snapshot. Because gst-ffmpeg uses some ffmpeg internals (types, etc),
this just calls for crashes.

Now gst-ffmpeg is still built against an internal copy, but it at least
matches the version pretty close to the version it is used with.

I hope this makes things more clear, and thanks for reconsidering.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4