Quoting Reinhard Tartler (2014-11-19 04:02:42)
>>> What could be considered problematic is that users technically do a
>>> license violation by installing libavcodec-extra-NN together with
>>> GPLv2 only packages. On might construct a situation where some
>>> Debian user creates an appliance that uses one of the packages above
>>> and install libavcodec-extra-NN. I could imagine that this situation
>>> might be problematic for that user.
[...]
> Maybe we can play tricks with dependencies instead: Let's have a
> "libavcodec-noextra" package (stable package name) that conflicts
> against the "libavcodec-extra-NN" (NN change on SONAME bumps). GPLv2
> binary packages can then depend on libavcodec-noextra to implement
> your concern.
>
> Does that make more sense?
Sounds good to me.
Possibly we can simplify even further:
* Have package libavcodec-extra-NN provide virtual libavcodec-extra
(i.e. non-versioned name of itself)
* Let GPLv2 packages conflict against libavcodec-extra (i.e. not
replace but complement existing suggests/recommends/depends).
How does that sound?
>>> I suppose that many users are very interested in the AAC encoders,
>>> because the native encore inside libavcodec is of rather poor
>>> quality.
>> Do you know of specific problems the native encoder has, which are
>> not present in the libvo_aacenc encoder?
>
> Sorry, I'm not up to speed with the details, but you have to be aware
> that AAC (like many other modern codecs) comes with lots of optional
> features, check for instance
> http://en.wikipedia.org/wiki/Advanced_Audio_Coding to get a flavor. I
> have to admit that I lost track which AAC encoder supports what
> features, how many tracks, etc, but I do know that vo-aacenc
> originates from the Android code base and at least at the time it was
> released, many people found it useful compared to the native aac
> encoder.
So basically you are unaware of any benefits of libvo_aacenc compared to
the builtin AAC encoder - beyond optimism¹ at its introduction.
- Jonas
¹ Release was obviously hyped by Google, and obviously few had yet
tested its actual merits at that time. Any actual benefits would have
found their way to either of the FFMpeg or Libav wiki pages by now, I
believe.
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature