Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-08-08 Thread Paul B Mahol
Unacceptable as it contains multiple typos. On 7/31/20, Nicolas George wrote: > 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. >

Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-08-07 Thread Alexander Strasser
Hi Nicolas! On 2020-08-03 11:54 +0200, Nicolas George wrote: > Nicolas George (12020-07-31): > > Something like this would be acceptable: > > > > /* Reverse-engineered by encoding various files with the reference > >encoder. */ > > > > Reluctance to give this little information is baffling to

Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-08-03 Thread Zhao Zhili
> On Aug 3, 2020, at 5:54 PM, Nicolas George wrote: > > Nicolas George (12020-07-31): >> Something like this would be acceptable: >> >> /* Reverse-engineered by encoding various files with the reference >> encoder. */ >> >> Reluctance to give this little information is baffling to me. > >

Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-08-03 Thread Valentin Schweitzer
Can other developers give their input on this? I am not currently a FFmpeg developer, so my opinion might be less relevant than what others have stated. I think giving a source for things that are not inherently obvious, but are part of the code is a good idea. Even if some tables are well ex

Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-08-03 Thread Nicolas George
Nicolas George (12020-07-31): > Something like this would be acceptable: > > /* Reverse-engineered by encoding various files with the reference >encoder. */ > > Reluctance to give this little information is baffling to me. Can other developers give their input on this? Is it acceptable or t

Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-07-31 Thread Nicolas George
Kieran Kunhya (12020-07-31): > > /* Geometric progression with ratio 42. */ > > > > Or, if you used a one-liner in whatever language of your choice, just > > copy-paste it into the comment: > > > > /* Zsh: for i in {0..11}; printf "%8x\\n" $[440*2**(22+i/12.)] */ > > This is completely unrealistic

Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-07-31 Thread Kieran Kunhya
> /* Geometric progression with ratio 42. */ > > Or, if you used a one-liner in whatever language of your choice, just > copy-paste it into the comment: > > /* Zsh: for i in {0..11}; printf "%8x\\n" $[440*2**(22+i/12.)] */ > This is completely unrealistic for reverse engineered tables such as VLCs

Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-07-31 Thread Lynne
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

Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.

2020-07-31 Thread Nicolas George
Lynne (12020-07-31): > 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. Please read my message more carefully (and possibly with less hostility): I never sai