1 |
On 11/02/13 03:01, Alexis Ballier wrote: |
2 |
> Sorry, I was away this week end... |
3 |
|
4 |
Not a problem, I should be reachable anytime today. |
5 |
|
6 |
> This is only because libav people do not care at all about what FFmpeg |
7 |
> defines, while FFmpeg seems to care more about its consumers and users |
8 |
> by trying to provide a compatible ABI and API. |
9 |
|
10 |
The reasons about that could be multiple, the facts are those. If you |
11 |
want you application to run in both you pick the Libav API. |
12 |
|
13 |
> Moreover, this is not |
14 |
> true at all when it comes to the parts where supporting both forks is |
15 |
> painful: libavfilter and audio resampling. It is pretty clear that the |
16 |
> audio resampling wheel was reinvented on the libav part, with a |
17 |
> different library name and in 95% of its use cases going from ffmpeg's |
18 |
> audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'. |
19 |
|
20 |
Not really, the resample library idea was brewing for long even |
21 |
pre-fork, it got released first on FFmpeg because there is this bulimic |
22 |
tendency to add more features in order to be compelling in FFmpeg. |
23 |
|
24 |
I said already what happened when I started to develop the pulse capture |
25 |
and the generic segmenter in my github as another example of stuff |
26 |
developed by unrelated people and curiously landing before deemed ready |
27 |
by the author in ffmpeg git. (prores could be considered yet another |
28 |
funny example). |
29 |
|
30 |
> Some parts of libavfilter also appeared later in libav, sometimes with |
31 |
> a slightly different API, making it really awful to support both forks |
32 |
> in applications. |
33 |
|
34 |
libavfilter is deemed still not ready for general consumption in Libav |
35 |
and just the set of calls that won't change (hopefully) in the future |
36 |
are provided. Meanwhile we are trying to make the whole buffer |
37 |
management less copy-happy and a little more rational. |
38 |
|
39 |
(not sure if you tried to use libavfilter but it is a _bit_ hard to use |
40 |
if compared to vlc filter layer and such) |
41 |
|
42 |
> (I'm still looking forward a patch for xbmc and upstreamed patches for |
43 |
> mplayer btw) |
44 |
|
45 |
I might spend a little time. |
46 |
|
47 |
>> it offers a more compact surface for attacks if you are |
48 |
>> really concerned about security and usually it is a little more |
49 |
>> compact |
50 |
> |
51 |
> If you mean that ffmpeg is libav + ffmpeg additions, then yes. |
52 |
> However, if you are concerned by a more compact surface, then libav is |
53 |
> not the right answer: you can very well disable selected codecs, |
54 |
> (de)muxers, etc at build time. I even started to work on reflecting this |
55 |
> into an ebuild some years ago before reaching the conclusion that it |
56 |
> would be confusing for little to no gain. This can of course be done if |
57 |
> there is some demand, but so far I have not seen any. |
58 |
|
59 |
The ebuild supports extra parameters for that specific purpose. |
60 |
|
61 |
> It is funny to see how libav ignores completely ffmpeg even for |
62 |
> bugfixes, I stumbled over this recently and it sounded familiar: |
63 |
> http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d |
64 |
> vs |
65 |
> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b |
66 |
> now, you can look at the dates, there's a one year lag in libav for |
67 |
> reinventing the same bugfix. This is for a format almost nobody uses, |
68 |
> but in any case I do not consider this attitude sane. |
69 |
|
70 |
Nobody is perfect and not everybody has the time to track another |
71 |
project tree every day. |
72 |
|
73 |
>> and a bit more tested over a wider range of architectures. |
74 |
> |
75 |
> If you are talking about fate, then I cannot comment. fate started |
76 |
> before the split, so I assume the owners of said test machines took |
77 |
> them within their respective fork. |
78 |
|
79 |
That speaks a *bit* about the general support maybe? |
80 |
|
81 |
|
82 |
> I fully agree there, but you should be careful with who you include in |
83 |
> 'our'. In the case of a default then it is clearly 'the users'. Now, |
84 |
> considering there are a couple (very few) of packages that do not |
85 |
> compile with libav, do you consider having it as default a good idea? |
86 |
|
87 |
I have no opinion, I stayed out of the discussion and decision about |
88 |
that before because I know I have a bias. I let other people decide. |
89 |
|
90 |
> Those packages can very well be fixed, but if patches do not go |
91 |
> upstream, this is not going to work in the long term. Also, the only |
92 |
> reason why I have not pinned those packages to depend only on |
93 |
> media-video/ffmpeg is because libav is not the default (not entirely |
94 |
> true btw, see later), meaning those that use libav are those that are |
95 |
> willing to help and know what they are doing. If people are to get |
96 |
> libav by default and then hit compile failures to be told to use |
97 |
> ffmpeg, then it is QA 101 that these packages should be depending on |
98 |
> media-video/ffmpeg. |
99 |
|
100 |
You can, if you really want, offset ffmpeg so it doesn't clash with Libav. |
101 |
|
102 |
|
103 |
> ... and chrome, mplayer, xbmc use ffmpeg :=) |
104 |
|
105 |
Chrome uses its own fork, reverting some changes form FFmpeg and picking |
106 |
what they deem useful. |
107 |
|
108 |
mplayer changes ffmpeg when they need something as they please |
109 |
|
110 |
xbmc used the new&improved libavfilter API to access swscale, the |
111 |
restricted api seems to work just fine. |
112 |
|
113 |
> Probably true, but I still consider a quick fix disabling the |
114 |
> vulnerability to be released quickly is a good thing. |
115 |
|
116 |
No, it is in general a really stupid idea. You are basically telling the |
117 |
interested attackers where the problem is. Then the attacker does +1 and |
118 |
you have your new, freshly installed application compromised. |
119 |
|
120 |
It is the _worst_ possible service you could do. |
121 |
|
122 |
Think about a random rpc system with 4 calls that are similar and go |
123 |
down the same codepaths, some fuzzer discovers that sending a message |
124 |
with a certain shape let you crash the application. |
125 |
|
126 |
The fix pushed and published with much fanfare is "if $shape then error" |
127 |
for that specific rpc call. |
128 |
Pity that that similar shapes would crash the other rpc calls, thus |
129 |
anybody with interest in crashing the application have a good example on |
130 |
how to do that. |
131 |
|
132 |
Unrelated to the discussion please do not do that in any project you |
133 |
contribute. It is that _bad_ |
134 |
|
135 |
|
136 |
> By the way, I do not know why you still consider me a FFmpeg committer, |
137 |
> of course I can git clone and commit but someone has to push for me. |
138 |
|
139 |
I thought you had the commit since svn time, I don't recall if I |
140 |
suggested it myself or other did. |
141 |
|
142 |
> Also, I never understood why you consider Tomás to be neutral |
143 |
|
144 |
I can't say about him, he never sent patches to us and he volunteer to |
145 |
do the virtual when I said that I'd rather have somebody else not |
146 |
related to the project. |
147 |
|
148 |
> These two posts are interesting for anyone wanting to understand the |
149 |
> situation also (1st more from ffmpeg side and 2nd more from libav's): |
150 |
> http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html |
151 |
> http://codecs.multimedia.cx/?p=370 |
152 |
|
153 |
First one from one of the main ffmpeg committers nowadays the second |
154 |
from the main codec reverse engineer. |
155 |
|
156 |
lu |