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.
Moritz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
