From: Gyan Doshi <ffmpeg@gyani.pro>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
Date: Thu, 25 Jan 2024 12:41:30 +0530
Message-ID: <36aab7a2-3590-4cc1-aeb4-8805d6484de9@gyani.pro> (raw)
In-Reply-To: <AS8P250MB074454EDD9999DAE7785C6078F7A2@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM>
On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
> Gyan Doshi:
>> Set up framework for non-PCM decoding in-place and
>> add support for Dolby-E decoding.
>>
>> Useful for direct transcoding of non-PCM audio in live inputs.
>> ---
>> configure | 1 +
>> doc/decoders.texi | 40 +++
>> libavcodec/s302m.c | 609 +++++++++++++++++++++++++++++++++++++--------
>> 3 files changed, 543 insertions(+), 107 deletions(-)
>>
>> diff --git a/configure b/configure
>> index c8ae0a061d..8db3fa3f4b 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2979,6 +2979,7 @@ rv20_decoder_select="h263_decoder"
>> rv20_encoder_select="h263_encoder"
>> rv30_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
>> rv40_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
>> +s302m_decoder_select="dolby_e_decoder"
>> screenpresso_decoder_deps="zlib"
>> shorten_decoder_select="bswapdsp"
>> sipr_decoder_select="lsp"
>> diff --git a/doc/decoders.texi b/doc/decoders.texi
>> index 293c82c2ba..9f85c876bf 100644
>> --- a/doc/decoders.texi
>> +++ b/doc/decoders.texi
>> @@ -347,6 +347,46 @@ configuration. You need to explicitly configure the build with
>> An FFmpeg native decoder for Opus exists, so users can decode Opus
>> without this library.
>>
>> +@section s302m
>> +
>> +SMPTE ST 302 decoder.
>> +
>> +SMPTE ST 302 is a method for storing AES3 data format within an MPEG Transport
>> +Stream. AES3 streams can contain LPCM streams of 2, 4, 6 or 8 channels with a
>> +bit depth of 16, 20 or 24-bits at a sample rate of 48 kHz.
>> +They can also contain non-PCM codec streams such as AC-3 or Dolby-E.
>> +
> This sounds like we should add bitstream filters to extract the proper
> underlying streams instead.
> (I see only two problems with this approach: The BSF API needs to set
> the CodecID of the output during init, but at this point no packet has
> reached the BSF to determine it. And changing codec IDs mid-stream is
> also not supported.)
In theory, this decoder shouldn't exist, as it is just a carrier,
whether of LPCM or non-PCM.
FFmpeg architecture also imposes a fundamental limitation in that one
s302m stream may
carry multiple payload streams and we support only one decoding context
per input stream
neither can a bsf spawn streams (not sure). So proper, full support
seems not possible.
[...]
>> +
>> + ret = init_get_bits8(&gb, buf, buf_size);
>> + if (ret < 0)
>> + return ret;
>> +
>> + aes_frm_size = (s->bits + 4) * 2 / 8;
>> + if (buf_size < aes_frm_size * 2) // not enough to contain data_type & length_code
>> + return AVERROR_INVALIDDATA;
>> +
>> + state = get_bits64(&gb, aes_frm_size * 8);
>> +
>> + while (!IS_NONPCMSYNC(s->bits,state) && (get_bits_left(&gb) >= 8))
>> + state = (state << 8) | get_bits(&gb, 8);
> Reading byte-aligned data with a GetBit context is very suboptimal.
What is the performance difference vs. uint8 pointers?
Note that if stream is LPCM or non-decodable non-PCM, this isn't called
again. If it is Dolby-E, the data traversed can typically be measured in
the dozens of bytes. And further on, I do read and skip some
non-byte-aligned lengths.
[...]
>> +
>> + if (s->non_pcm_dec)
>> + for (int i = 0; i < 4; i++)
>> + *p++ = b[i];
>> + else {
>> + *f16++ = (b[0] << 8) |
>> + (b[1] ) ;
> AV_RB16(b)
Ok.
[...]
>> +
>> + for (int ch = 0; ch < s->frame->ch_layout.nb_channels; ch++)
>> + memcpy(frame->extended_data[ch], s->frame->extended_data[ch],
>> + av_get_bytes_per_sample(s->non_pcm_ctx->sample_fmt) * s->frame->nb_samples);
> Would you please explain to me why this extra frame s->frame exists at
> all? (Is it just the assert due to the missing FrameDecodeData? If so,
> then this should be changed instead.)
Yes, that assert was triggered. I haven't looked into the ramifications
of altering decode_receive_frame_internal and it's out of scope for this
patch.
If you feel strongly about it, I invite you to change that code and I'll
update this patch accordingly.
[...]
>> +static av_cold int s302m_close(AVCodecContext *avctx)
>> +{
>> + S302Context *s = avctx->priv_data;
>> +
>> + avcodec_free_context(&s->non_pcm_ctx);
>> + av_packet_free(&s->packet);
>> + av_frame_free(&s->frame);
>> + av_dict_free(&s->non_pcm_opts);
> non_pcm_opts is an av_opt-enabled field and is therefore freed generically.
Will remove.
Regards,
Gyan
_______________________________________________
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".
next prev parent reply other threads:[~2024-01-25 7:11 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 6:49 Gyan Doshi
2024-01-23 6:49 ` [FFmpeg-devel] [PATCH 2/2] fate: add tests for dolby_e decoding in s302m Gyan Doshi
2024-01-23 7:56 ` [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding Kieran Kunhya
2024-01-23 8:32 ` Gyan Doshi
2024-01-23 9:05 ` Kieran Kunhya
2024-01-23 14:50 ` Devin Heitmueller
2024-01-23 14:53 ` Kieran Kunhya
2024-01-23 15:04 ` Devin Heitmueller
2024-01-23 10:28 ` Nicolas Gaullier
2024-01-23 11:18 ` Gyan Doshi
2024-01-25 4:59 ` Andreas Rheinhardt
2024-01-25 7:11 ` Gyan Doshi [this message]
2024-01-25 13:17 ` Andreas Rheinhardt
2024-01-26 4:23 ` Gyan Doshi
2024-01-26 6:42 ` Andreas Rheinhardt
2024-01-28 10:54 ` Anton Khirnov
2024-01-28 21:29 ` Kieran Kunhya
2024-01-29 4:00 ` Gyan Doshi via ffmpeg-devel
2024-01-29 9:27 ` Nicolas Gaullier
2024-01-29 10:17 ` Gyan Doshi
2024-01-29 10:18 ` Kieran Kunhya
2024-02-15 10:47 ` Anton Khirnov
2024-02-15 12:31 ` Gyan Doshi
2024-02-15 16:10 ` Anton Khirnov
2024-02-15 16:47 ` Gyan Doshi
2024-02-15 20:26 ` Kieran Kunhya
2024-02-16 4:12 ` Gyan Doshi
2024-02-16 9:03 ` Anton Khirnov
2024-02-17 11:46 ` Gyan Doshi
2024-02-17 12:22 ` Anton Khirnov
2024-02-17 12:37 ` Gyan Doshi
2024-02-17 19:55 ` Anton Khirnov
2024-02-18 0:43 ` Michael Niedermayer
2024-02-18 18:20 ` Anton Khirnov
2024-02-18 22:34 ` Michael Niedermayer
2024-02-18 22:47 ` Vittorio Giovara
2024-02-19 8:45 ` Nicolas George
2024-02-19 14:15 ` Vittorio Giovara
2024-02-19 14:28 ` Nicolas George
2024-02-19 14:37 ` Vittorio Giovara
2024-02-19 14:41 ` Nicolas George
2024-02-18 22:48 ` Hendrik Leppkes
2024-02-19 1:17 ` Michael Niedermayer
2024-02-19 2:26 ` Vittorio Giovara
2024-02-19 2:07 ` Ronald S. Bultje
2024-02-19 21:37 ` Anton Khirnov
2024-02-19 21:54 ` Nicolas George
2024-02-20 21:39 ` Michael Niedermayer
2024-02-20 21:56 ` Kieran Kunhya
2024-02-20 22:07 ` Nicolas George
2024-02-18 18:50 ` Rémi Denis-Courmont
2024-02-18 18:55 ` Nicolas George
2024-02-18 4:06 ` Gyan Doshi
2024-02-18 18:03 ` Anton Khirnov
2024-02-18 18:40 ` Nicolas George
2024-02-18 19:03 ` Rémi Denis-Courmont
2024-02-18 19:11 ` Nicolas George
2024-02-18 21:06 ` Vittorio Giovara
2024-02-18 21:25 ` Nicolas George
2024-02-18 21:55 ` Vittorio Giovara
2024-02-19 8:54 ` Nicolas George
2024-02-19 14:21 ` Vittorio Giovara
2024-02-19 14:30 ` Nicolas George
2024-02-19 14:33 ` Vittorio Giovara
2024-02-19 14:34 ` Nicolas George
2024-02-18 19:02 ` Gyan Doshi
2024-02-18 21:46 ` Vittorio Giovara
2024-02-19 5:10 ` Gyan Doshi
2024-02-19 14:30 ` Vittorio Giovara
2024-02-19 15:39 ` Gyan Doshi
2024-02-20 3:02 ` Vittorio Giovara
2024-02-17 12:31 ` Rémi Denis-Courmont
2024-02-19 2:16 ` epirat07
2024-02-16 13:55 ` Andreas Rheinhardt
2024-02-17 11:44 ` Gyan Doshi
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=36aab7a2-3590-4cc1-aeb4-8805d6484de9@gyani.pro \
--to=ffmpeg@gyani.pro \
--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