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

[Michael Niedermayer]

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?= <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
> >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


> 
> 
> 
> >  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.

what get_context does was designed for 8bit, it should still be good enough
for 10bit and maybe 12 but as the bit depth gets larger i suspect get_context
becomes less optimal and there is more potential to improve compression
by changing it.


> 
> 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180106/7516534b/attachment.sig>