On 1/15/13 4:55 AM, Alexis Ballier wrote: > On Mon, 14 Jan 2013 20:34:42 -0800 > ""Paweł Hajdan, Jr."" <phajdan...@gentoo.org> wrote: >> I'm trying to make Chromium be more compatible with more versions of >> ffmpeg: >> <https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion> >> (although not stated there, that includes libav). > > I've done quite a lot of work for various packages among the past years > on that side, so if you have specific questions, feel free to ask.
Alright: 1. What's the difference between libav and ffmpeg? Do the projects merge each other's changes? If not, in what direction do patches flow? 2. What are API compatibility policies for ffmpeg and libav? 3. Same as above for making releases (i.e. how frequent they are, how much they change, and how much released libav and ffmpeg are in sync with each other in practice). 4. What are typical incompatibilities (if possible), and usual ways to deal with them? 5. Do you think it's possible / worth trying to convince upstream ffmpeg / libav to have a more stable API over time? Which one could be possibly more willing to listen and why? >> Now the initial response there is not enthusiastic (which doesn't >> surprise me), but do you think there are some points useful for the >> discussion I'm not aware of? > > I don't get what is the problem: chromium uses an internal version > corresponding to ffmpeg git master and doesn't build with older ones? Generally yes. It periodically pulls directly from git master (often ahead of any release) and that usually breaks build with older ffmpegs. > What is the min. version it works with? Currently, for masked system-ffmpeg USE flag for chromium, it's ffmpeg-1.0. > As a distro we have two options: > 1) patch chromium to add #if's for older ffmpeg versions and be > compatible: this may or may not be accepted by upstream, supporting > older versions is just garbage code for them. I'm pretty sure upstream won't accept "trench warfare" #ifdefs (I'm also an upstream dev). I'm also not enthusiastic about having an out-of-tree Gentoo-side patch for a fast-moving project like that. The additional cost on each version bump is also something to take into account (fixing incompatibilities is one thing, but I'm also thinking about like merge conflicts on the patches). > 2) (preferred) coordinate the other packages to be compatible with > newer versions and unmask latest (we should be very close to be able to > unmask ffmpeg-1) and make chromium require this version (this require > chromium upstream to figure out what is the min. req. version) What when chromium upstream uses code more recent than latest ffmpeg release and it doesn't compile against latest release? Now what about libav? At one time I could compile against latest masked ffmpeg in tree but couldn't compile against latest masked libav (or any other version of it I think). Ideally I would like to make it compilable against both. Does that sound like much more difficult? > we should probably do something in-between 1 and 2 in order not to hold > off sec. stabilizations of chromium because dozens of stable packages > do not build with latest ffmpeg. Yup. Just note there is just ~6 weeks before each stable release. That's not a very long time for most projects, and I think we won't get other packages into shape that quickly. >> What are the main challenges of keeping up-to-date with latest ffmpeg >> API changes? How do other projects deal with that? > > Specify a min. supported version, use #if for what remains. > It may be easy or quite a lot of work, depending on what part of the > API is used. ATM, being compatible with ffmpeg 0.10 up to git master > isn't _that_ heavy on #if's (see eg: > http://dev.gentoo.org/~aballier/distfiles/xbmc-11.0-ffmpeg-1.0-compat-1.tar.bz2 > ) but may require a lot of changes. I will take a look at that patch later to see how possible changes look like. > Usually, if you build with the latest ffmpeg release and don't see any > deprecation warning, you are safe for ~1 year or more. Somehow I don't think that'll work. Chromium pulls from ffmpeg trunk frequently, so it's also a moving target. > IMHO a compatibility layer like you suggest on your link will be a > pain, #if's are easier to handle. I could make a leightweight compatibility layer, don't underestimate how nicely invented it can be. :) What if I say #define ffmpeg_function wrapper_ffmpeg_function for chromium code, and then have wrapper_ffmpeg_function do something smart depending on actual ffmpeg version? Paweł
signature.asc
Description: OpenPGP digital signature
