[FFmpeg-devel] decklink 24/32 bit question

Submitted by ffmpeg@dx9s.net on Oct. 4, 2017, 3:39 a.m.

Details

Message ID 1e3594e415405a5899ec7be9730bb469@dx9s.net
State New
Headers show

Commit Message

ffmpeg@dx9s.net Oct. 4, 2017, 3:39 a.m.
After digging around in places, made the following changes:

dx@x299:~/git/ffmpeg$ git diff
      avpriv_set_pts_info(st, 64, 1, 1000000);  /* 64 bits pts in us */
@@ -1028,7 +1028,7 @@ av_cold int 
ff_decklink_read_header(AVFormatContext *avctx)
      }

      av_log(avctx, AV_LOG_VERBOSE, "Using %d input audio channels\n", 
ctx->audio_st->codecpar->channels);
-    result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz, 
bmdAudioSampleType16bitInteger, ctx->audio_st->codecpar->channels);
+    result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz, 
bmdAudioSampleType32bitInteger, ctx->audio_st->codecpar->channels);

      if (result != S_OK) {
          av_log(avctx, AV_LOG_ERROR, "Cannot enable audio input\n");


It doesn't work (the audio capture is close but wrong), but believe it 
is a step in the correct direction. Anybody have a clue? Saw several 
names in cpp,c,h files including: Ramiro Polla, Luca Barbato, Deti 
Fliegl, Rafaël Carré and Akamai Technologies Inc.

Thanks in advance!

--Doug (dx9s)

Comments

Moritz Barsnick Oct. 17, 2017, 6:59 p.m.
Hi Doug,

On Tue, Oct 03, 2017 at 20:39:49 -0700, Douglas Marsh wrote:
> After digging around in places, made the following changes:
[...]
> It doesn't work (the audio capture is close but wrong), but believe it 
> is a step in the correct direction. Anybody have a clue? Saw several 
> names in cpp,c,h files including: Ramiro Polla, Luca Barbato, Deti 
> Fliegl, Rafaël Carré and Akamai Technologies Inc.

Did you check out Dave Rice's recent patch (on this list)? It touches
code in a few more places, and adds an option to select 16 vs. 32 bits.
Please test, if you can.

Is your subject indicating that 24 bits depth could also be supported?
If so, Dave perhaps should expand his patch to cover that.

Moritz
Dave Rice Oct. 17, 2017, 7:12 p.m.
> On Oct 17, 2017, at 2:59 PM, Moritz Barsnick <barsnick@gmx.net> wrote:
> 
> Hi Doug,
> 
> On Tue, Oct 03, 2017 at 20:39:49 -0700, Douglas Marsh wrote:
>> After digging around in places, made the following changes:
> [...]
>> It doesn't work (the audio capture is close but wrong), but believe it 
>> is a step in the correct direction. Anybody have a clue? Saw several 
>> names in cpp,c,h files including: Ramiro Polla, Luca Barbato, Deti 
>> Fliegl, Rafaël Carré and Akamai Technologies Inc.
> 
> Did you check out Dave Rice's recent patch (on this list)? It touches
> code in a few more places, and adds an option to select 16 vs. 32 bits.
> Please test, if you can.
> 
> Is your subject indicating that 24 bits depth could also be supported?
> If so, Dave perhaps should expand his patch to cover that.

The decklink sdk only defines two BMDAudioSampleType values: bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I don't think there's an easy way to support a 24 bit input here. Generally in this case I've used bmdAudioSampleType32bitInteger and then encode it at pcm_s24le.
Dave Rice
ffmpeg@dx9s.net Oct. 17, 2017, 7:16 p.m.
On 2017-10-17 11:59, Moritz Barsnick wrote:

> Did you check out Dave Rice's recent patch (on this list)? It touches
> code in a few more places, and adds an option to select 16 vs. 32 bits.
> Please test, if you can.
> 
> Is your subject indicating that 24 bits depth could also be supported?
> If so, Dave perhaps should expand his patch to cover that.
> 

I did see it!

Been busy, trying to get a video project done and under the belt before 
I start tinkering with dependent things. I *WILL* report back my 
experiences (positive or negative). I was hacking the source before that 
patch and see the two areas that I missed. But his patch added command 
line parameters for selecting (which I prefer). Was going to try it out 
and change the default to 32-bit as well.

I am guessing that some capture hardware may not support higher than 16 
bit depths? If all support higher depths, then why should the default 
not be higher and then let FFMPEG convert the input stream to the 
correct output stream (it might be 16 bits)? Is truncating CPU 
intensive? Dithering be applied? What does the DAC do in hardware when 
outputting 16-bits (truncate or dither)?

Also from what I understand word/sample size is 32-bits but the DAC is 
24 (assuming 8-bits are padded) -- hence why I said 24/32. I only see in 
the SDK 16-bits and 32-bits, but know the documentation for the card I 
have (Studio 4K) states 24-bits. Do others have cards that state 
anything additional over 16 and 32?

--Doug (dx9s)
Devin Heitmueller Oct. 17, 2017, 7:44 p.m.
> 
> The decklink sdk only defines two BMDAudioSampleType values: bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I don't think there's an easy way to support a 24 bit input here. Generally in this case I've used bmdAudioSampleType32bitInteger and then encode it at pcm_s24le.
> Dave Rice

For what it’s worth, I’ve got deinterleaving code in the works to handle capture of multiple pairs of audio (i.e. break 16 channels into 8 pairs and announce them as separate S16LE streams).  If we really thought 24-bit was desirable, that code could be adjusted accordingly (the hardware would still capture 32-bit, but the deinterleaver would put out S24LE).

Devin

Patch hide | download patch | download mbox

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 3ce2cab..afd255f 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -937,7 +937,7 @@  av_cold int ff_decklink_read_header(AVFormatContext 
*avctx)
          goto error;
      }
      st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
-    st->codecpar->codec_id    = AV_CODEC_ID_PCM_S16LE;
+    st->codecpar->codec_id    = AV_CODEC_ID_PCM_S32LE;
      st->codecpar->sample_rate = bmdAudioSampleRate48kHz;
      st->codecpar->channels    = cctx->audio_channels;