1 |
On Sun, Aug 28, 2016 at 11:15:40PM -0400, Mike Gilbert wrote: |
2 |
> On Sun, Aug 28, 2016 at 3:57 PM, Kristian Fiskerstrand <k_f@g.o> wrote: |
3 |
> > On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote: |
4 |
> >> B. Backport just the changes needed for chromium to older ffmpeg |
5 |
> > |
6 |
> > Any chance of it being included upstream or would it be a downstream |
7 |
> > carry for a long time? |
8 |
> |
9 |
> I haven't looked at any code, but given that it's a major version bump |
10 |
> of a library, the changes probably involve API-breaks. Backporting |
11 |
> them upstream or downstream is probably not a simple matter, and |
12 |
> probably a bad idea. |
13 |
|
14 |
Please don't backport or patch. That sounds like a potential disaster |
15 |
waiting to happen. The tracker bug for ffmpeg 3.0 has been open for |
16 |
quite a while and is taking time. Backporting just parts of it has the |
17 |
potential to break both stable and unstable and the time would be better |
18 |
used working on stabilizing 3.0. |
19 |
|
20 |
> >> C. Mask chromium's system-ffmpeg flag when the dependency on |
21 |
> >> ffmpeg-3.0.1 can't be satisfied |
22 |
> > |
23 |
> > Would this result in using bundled libraries instead? |
24 |
> |
25 |
> Yes, masking the system-ffmpeg USE flag would cause the bundled ffmpeg |
26 |
> code to be used. |
27 |
> |
28 |
> The Chromium project applies security fixes quite regularly, so don't |
29 |
> get too worried over it. |
30 |
|
31 |
Masking it is fine. Its suboptimal but it has much less breakage- |
32 |
potential. If 3.0 is not stable in time then just mask it. |
33 |
|
34 |
Also, is this ffmpeg or libav? or are they the same for 3.x? |
35 |
|
36 |
-- Jason |