1 |
On Tue, 15 Jan 2013 21:10:12 -0800 |
2 |
""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
3 |
|
4 |
> On 1/15/13 4:55 AM, Alexis Ballier wrote: |
5 |
> > On Mon, 14 Jan 2013 20:34:42 -0800 |
6 |
> > ""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
7 |
> >> I'm trying to make Chromium be more compatible with more versions |
8 |
> >> of ffmpeg: |
9 |
> >> <https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion> |
10 |
> >> (although not stated there, that includes libav). |
11 |
> > |
12 |
> > I've done quite a lot of work for various packages among the past |
13 |
> > years on that side, so if you have specific questions, feel free to |
14 |
> > ask. |
15 |
> |
16 |
> Alright: |
17 |
> |
18 |
> 1. What's the difference between libav and ffmpeg? Do the projects |
19 |
> merge each other's changes? If not, in what direction do patches flow? |
20 |
|
21 |
ffmpeg merges daily from libav; for libav, better ask Luca or Diego I |
22 |
think, but I've seen they manually port some patches from ffmpeg from |
23 |
time to time. |
24 |
|
25 |
> 2. What are API compatibility policies for ffmpeg and libav? |
26 |
|
27 |
There's no policy AFAIK. For what I understood, libav doesn't care; |
28 |
ffmpeg tries to be API and ABI compatible with libav (ie: provide the |
29 |
same API and ABI + their additions) |
30 |
|
31 |
> 3. Same as above for making releases (i.e. how frequent they are, how |
32 |
> much they change, and how much released libav and ffmpeg are in sync |
33 |
> with each other in practice). |
34 |
|
35 |
libav release schedule is independent; in the last years, ffmpeg |
36 |
releases have been more frequent and there's always been a ffmpeg |
37 |
release on par with a libav release (now we have libav-9 and ffmpeg-1.1 |
38 |
that should be on par) |
39 |
|
40 |
> 4. What are typical incompatibilities (if possible), and usual ways to |
41 |
> deal with them? |
42 |
|
43 |
For most of the API, there's none, but because of the above, during the |
44 |
years, small incompatibilities have accumulated and you can see them |
45 |
between the supposed to be on par releases. For example, libavfilter |
46 |
differs a lot between the two; the major/minor/micro versions are |
47 |
completely different between the two (usually you do #if version < foo |
48 |
conditions which become messy if you want to support both). |
49 |
|
50 |
> 5. Do you think it's possible / worth trying to convince upstream |
51 |
> ffmpeg / libav to have a more stable API over time? Which one could |
52 |
> be possibly more willing to listen and why? |
53 |
|
54 |
It is already the case for both: once a symbol / API is deprecated at |
55 |
major release N, it's still there at major N+1 and removed at major N+2. |
56 |
That's why I told you if you build without any deprecation warning, |
57 |
you should be safe for some time :) |
58 |
|
59 |
[...] |
60 |
> > What is the min. version it works with? |
61 |
> |
62 |
> Currently, for masked system-ffmpeg USE flag for chromium, it's |
63 |
> ffmpeg-1.0. |
64 |
|
65 |
And what is the problem with, say, 0.10.6 ? |
66 |
|
67 |
> > As a distro we have two options: |
68 |
> > 1) patch chromium to add #if's for older ffmpeg versions and be |
69 |
> > compatible: this may or may not be accepted by upstream, supporting |
70 |
> > older versions is just garbage code for them. |
71 |
> |
72 |
> I'm pretty sure upstream won't accept "trench warfare" #ifdefs (I'm |
73 |
> also an upstream dev). I'm also not enthusiastic about having an |
74 |
> out-of-tree Gentoo-side patch for a fast-moving project like that. |
75 |
> The additional cost on each version bump is also something to take |
76 |
> into account (fixing incompatibilities is one thing, but I'm also |
77 |
> thinking about like merge conflicts on the patches). |
78 |
> |
79 |
> > 2) (preferred) coordinate the other packages to be compatible with |
80 |
> > newer versions and unmask latest (we should be very close to be |
81 |
> > able to unmask ffmpeg-1) and make chromium require this version |
82 |
> > (this require chromium upstream to figure out what is the min. req. |
83 |
> > version) |
84 |
> |
85 |
> What when chromium upstream uses code more recent than latest ffmpeg |
86 |
> release and it doesn't compile against latest release? |
87 |
|
88 |
Blame them, it's stupid to break support for the latest release. |
89 |
Usually, it's quite trivial to maintain compatibility and you should |
90 |
probably lobby upstream to get this as a rule, it'd make life simpler |
91 |
for everyone. Or just patch releases not to use too bleeding-edge code |
92 |
(see mplayer for example). |
93 |
|
94 |
> Now what about libav? At one time I could compile against latest |
95 |
> masked ffmpeg in tree but couldn't compile against latest masked |
96 |
> libav (or any other version of it I think). Ideally I would like to |
97 |
> make it compilable against both. Does that sound like much more |
98 |
> difficult? |
99 |
|
100 |
It depends what the problem is: it may be just some missing #includes, |
101 |
some CODEC_ID present in ffmpeg but not in libav in which case you'd |
102 |
have to #ifdef its usage out, or more complicated if you use an API |
103 |
from ffmpeg not in libav like some libavfilter stuff. |
104 |
|
105 |
> > we should probably do something in-between 1 and 2 in order not to |
106 |
> > hold off sec. stabilizations of chromium because dozens of stable |
107 |
> > packages do not build with latest ffmpeg. |
108 |
> |
109 |
> Yup. Just note there is just ~6 weeks before each stable release. |
110 |
> That's not a very long time for most projects, and I think we won't |
111 |
> get other packages into shape that quickly. |
112 |
|
113 |
Probably, unfortunately. We could do like for mplayer then, patch it so |
114 |
that it builds with current releases. |
115 |
|
116 |
[...] |
117 |
> > Usually, if you build with the latest ffmpeg release and don't see |
118 |
> > any deprecation warning, you are safe for ~1 year or more. |
119 |
> |
120 |
> Somehow I don't think that'll work. Chromium pulls from ffmpeg trunk |
121 |
> frequently, so it's also a moving target. |
122 |
|
123 |
It doesn't imply chromium uses bleeding edge API not present in older |
124 |
releases: you told me that ffmpeg-1.0 is fine while we have ffmpeg-1.1 |
125 |
now :) |
126 |
|
127 |
> > IMHO a compatibility layer like you suggest on your link will be a |
128 |
> > pain, #if's are easier to handle. |
129 |
> |
130 |
> I could make a leightweight compatibility layer, don't underestimate |
131 |
> how nicely invented it can be. :) What if I say #define |
132 |
> ffmpeg_function wrapper_ffmpeg_function for chromium code, and then |
133 |
> have wrapper_ffmpeg_function do something smart depending on actual |
134 |
> ffmpeg version? |
135 |
|
136 |
It really depends on the problem; most of the time, the API breaks are |
137 |
not just simple function renaming :) |
138 |
See eg: |
139 |
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.h;h=8c8dd20ed3400527cab84265f4442bf06eb06f8d;hb=HEAD |
140 |
that tries to provide such a compatibility layer when possible, but |
141 |
there are #if in other parts of the code when not possible. |
142 |
It could be even worse if you want to go backward: usually deprecated |
143 |
functions are replaced by new more powerful ones. It's easy to map the |
144 |
old one to the new one (just set some arguments to 0) but the other way |
145 |
may be more tricky. |
146 |
|
147 |
Alexis. |