[FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Paul B Mahol]

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
>
> 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.