[FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

[Jerome Martinez]

On 06/01/2018 23:21, Michael Niedermayer wrote:
> On Sat, Jan 06, 2018 at 04:54:18PM +0100, Jerome Martinez wrote:
>> On 06/01/2018 02:05, Michael Niedermayer wrote:
>>>>   ffv1enc.c |    4 ----
>>>>   1 file changed, 4 deletions(-)
>>>> acfc60c913b311b148f2eeef2d2d6ea9e37afcf7  0001-avcodec-ffv1enc-mark-RGB48-support-as-non-experiment.patch
>>>>  From 303f63fb7e6172fdb7de66da1f8a4006b79a535f Mon Sep 17 00:00:00 2001
>>>> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <jerome at mediaarea.net>
>>>> Date: Fri, 5 Jan 2018 11:09:01 +0100
>>>> Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental
>>>>
>>>> Resulting bitstream was tested with a conformance checker
>>>> using the last draft of FFV1 specifications.
>>> But has the way this is stored been optimized ?
>>>
>>> Once its marked as non exerimental all future decoders must support the exact
>>> way.
>> Although this is considered experimental in the encoder, the implementation
>> adheres to the description in the specification. The bitstream specification
>> does not provide a bitdepth limit so with the current draft of the
>> specification, another FFV1 encoder could already encode 16-bit (and more)
>> content. The work on the specification has been careful to not break
>> compatibility with former drafts and at this point the FFV1 bitstream
>> specification for versions 0, 1, and 3 should be considered already
>> non-experimental for all bit depths. All current decoders should already
>> support the exact way it is currently specified.
>>
>> To make a change in the specification at this point would have cascading
>> consequences as we’d have to retract the part of the specification which
>> states that micro_version 4 of version 3 is the first stable variant. Worse,
>> it is impossible to indicate a bitstream change in FFV1 version 1, which
>> permits RGB 16-bit content too, so it would be difficult for a decoder to
>> detect a bitstream not conforming to the bitstream created by the current
>> version of FFmpeg encoder.
> Are you not making this look alot more complex than it is ?
> Or maybe we talk about slightly different things here
>
> with the next version we can introduce any method of storing 16bit or 9-15 bit
> and we certainly do not support in the implementation all possible bit depths
>
>  From what i remember I had always wanted to improve the way that
> more than 8bit is handled, not just 16. Although 16 is a bit special
>
> Consider this:
> If we improve get_context() in the next version for >8bit
> we still have to support 9-15 bit with the old definition
> if we now declare 16bit non experimental then we also must support that with
> an old get_context() in the decoder.
> the 16bit path is seperate from the lower bit depth. So this is an Additional
> codepath that we have to carry in the future
>
> isnt it smarter now that if we want to improve get_context() that we
> dont now extend what can be generated with the current get_context ?
>
> or are such current get_context() style files already widespread ?
> if so then its probably best to accept it and keep supporting it

I am lost.
Looks like we talk about 2 different subjects: FFV1 bitstream 
specifications and FFmpeg implementation.
Let separate subjects:

FFV1 bitstream specifications:
Since at least 2012 [1] get_context (in the bitstream) is defined and 
flagged as stable for **all** bit depths for versions 0, 1, 3.
It is still the case today [2].
There was a consensus on discussing about FFV1 bitstream on CELLAR 
mailing list
There was a consensus for not changing the bitstream for version 0, 1, 3 
so we can standardize it ASAP without breaking current implementations 
(reason we document bugs in the main encoder, but the idea is not to 
accept more changes)
If the FFV1 bitstream for version 0, 1, or 3 must be changed in current 
stable version, it would be a major break in the consensus and it should 
be discussed on CELLAR list (in copy as they are concerned), but I doubt 
the consensus would be for breaking the bitstream compatibility as the 
discussion from day 0 on CELLAR is to document current bitstream without 
changing it for versions 0, 1, 3. The fact that there was no (publicly 
available) RGB48 encoder in the wild is not an excuse for breaking the 
compatibility with current draft of specifications. Same if someone 
decides to do an encoder for e.g. RGB3000.
It is possible to change the bitstream with version 4 (experimental 
version), and it is a good place for changing get_context for 16-bit 
content (whatever is the color space, BTW).

FFmpeg implementation:
FFV1 YCbCr 16-bit is already flagged as non experimental, so there is 
already some non experimental 16-bit support in FFmpeg FFV1 encoder. 
16-bit is not new and for RGB48 the actual encoding after RGB to YCbCr 
transformation is just 1 bit more (17-bit).
FFmpeg experimental flag is for the status of the encoder, not for the 
status of the bitstream (the bitstream for versions 0, 1, 3 is already 
considered stable for RGB48 and others)
FFV1 RGB48 support in FFmpeg is conform to FFV1 bitstream specifications.
Optimizing FFmpeg for better compression of FFV1 RGB48 as specified in 
spec is not blocked after this change.
The only reason for keeping the experimental flag for RGB48 support is 
if the resulting file does not comply to the FFV1 specification, and 
this is not the case (tested with a conformance checker complying to 
FFV1 specifications).

As a result, the comment about get_contet for RGB48 is blocking for 
removing experimental status of version 4, but the suggested patch does 
not touch on version 4.

[1] 
https://github.com/FFmpeg/FFV1/blob/cbb560873e54bfe2d2042e898a210fe2abd079e0/ffv1.lyx#L659
[2] 
https://github.com/FFmpeg/FFV1/blob/fdc65b73282633cc8867c185e83a6d21e5c65f3f/ffv1.md#context 

[3] 
https://github.com/FFmpeg/FFV1/blob/fdc65b73282633cc8867c185e83a6d21e5c65f3f/ffv1.md#micro_version