1 |
On 1/15/13 4:55 AM, Alexis Ballier wrote: |
2 |
> On Mon, 14 Jan 2013 20:34:42 -0800 |
3 |
> ""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
4 |
>> I'm trying to make Chromium be more compatible with more versions of |
5 |
>> ffmpeg: |
6 |
>> <https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion> |
7 |
>> (although not stated there, that includes libav). |
8 |
> |
9 |
> I've done quite a lot of work for various packages among the past years |
10 |
> on that side, so if you have specific questions, feel free to ask. |
11 |
|
12 |
Alright: |
13 |
|
14 |
1. What's the difference between libav and ffmpeg? Do the projects merge |
15 |
each other's changes? If not, in what direction do patches flow? |
16 |
|
17 |
2. What are API compatibility policies for ffmpeg and libav? |
18 |
|
19 |
3. Same as above for making releases (i.e. how frequent they are, how |
20 |
much they change, and how much released libav and ffmpeg are in sync |
21 |
with each other in practice). |
22 |
|
23 |
4. What are typical incompatibilities (if possible), and usual ways to |
24 |
deal with them? |
25 |
|
26 |
5. Do you think it's possible / worth trying to convince upstream ffmpeg |
27 |
/ libav to have a more stable API over time? Which one could be possibly |
28 |
more willing to listen and why? |
29 |
|
30 |
>> Now the initial response there is not enthusiastic (which doesn't |
31 |
>> surprise me), but do you think there are some points useful for the |
32 |
>> discussion I'm not aware of? |
33 |
> |
34 |
> I don't get what is the problem: chromium uses an internal version |
35 |
> corresponding to ffmpeg git master and doesn't build with older ones? |
36 |
|
37 |
Generally yes. It periodically pulls directly from git master (often |
38 |
ahead of any release) and that usually breaks build with older ffmpegs. |
39 |
|
40 |
> What is the min. version it works with? |
41 |
|
42 |
Currently, for masked system-ffmpeg USE flag for chromium, it's ffmpeg-1.0. |
43 |
|
44 |
> As a distro we have two options: |
45 |
> 1) patch chromium to add #if's for older ffmpeg versions and be |
46 |
> compatible: this may or may not be accepted by upstream, supporting |
47 |
> older versions is just garbage code for them. |
48 |
|
49 |
I'm pretty sure upstream won't accept "trench warfare" #ifdefs (I'm also |
50 |
an upstream dev). I'm also not enthusiastic about having an out-of-tree |
51 |
Gentoo-side patch for a fast-moving project like that. The additional |
52 |
cost on each version bump is also something to take into account (fixing |
53 |
incompatibilities is one thing, but I'm also thinking about like merge |
54 |
conflicts on the patches). |
55 |
|
56 |
> 2) (preferred) coordinate the other packages to be compatible with |
57 |
> newer versions and unmask latest (we should be very close to be able to |
58 |
> unmask ffmpeg-1) and make chromium require this version (this require |
59 |
> chromium upstream to figure out what is the min. req. version) |
60 |
|
61 |
What when chromium upstream uses code more recent than latest ffmpeg |
62 |
release and it doesn't compile against latest release? |
63 |
|
64 |
Now what about libav? At one time I could compile against latest masked |
65 |
ffmpeg in tree but couldn't compile against latest masked libav (or any |
66 |
other version of it I think). Ideally I would like to make it compilable |
67 |
against both. Does that sound like much more difficult? |
68 |
|
69 |
> we should probably do something in-between 1 and 2 in order not to hold |
70 |
> off sec. stabilizations of chromium because dozens of stable packages |
71 |
> do not build with latest ffmpeg. |
72 |
|
73 |
Yup. Just note there is just ~6 weeks before each stable release. That's |
74 |
not a very long time for most projects, and I think we won't get other |
75 |
packages into shape that quickly. |
76 |
|
77 |
>> What are the main challenges of keeping up-to-date with latest ffmpeg |
78 |
>> API changes? How do other projects deal with that? |
79 |
> |
80 |
> Specify a min. supported version, use #if for what remains. |
81 |
> It may be easy or quite a lot of work, depending on what part of the |
82 |
> API is used. ATM, being compatible with ffmpeg 0.10 up to git master |
83 |
> isn't _that_ heavy on #if's (see eg: |
84 |
> http://dev.gentoo.org/~aballier/distfiles/xbmc-11.0-ffmpeg-1.0-compat-1.tar.bz2 |
85 |
> ) but may require a lot of changes. |
86 |
|
87 |
I will take a look at that patch later to see how possible changes look |
88 |
like. |
89 |
|
90 |
> Usually, if you build with the latest ffmpeg release and don't see any |
91 |
> deprecation warning, you are safe for ~1 year or more. |
92 |
|
93 |
Somehow I don't think that'll work. Chromium pulls from ffmpeg trunk |
94 |
frequently, so it's also a moving target. |
95 |
|
96 |
> IMHO a compatibility layer like you suggest on your link will be a |
97 |
> pain, #if's are easier to handle. |
98 |
|
99 |
I could make a leightweight compatibility layer, don't underestimate how |
100 |
nicely invented it can be. :) What if I say #define ffmpeg_function |
101 |
wrapper_ffmpeg_function for chromium code, and then have |
102 |
wrapper_ffmpeg_function do something smart depending on actual ffmpeg |
103 |
version? |
104 |
|
105 |
Paweł |