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

[Jerome Martinez]

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.



>   It can no longer then be changed, so we need to be really sure the design
> is optimal first.
> Are we ?
> who has checked alternatives? what where the reasons why the alternatives
> were not choosen?
> for example consider get_context(), what it does with >8bit may or may not
> be optimal
> iam interrested to work on that in fact, ive a quite long and growing list
> of other volunteer jobs to do though ...

bitdepths >8bit have been well-used for years since many of them have 
long been marked as non-experimental (for instance 10bit is frequently 
used with lossless encoding of broadcast media and video from analog 
tape sources). In my opinion get_context() is specified for all 
bitdpeths and non-experimental for FFV1 versions 0, 1, and 3 by the 
specification work and it should not be changed in these versions.

For the encoder there may still be an opportunity to optimize while 
continuing to conform to the FFV1 versions 0, 1, and 3 bitstream 
specification, even if the encoder marks RGB48 as non-experimental. 
Additionally FFV1 version 4 or later could consider further optimization 
requesting a change in the FFV1 bitstream as version 4 has no stable 
micro_version and the entire version is in an experimental status.