Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 2, 2015 at 12:51 PM, Ganesh Ajjanagadde wrote: > On Wed, Dec 2, 2015 at 10:37 AM, Claudio Freire > wrote: >> So, here comes the discussion again. >> >> This time, the AAC encoder is in good shape. It's not perfect. I have >> a list of known bugs to address that still has some issues, but I'm >> not really certain whether they should block the flag's removal. >> >> The bugs will be addressed in time, but maybe the encoder is in good >> enough shape as it is? > > IIUC, JBK responded at VDD 2015 to the question of for which types of > files they don't use avcodec. He mentioned AAC due to some user's > complaints about quality on certain files. This was likely referring > to the decoder and not encoder. Nevertheless, I suggest a conversation > with them (or other users) to obtain problematic files to test. I'm always on the lookout for problematic files to add to my "test samples" collection, so if anyone has one they should contact me in private. In fact fate needs a few more samples since most of the samples there fail to trigger any of the bugs we've been working on of late. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 2, 2015 at 12:50 PM, Hendrik Leppkes wrote: > On Wed, Dec 2, 2015 at 4:42 PM, Clément Bœsch wrote: >> On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote: >>> So, here comes the discussion again. >>> >>> This time, the AAC encoder is in good shape. It's not perfect. I have >>> a list of known bugs to address that still has some issues, but I'm >>> not really certain whether they should block the flag's removal. >>> >> >> What kind of bugs? If it's crashes, I think they should be fixed before >> removing the flag (for security reasons). > > > Maybe the other coders could just be disabled unless the experimental > flag is set, and only allow twoloop otherwise. That's not a bad idea in fact. But yeah, the issue is that they might crash. I don't know, because they haven't been tested enough. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
Dana 2. 12. 2015. 16:54 osoba "Nicolas George" napisala je: > > Le duodi 12 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > > He mentioned AAC due to some user's > > complaints about quality on certain files. This was likely referring > > to the decoder and not encoder. > > I remember it about the MP3 decoder compared to libmp3, not AAC. > It it on range of golden cables. > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
Le duodi 12 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > He mentioned AAC due to some user's > complaints about quality on certain files. This was likely referring > to the decoder and not encoder. I remember it about the MP3 decoder compared to libmp3, not AAC. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 2, 2015 at 10:37 AM, Claudio Freire wrote: > So, here comes the discussion again. > > This time, the AAC encoder is in good shape. It's not perfect. I have > a list of known bugs to address that still has some issues, but I'm > not really certain whether they should block the flag's removal. > > The bugs will be addressed in time, but maybe the encoder is in good > enough shape as it is? IIUC, JBK responded at VDD 2015 to the question of for which types of files they don't use avcodec. He mentioned AAC due to some user's complaints about quality on certain files. This was likely referring to the decoder and not encoder. Nevertheless, I suggest a conversation with them (or other users) to obtain problematic files to test. If it works fine wrt users (who really are the main people affected by removal of such "strict" flags), and the more immediate possible concerns of Clement are met, then I am ok with this change. Or in other words, for me removal of the flag is "stable beyond fuzzing/security, and stable for integration by important users". If there are known crashes, it is an immediate nack from me. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 2, 2015 at 4:42 PM, Clément Bœsch wrote: > On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote: >> So, here comes the discussion again. >> >> This time, the AAC encoder is in good shape. It's not perfect. I have >> a list of known bugs to address that still has some issues, but I'm >> not really certain whether they should block the flag's removal. >> > > What kind of bugs? If it's crashes, I think they should be fixed before > removing the flag (for security reasons). Maybe the other coders could just be disabled unless the experimental flag is set, and only allow twoloop otherwise. > > If it's about efficiency (regarding compression or speed), I don't think > it should be blocking the drop of the flag. > > Note that dropping the flag means it will be a white flag for the > beginning of extended tests & benchmarks > > Regards, > > [...] > > -- > Clément B. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote: > So, here comes the discussion again. > > This time, the AAC encoder is in good shape. It's not perfect. I have > a list of known bugs to address that still has some issues, but I'm > not really certain whether they should block the flag's removal. > What kind of bugs? If it's crashes, I think they should be fixed before removing the flag (for security reasons). If it's about efficiency (regarding compression or speed), I don't think it should be blocking the drop of the flag. Note that dropping the flag means it will be a white flag for the beginning of extended tests & benchmarks Regards, [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] AAC experimental flag: the sequel
So, here comes the discussion again. This time, the AAC encoder is in good shape. It's not perfect. I have a list of known bugs to address that still has some issues, but I'm not really certain whether they should block the flag's removal. The bugs will be addressed in time, but maybe the encoder is in good enough shape as it is? It needs more testing. My tests have all been centered on one configuration: AAC-LC + PNS + M/S + I/S, ABR, twoloop coder. I haven't yet thoroughly tested any other configuration, or any other coder, and it's possible the other coders are kaputt. I have plans for the other coders but they haven't been fleshed out yet. There are two possibilities here: 1. Wait until the other coders at least don't crash before removing the flag 2. Remove the flag now, and document the other coders' instability Which one to go for depends a lot on what removing the flag means to other people. Does it mean "it is stable" or does it mean "it's stable for most uses"? (a subtle but important distinction). IE: what's the contract between us developers and users when we remove the flag? I'm rather new at this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
