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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
