From: Devin Heitmueller <devin.heitmueller@ltnglobal.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] decklink: Add support for compressed AC-3 output over SDI
Date: Fri, 17 Mar 2023 08:43:12 -0400
Message-ID: <CAHGibzFy_ODJ_zJjgOdnBa1-3G1jVR6LBw3S35jeLqj-jkhcqw@mail.gmail.com> (raw)
In-Reply-To: <9657e20-9ff0-4ee-934f-76dd9c9116de@passwd.hu>
On Mon, Mar 13, 2023 at 7:38 PM Marton Balint <cus@passwd.hu> wrote:
> > /* The device expects the sample rate to be fixed. */
> > - avpriv_set_pts_info(st, 64, 1, c->sample_rate);
> > - ctx->channels = c->ch_layout.nb_channels;
> > + avpriv_set_pts_info(st, 64, 1, bmdAudioSampleRate48kHz);
>
> I'd rather not use a BMD constant for non-BMD function. Make this 48000 or
> create a non-BMD 48000 constant and use it here and when checking the
> sample rate earlier.
Ok, good point. Will change to 48000.
>
> >
> > ctx->audio = 1;
> >
> > return 0;
> > }
> >
> > +static int create_s337_payload(AVPacket *pkt, enum AVCodecID codec_id, uint8_t **outbuf, int *outsize)
> > +{
> > + uint8_t *s337_payload;
> > + uint8_t *s337_payload_start;
> > + int i;
> > +
> > + if (codec_id != AV_CODEC_ID_AC3)
> > + return AVERROR(EINVAL);
>
> Use the PutByteContext for this function.
Ok.
> > - if (ctx->dlo->ScheduleAudioSamples(pkt->data, sample_count, pkt->pts,
> > + if (st->codecpar->codec_id == AV_CODEC_ID_AC3) {
> > + /* Encapsulate AC3 syncframe into SMPTE 337 packet */
> > + int outbuf_size;
> > + ret = create_s337_payload(pkt, st->codecpar->codec_id,
> > + &outbuf, &outbuf_size);
>
> Can't you create a buffer on the stack instead of using a dynamic
> memory allocation for each frame? I guess the S337 packet should never
> exceed the uncompressed size, but AC3 might have even more strict frame
> size limits.
I generally avoid putting things on the stack which are of
indeterminate size. Also, I've got a patch coming which has to make a
copy of all audio data (to interleave different audio streams together
prior to output). In that case heap usage is unavoidable and thus I
didn't think it was worthwhile to allocate a 1500+ byte stack buffer.
> > + if (ret)
> > + return ret;
> > + sample_count = outbuf_size / 4;
>
> How is it ensured that enough raw audio data is provided for Decklink? Or
> we provide "sparse" audio data to the decklink API, and decklink will
> pad the audio with silence based on the packet timestamps?
This patch relies on the hardware automatically padding the audio
(which does work correctly). I have a subsequent patch which always
inserts empty audio if there are gaps (as part of the work to
interleave multiple audio streams).
I will submit a revised version of the patch incorporating your
comments. Thanks for reviewing!
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com e: devin.heitmueller@ltnglobal.com
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
prev parent reply other threads:[~2023-03-17 12:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 14:08 Devin Heitmueller
2023-03-10 7:44 ` Nicolas Gaullier
2023-03-10 14:36 ` Devin Heitmueller
2023-03-10 16:25 ` Nicolas Gaullier
2023-03-13 23:38 ` Marton Balint
2023-03-17 12:43 ` Devin Heitmueller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHGibzFy_ODJ_zJjgOdnBa1-3G1jVR6LBw3S35jeLqj-jkhcqw@mail.gmail.com \
--to=devin.heitmueller@ltnglobal.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git