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

Jerome Martinez jerome at mediaarea.net
Sun Jan 7 22:20:15 EET 2018


On 07/01/2018 20:08, Michael Niedermayer wrote:
> [...]
> This is correct but i think misleading a bit
> the 17bit case this is about uses a seperate codepath.

For your (FFmpeg) encoder and decoder. Not mine (same code path is used 
for 8/10/12/16/... bit RGB and YUV with my encoder and decoder).
Again, we mix up bitstream specification and FFmpeg implementation.
In the bitstream specifications, there is currently only one path 
(except for handling files in the wild which are not conform to the 
unique path, we take care of them for historical reasons).

>   So if its enabled
> we generate new files that have never been generated before in some sense
> AFAIK

- MediaConch conformance checker can check files up to 30 bits per 
component, and already implements the way it is written in spec for all 
supported bit depths, because the spec was flagged as stable whatever is 
the bit depth for a long time, without having anyone saying that 16 or 
17-bit for RGB (reminder: it is already set as "stable" for YCbCr 
16-bit) may have a different paths later for versions 0, 1, 3. If you 
change the bitstream of RGB48 or any stream with bitdepth <=30, you 
break it despite the fact it is validating correctly and would be a 
major issue for this tool (breaking trust about the tool or FFV1, as 
there would be 2 variants of FFV1 RGB48).
- I have an early (not yet public, for testing the spec only for the 
moment) version of an encoder conforming to the spec for all bit depths 
up to 30-bit per component.
- I have heard about other FFV1 encoders able to encode RGB48

>
> If we change the bitstream in a future version, which i belive we
> should consider. Then we have an additional "old" version of the 17bit path
> that needs to be supported in implementations.

question: How would you detect old version, from all encoders (not only 
FFmpeg)? there is nothing permitting that in the bitstream AFAIK (for 
v1: no micro_version; for v3: micro version >4 must be compatible with 
v4 as v4 is flagged stable).
So it is "bitstream is in stone" now, for at least versions 0, 1, 3. 
Reason I speak about R&D with version 4 bitstream (I don't speak about 
FFmpeg), which is still flagged as experimental for all files.

>
>
>> 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)
> I think i added the flag check. The reason behind the check was so that the
> bitstream syntax can be changed without the need to support every iteration
> of the bitstream.
> I had hoped someone would fund research and testing of further improvments
> to the various fine details of higher bit depth encoding beyond 8bit.
> IIRC No further funding was provided, Noone worked on it as a volunteer,
> No changes where proposed  ...

This is planned on my side after FFV1 versions 0, 1, 3 are finalized. 
With version 4 (the experimental version).
but it is possible only if we all are in sync and don't do something 
against the consensus, and as far I as I understand the consensus is 
that versions 0, 1, 3 are "bitstream is in stone" now (and actually from 
the beginning of CELLAR) based on the draft of FFV1 specifications, 
which is detailed before going to IETF but not changed. All the 
communication, at IETF and conferences, around FFV1 versions 0, 1, 3 is 
that the bitstream specification is stable, and discussing about 
breaking this consensus may harm FFV1 spread.

>
> But it wasnt intended as a "bitstream is in stone, encoder might mismatch
> the spec" at the time.

I disagree: the idea behind CELLAR is that all encoders **must** match 
the spec, or there is misunderstanding to clarify. Else everyone does 
his own version of FFV1, and we can not work together on an unique 
lossless compression format. The spec is expected to be the reference 
(for versions 0, 1, 3 for the moment) and encoders are expected to match 
the spec.

>
> We have a draft spec now that does not limit bitdepth in any way, this may
> have been a mistakke but i dont see this as a big problem honestly. I do not
> propose to change this. But i would not oppose it if people want to change it
>
> If someone creates a 19bit per sample file based on the draft spec it also
> will not decode with most real world implementations.

It will with my conformance checker. You can not know what is "real 
world", as a couple of encoders may be in house only.
we still mix up bitstream specification and one implementation.
The idea behind CELLAR is to have FFV1 a standardized video format, so 
we can not decide for 1 encoder to change the bitstream. We need to find 
a consensus on CELLAR mailing-list first. The consensus is what is 
written in the draft and there was no post on CELLAR mailing-list for 
limiting to some bit depths.

> There is no question that with a unlimited bitdepth, real implementations
> will never support some depths

Whatever is the support from the encoders you know, you can not know 
what was created by others based on the bitstream specification. so the 
bitstream is specified (for versions 0, 1, 3) for all bit depths and we 
can not change that now, as it is written for a long time in spec that 
the spec is flagged stable for these versions.

The question is not what is the support from decoder x, the question is 
that if there is a plan to break the compatibility between current 
version of FFV1 draft and future versions of this document.

>
> I just dont want to create a new variant of files _IF_ we plan to work on
> improving the "bitstream syntax" in the next version.

I don't understand: yes, we plan to improve the bitstream, and this is 
the reason we plan a version 4, 5, 6... But it does not mean that 
versions 0, 1, 3 are not used by FFmpeg or any other encoder for all bit 
depths.

But again, here (ffmpeg-devel), my goal was to speak about FFmpeg 
encoder, it was not intended to speak about FFV1 specification, and it 
is weird for me to have to speak about FFV1 specification on 
ffmpeg-devel (it should be on CELLAR only).
Being sure that FFmpeg is creating a bitstream conforming to FFV1 
specifications (so versions 0, 1, 3) should be the only criteria.

> Of course if these files are already out in the wild then we must support
> this in the implementation. And then most of this discussion is meaningless

I confirm that RGB48 files are already in the wild, as it is needed by 
some archives, and I confirm that they rely on MediaConch for testing 
the conformance compared to the specification.

I still don't see a reason to block 1 encoder to create RGB48 with 
version 1 or 3, as the spec is clear for a long time about how the 
bitstream is for such bit depth. Note that the FFV1 RGB48 decoder is not 
flagged as experimental, so any old version of FFmpeg should be able to 
decode new files you want to create (I don't see how they could do that 
as they don't know the get_context you want to implement) if you don't 
want to have complain that an old stable version of FFmpeg is not able 
to decode a FFV1 RGB48 file you just created with the new FFmpeg 
implementation.

Again, the experimental flag is for FFmpeg encoder, not the FFV1 
bitstream, the FFV1 bitstream is flagged as stable in FFV1 
specification, including RGB48.

Additionally, FFmpeg FFV1 decoder is currently able to decode RGB48 as 
specified in FFV1 specification and created by encoders conforming to 
the spec (FFmpeg "experimental" included) without having to set "-strict 
experimental" on the command line.

For these reasons, I still argue to remove the experimental flag for 
this encoder about RGB48 as the output is conform to FFV1 specifications 
and current and older versions of FFmpeg would not be able to decode 
FFV1 RGB48 if get_context is changed.

Jérôme


More information about the ffmpeg-devel mailing list