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 3BB294870A for ; Thu, 15 Feb 2024 16:10:17 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9D1DC68D0ED; Thu, 15 Feb 2024 18:10:14 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 56F1F68D1C1 for ; Thu, 15 Feb 2024 18:10:07 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=lGcLYWO2; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 413AF240DA9 for ; Thu, 15 Feb 2024 17:10:05 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id Z0EpjLIj9pNi for ; Thu, 15 Feb 2024 17:10:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1708013404; bh=4TPPSrd/tngm2rEZBi/dN/2A0lWUFC+2HxHW6VDAgGc=; h=Subject:From:To:In-Reply-To:References:Date:From; b=lGcLYWO2QakkRSbrC2Ai4iN/JBu07s8oRg1bLeq4Pd6IXo4DKWaIiPU75FBJ7tKbG Xrcqzlr7Cd/Q9j9+VFFqO8kXwqAPNguGEPIye2WjcmiVZFfW4YPyLdW2M/eUFtSMC5 mdrurOQ1u5udB5SKUTWMxMpG6Ne5ktka0UK9ptKUk7oIWYoBK2veb0kKrc3bH6Ryy8 Vq8riW49WYO9bB5rvKbZswApiEqOz94bTuhtUkHQkgESECeDW/TsYH5YLu8HBHIVPu KPSEZ1Qd/q4VpAOuyKl0P8XFC32hBIY3GmlsNuz3IMGrgEWkVcMB6q7G1+XLUIoppA VQl+A6BWKsiEw== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 49D18240177 for ; Thu, 15 Feb 2024 17:10:04 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 2821A1601B9; Thu, 15 Feb 2024 17:10:04 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <0c3c8b9b-927e-470d-9272-67536279ba15@gyani.pro> 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> Mail-Followup-To: FFmpeg development discussions and patches Date: Thu, 15 Feb 2024 17:10:04 +0100 Message-ID: <170801340414.21676.5189683358387742257@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 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: 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. > If you feel strongly about this, please refer this to the TC. The TC is supposed to be invoked as a last resort. -- Anton Khirnov _______________________________________________ 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".