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 BA6A449674 for ; Fri, 16 Feb 2024 04:12:27 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B5EA368D200; Fri, 16 Feb 2024 06:12:25 +0200 (EET) Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D71A068D150 for ; Fri, 16 Feb 2024 06:12:18 +0200 (EET) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (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-103.mailbox.org (Postfix) with ESMTPS id 4Tbdmw1pLBz9sf2 for ; Fri, 16 Feb 2024 05:12:16 +0100 (CET) Message-ID: Date: Fri, 16 Feb 2024 09:42:15 +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> <170801340414.21676.5189683358387742257@lain.khirnov.net> Content-Language: en-US From: Gyan Doshi In-Reply-To: X-Rspamd-Queue-Id: 4Tbdmw1pLBz9sf2 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 01:56 am, Kieran Kunhya wrote: > On Thu, 15 Feb 2024 at 16:48, Gyan Doshi wrote: > >> >> On 2024-02-15 09:40 pm, Anton Khirnov wrote: >>> Quoting Gyan Doshi (2024-02-15 13:31:59) >>>> 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. >>> I don't see why specifically this property should be the one >>> distinguishing demuxers from decoders, it sounds pretty arbitrary to me. >>> Many demuxers apply transformations of far higher complexity to the >>> bytestream before exporting it, e.g. in matroska the packet data may be >>> compressed, laced, etc. >>> >>>> And the stream extracted from the container is meant to be SMPTE ST >>>> 302 not PCM* or Dolby-E/AC-3..etc, >>> "meant to be"? By whom? >>> >>> The point of libavformat is to abstract away the differences between >>> containers as much as is reasonably feasible, and export the data in the >>> format most useful to the caller for decoding or other processing. >>> >>>> which will both misrepresent what the container carries >>> Why should the caller care? >>> >>>> and possibly discard S-ADM metadata, if present, in the packet. >>> Why could that not be exported as side data? >>> >>>> A bsf in principle would work but in practice, can't as Andreas >>>> clarified that bsfs can't set or alter codec_id after init. And >>>> resetting the codec id requires packet inspection. >>> There are two possibilities then - either extend the BSF API to support >>> multiple output streams, or implement it inside libavformat as a >>> post-demuxer hook called in the same place as parsing. >>> >>>> Nested decoders are used without issue in components like imm5 or ftr >>>> (upto 64 nested decoders!) among others. There's no breaking of new >>>> ground here. >>> Nested decoders are certainly not "without issue" - they are a constant >>> source of issues, since implementing nesting properly is very tricky. I >>> am fairly sure most nested decoders we have are subtly broken in various >>> ways. >> This patch facilitates a certain productive use of ffmpeg with respect >> to processing of live inputs that wasn't possible earlier, >> and which currently is being used successfully by multiple people over >> the past few weeks. >> It applies a processing model already implemented in multiple other >> decoders for a number of years. I haven't seen many reports >> of issues with them. And surely something being 'a constant source of >> issues' would be a lot more than 'subtly broken' as you describe >> them.You're the only one who has objected on architectural grounds and >> this looks to be a fundamental disagreement. >> If you are blocking this patch, do acknowledge here within 24 hours and >> we can send this to the TC else I'll push it after that period. >> > Dolby E can exist in other containers apart from S302M. Raising the TC is > premature. This patch only concerns s302m and sets up a framework for non-PCM decode. Dolby-E is incidental. 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".