From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id CC59C48E43 for ; Mon, 29 Jan 2024 10:19:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4681C68D1E6; Mon, 29 Jan 2024 12:19:04 +0200 (EET) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A73AF68CCB5 for ; Mon, 29 Jan 2024 12:18:58 +0200 (EET) Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1d8ef972451so1532555ad.2 for ; Mon, 29 Jan 2024 02:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ob-encoder-com.20230601.gappssmtp.com; s=20230601; t=1706523535; x=1707128335; darn=ffmpeg.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=0jzWcoaRHaigsKREReVx3xPhEMQVS4G8gsewDd9C8Zg=; b=CSfhU/FvHT5Qg+q1ixatsXHax1zjZYDKHqWwU5clYPOzikiY+NQ3Gu2/P6qudZvypA 7oJGyStVcC+UEJ47MfTeqN+v/kE8s5CA3NBD6gUdD0ljR57NW+sIsz5rNq/4TZKSkQiB VrVfYvvTvV13NQ7PpdMtJ8jteKfrftm7EUYjQ7uszM9DorOzLfZSHISpj+D1kfMIEpG1 MZQ96DJ719J7wKiDornv6GjnJKI5S3ac43rVhZvpVPp/twkSBd37KGgXHFJ7alrdLNDB ArS5WfnUSyxg3SsCguI6/5zmZ43gDsxMF1WsRuFMv4HK1IQHKMQ0Rj1zcVmFZwEpK4lA k2Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706523535; x=1707128335; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0jzWcoaRHaigsKREReVx3xPhEMQVS4G8gsewDd9C8Zg=; b=Z8tbqmXQwtG3LM7Vrt42HO2aclqAbkHmphnEksdyyRpzjP1pM54v9cpcnI2alDeODP G/pLMQMUc2YFqVwoW9d4CbQucRGNV6dZP+1NI7aKwMBfK+0BhNj8wfAyLPfeXApxhFDr ED3MAz7qqjt8T/4ES6skIO/dGJs4qThXNddiUKm1m7EMYme9rUsVfbfMUi5e3uZJrxyg YQGPSuYacqbY/rGr+3jIt17QB803N4INvQAl3oPA03GGtk4ODTIjzutixLVPNLesuZ+F BtRLCdoJQpsNk8luFe5BeANcQNfidyVRrQAZ0VfFQuPUfyH+lgpRlIUtJlC1UjWdJxqi VgWA== X-Gm-Message-State: AOJu0YzQGz5LcNPOW2R01bDYyqy3T4Okn52nooPFvvgYLkcpjpHleqi9 IUxce7jrPBTq2beKacJoeXgDW7gyxMckgHcs+ITMcpAPKN9LZK6BZOb4sgbaM5BK6NYHUAOYCK0 1SY/lyq32xVS7p8/4gSv7FVtLNBUMAe9hRnS0n0M9/pWYGjJT/ZA= X-Google-Smtp-Source: AGHT+IGRQa8CVDpM0T4sAaE4WC0bQkkiHTFwP/90czTZbs7ncfGhbXosQYxXpsTcTUv2O+FekyBwsHkE2F5PPhBtGUw= X-Received: by 2002:a05:6a20:9f87:b0:19b:1eda:ab61 with SMTP id mm7-20020a056a209f8700b0019b1edaab61mr2979934pzb.54.1706523535424; Mon, 29 Jan 2024 02:18:55 -0800 (PST) MIME-Version: 1.0 References: <20240123064948.455-1-ffmpeg@gyani.pro> <36aab7a2-3590-4cc1-aeb4-8805d6484de9@gyani.pro> <677047fe-11e4-4a62-a003-912471ff81ef@gyani.pro> <170643927262.8914.6288212134706680203@lain.khirnov.net> <594a2da4-0693-483e-82ab-2924b16d8dbb@gyani.pro> <3d088020-574a-4432-8457-b895f8235334@gyani.pro> In-Reply-To: <3d088020-574a-4432-8457-b895f8235334@gyani.pro> From: Kieran Kunhya Date: Mon, 29 Jan 2024 10:18:45 +0000 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Mon, 29 Jan 2024 at 10:17, Gyan Doshi wrote: > > > On 2024-01-29 02:57 pm, Nicolas Gaullier wrote: > >> On 2024-01-28 04:24 pm, Anton Khirnov wrote: > >>> Quoting Gyan Doshi (2024-01-26 05:23:50) > >>>> On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote: > >>>>> Gyan Doshi: > >>>>>>> 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 > >>>>> Then why does the demuxer not separate the data into multiple > streams? > >>>> I didn't add demuxing support for this codec in MPEGTS, but I can > >>>> venture > >>>> > >>>> a) it would mean essentially inlining this decoder in the demuxer. > >>> Why is that a problem? This decoder seems like it shouldn't be a > >>> decoder. > >>> > >>> I agree with Andreas that this seems like it's a demuxer pretending to > >>> be a decoder. > >> This module transforms the entire raw payload data to generate its > output, even if the syntax is simple which essentially makes it a de-coder. > The de-multiplexer aspect of multiple streams is an academic possibility > allowed by the >standard but not seen in any sample which makes me suspect > it's used for carriage between broadcast facilities rather than something > ever sent to an OTT provider, let alone an end user. > >> > >> Regards, > >> Gyan > > AFAIK, DolbyE may be found on satellite feeds, for carriage between > broadcast facilities, and thus it makes them accessible so they may be > grabbed by "end users". Otherwise, it is "broadcast professional end > users", which are users too. AFAIK, its most common form is 20Bits and you > simply "cannot" have a single stream in a 20Bit carrier; but indeed, most > of the time only the first stream ("program") is used and the second is a > downmix; but not always. For example, you can have a first program which is > standard 5.1 and a second program with Audio Description. > In the samples I have, including yours, the outermost layer is AES3 > which contains one inner stream Dolby-E, which in turn contains 8 > channels constituting multiple programs. Those are programs downstream > of the dolby_e decoder. That's not what we are talking about. The > discussion here is about multiple payload streams within the AES3 layer > - streams stored in subframe mode e.g. a Dolby-E and AC-3 or LPCM in > alternate subframes/frames. I've no such samples of that sort. > I have not seen such streams in the wild. Kieran _______________________________________________ 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".