[FFmpeg-devel] [Cellar] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

Jerome Martinez jerome at mediaarea.net
Mon Feb 5 23:20:49 EET 2018


On 03/02/2018 14:48, Michael Niedermayer wrote:
>
> I hope this will not reduce interrest in working on a improved
> 9-16bit mode in v4.

I don't like to put politics in technical stuff, but here this is 
politics, and I think that blocking an easy improvement of FFV1 v3 
encoding/decoding in FFmpeg (actually just using the current FFV1 v3, 
and also v1 actually, specification without having artificial 
limitations about bit depths for a specific color space, i.e. 16-bit 
support was already there for YUV before I work on FFV1) just for 
forcing people to do a completely different work (e.g. working on FFV1 
v4) is not fair and IMO is not in the idea behind open source.
IMO if interest for 9-16bit (side note: I don't see why 8-bit should not 
be in the range, some ideas I have for v4 are useful also for 8-bit) 
mode in v4 is reduced, that would only mean that v3 is already so great 
and/or just that people have no better idea right now, it is not bad, 
and both works (using v3 at the maximum of its possibilities and working 
on v4) are separate works. FYI criticism I saw about FFV1 is not 
compression ratio but speed (playing a 4K stream is just impossible on a 
"normal" machine, you need a very expensive CPU for that) so my plan is 
to focus on speed improvement in priority. It could be v4 stuff 
(incompatible changes), or v3 (encoder/decoder optimization), depending 
of what I find.

>
>
> [...]
>
>> Last but not least, since almost two years now it's impossible
>> to work on the development of FFV1 v4. It's always the wrong
>> time and/or the wrong place every time I am doing something for
>> this cause. Why? This is extremely frustrating.
> I want to understand this too. IMO v4 development should be more
> important than or at least equally to the v3 draft polishing and neither
> should block the other.

Also politics, but I don't understand who is blocking v4 from your point 
of view. "impossible to work on v4"? Where? As far as I see 1 person 
(me) said his priority is having FFV1 v3 becoming a standard (so IETF 
related work) and widely used (so any bit depth for any supported color 
space in v3 because it is an easy demonstration that FFV1 is versatile 
without having to wait for v4 R&D, especially because v3 bitstream 
design is already pretty good and versatile) because this is what I 
need, and my personal case is not blocking anyone else for sending 
patches for either FFV1 specifications or FFmpeg code about v4. Eager to 
see patch proposals for v4 (and v3 if it does not break support of files 
in the wild), whoever feeling blocked with his patches should send patch 
proposals to either FFmpeg (code) or CELLAR mailing list (bitstream format).

That said, I plan to add more pix_fmt support for FFV1 v3 (which is 
already a good format!) support in FFmpeg and some optimization ideas 
beside my work for IETF spec, with the hope we could speak about 
technical issues (e.g. more optimization hints or info about wrong code 
or warning about that it breaks the bitstream specs as currently 
written), leaving aside politics.


More information about the ffmpeg-devel mailing list