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