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. For the wider context regarding an important category of FFmpeg users, I wrote this – and I apologise for mentioning myself: https://retokromer.ch/publications/JFP_96.html Best regards, Reto _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel