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