On 10/17/17, Moritz Barsnick <barsn...@gmx.net> wrote: > On Tue, Oct 17, 2017 at 11:12:46 -0400, Dave Rice wrote: > >> Thanks for pointing me in the right direction. I am attaching an >> updated patch below; however, after removing my 16/32 and using the >> enumeration method (with the patch below), it accepts any value >> between AUDIO_BITDEPTH_LOWEST and AUDIO_BITDEPTH_NB-1 (16 and 32). >> When I enter any value from 17 through 31 then the output is still in >> pcm_s16le, however the resulting audio is slow and choppy (I'm >> guessing from the pkt.size line). Am I missing some method to say >> that the enumeration list is restrictive? > > Yes, that was exactly the oversight I had. The const'ified option now > takes those strings, but also numbers within the range. So the option > value "16" will be either "16" (string) or 16 (or integer), "17" will > be interpreted as integer 17 (and still valid thanks to the range), and > so on. My bad. > > So I guess it's stupid to use a string enum to represent a number > value. You could properly restrict its use to the enumerated values if > they were subsequent (i.e. 0, 1), and perhaps strings with letters for > the enumerated options. But that's totally unintuitive. It would result > in (auto doc): > > -audio_depth <int> .D...... audio bitdepth (from 0 to 1) > (default 16bits) > 16bits .D...... > 32bits .D...... > > and you could use it with either > -audio_depth 0 # 16 bits > -audio_depth 1 # 32 bits > -audio_depth 16bits # 16 bits > -audio_depth 32bits # 16 bits > but not > -audio_depth 16 > > Horrible! > > Your original version was most intuitive, IMHO. Sorry for explaining > the concept. ;-) It fits well for anything representable by strings, > not numbers.
Hmm, first patch might be enough. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
