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