Jul 31, 2020, 10:48 by geo...@nsup.org: > Tables that were not just written by the code author are > not actually source code, otherwise, > "recode data..x1 < proprietary.o > source.c" > would be enough to launder a proprietary blob into > the source code. > > Documenting the origin of the tables or the methods > for their generation is necessary to let other developers > take over if the original author is no longer available. >
I disagree. We don't have any proprietary blobs in our codebase. Everything that you think is binary is in fact a well defined VLC table that simply describes bit positions and lengths. Neither are quantization tables. They're again, well defined series of lookup tables that always follow a simple pattern, be it linear or some exponent. Forcing developers to meticulously describe standard bitstream readers or copying entire chunks of specifications as comments just because you don't understand them, or want to justify your own personal war, or are paranoid of binary blobs is not acceptable. In the first place no one would commit actual binary blobs (read: CPU-specific bytecode or a series of bytes needed to initialize a device) to the codebase. And if developers were forced to copy chunks of spec as comments into the codebase you'll end up with licensed content just sitting in the codebase, making us liable for lawsuits. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
