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 A1D9A456B2 for ; Sat, 17 Feb 2024 11:44:58 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0FC5468D26C; Sat, 17 Feb 2024 13:44:55 +0200 (EET) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C8CD068D13C for ; Sat, 17 Feb 2024 13:44:48 +0200 (EET) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4TcRmY4Gpmz9t2H for ; Sat, 17 Feb 2024 12:44:45 +0100 (CET) Message-ID: <86496c5d-a4d8-4505-9213-f7e372a94ec3@gyani.pro> Date: Sat, 17 Feb 2024 17:14:41 +0530 MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org 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> <170799405543.32390.14003661310804711658@lain.khirnov.net> <0c3c8b9b-927e-470d-9272-67536279ba15@gyani.pro> Content-Language: en-US From: Gyan Doshi In-Reply-To: X-Rspamd-Queue-Id: 4TcRmY4Gpmz9t2H 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2024-02-16 07:25 pm, Andreas Rheinhardt wrote: > Gyan Doshi: >> >> On 2024-02-15 04:17 pm, Anton Khirnov wrote: >>> Hi, >>> sorry for the delay, I've been busy fixing things for the release >>> Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33) >>>> On 2024-01-28 04:24 pm, Anton Khirnov wrote: >>>>>> 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. >>> If it dynamically generates nested decoders, then it's not a proper >>> codec in our model. It should be either a part of the demuxer, or a >>> bitstream filter (possibly inserted automatically by the demuxer). >> s302m is a hybrid creature and does not slot cleanly into any role. So >> there is no theoretically proper place for this component - any choice >> is a least-out-of-place accommodation. >> >> But it is much more out of place inside a demuxer. Analyzing packet >> payload and then manipulating that entire payload is much closer to a >> decoding role than data chunk extraction for packetization. And the >> stream extracted from the container is meant to be SMPTE ST 302 not PCM* >> or Dolby-E/AC-3..etc, which will both misrepresent what the container >> carries >> and possibly discard S-ADM metadata, if present, in the packet. With >> passthrough demuxing, a stream can be mapped for both decoding and >> streamcopying. > This is not true: It can not be streamcopied into formats expecting > ordinary PCM or Dolby-e/AC-3. Which is why exporting the data without > the unnecessary packetization is preferable. With this decoder patch, the packet exported from the demuxer remains s302m. That may contain either PCM or non-PCM payload[+ ADM metadata]. A streamcopied output into TS or raw data allows the user to parse out the ADM on their own. I don't have the standard or samples for ADM so I can't extract it with either a decoder or demuxer patch. If they want the non-PCM coded stream then they select the pre-existing method of non_pcm_mode copy in the decoder and a suitable pcm_* encoder to extract the coded stream, else set the non pcm mode to decode to obtain playable LPCM AVFrames. With a demuxer patch, the packet extracted from the demuxer is either PCM* or some non-PCM codec. The ADM portion if present is lost since there is no parser for it. And if we add an option for passthrough demuxing and leave the s302m decoder as it is, then we're back with the status quo of a 2-step transcoding pipeline. 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".