[FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support
Paul B Mahol
onemda at gmail.com
Tue Oct 17 18:48:42 EEST 2017
On 10/17/17, Moritz Barsnick <barsnick at 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
> 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.
More information about the ffmpeg-devel