[FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental
jerome at mediaarea.net
Sat Jan 6 17:54:18 EET 2018
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
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.
More information about the ffmpeg-devel