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