| 1 |
On Thu, 1 Sep 2016 00:01:16 -0400 |
| 2 |
Mike Gilbert <floppym@g.o> wrote: |
| 3 |
|
| 4 |
> On Wed, Aug 31, 2016 at 11:09 PM, Mike Gilbert <floppym@g.o> |
| 5 |
> wrote: |
| 6 |
> > On Wed, Aug 31, 2016 at 12:52 PM, Alexis Ballier |
| 7 |
> > <aballier@g.o> wrote: |
| 8 |
> >> On Sun, 28 Aug 2016 19:28:48 +0200 |
| 9 |
> >> "Paweł Hajdan, Jr." <phajdan.jr@g.o> wrote: |
| 10 |
> >> |
| 11 |
> >>> D. Patch chromium not to require newer ffmpeg |
| 12 |
> >> |
| 13 |
> >> |
| 14 |
> >> You can use the attached patch. Quick test on youtube showed it |
| 15 |
> >> works. |
| 16 |
> > |
| 17 |
> > Nice! Testing this now. |
| 18 |
> |
| 19 |
> The code you have disabled seems to be comparing color space id values |
| 20 |
> as defined in src/ui/gfx/color_space.h to the equivalent values in the |
| 21 |
> ffmpeg API. I would assume this is because some chromium code uses |
| 22 |
> them interchangeably. |
| 23 |
> |
| 24 |
> What happens if we pass one of those ids to an ffmpeg function that |
| 25 |
> doesn't understand it? I'm afraid this might break in some subtle way. |
| 26 |
|
| 27 |
Me too. Except that looking at the code I realized those values are |
| 28 |
only read from ffmpeg, never written to, so this case cannot happen I |
| 29 |
think. |
| 30 |
|
| 31 |
Worse: ffmpeg usually parses it from the bitstream and passes it |
| 32 |
straight from it since the numerical values are made to match e.g. the |
| 33 |
ones from the hevc spec, so it should actually be transparent. |
Archives