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

[Michael Niedermayer]

On Sat, Jan 06, 2018 at 05:01:42PM +0100, Reto Kromer wrote:
> Michael Niedermayer wrote:
> 
> >>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. 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 ...
> 
> Hmm... I am a little surprised about this, as I paid EUR 2000 in
> 2016 for implementing the RGB48 support in FFV1. And I didn't it
> just for having less money in my pocket, but explicitly for the
> benefit of the community.
> 
> As I already said in other contexts, the experimental flag is
> actually avoiding a larger use of FFV1 in the archival
> community. As long as this flag is present, many film archives
> simply cannot adopt FFV1 for film preservation. That's my point.
> Therefore I support making the RGB48 support non-experimental.

Yes, the flag is annoying.
I kind of want to make teh design perfect before removing the experimental
check but maybe thats not reasonable i dont know


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.

-------------- 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/ec4b10ed/attachment.sig>