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 731D848726 for ; Thu, 15 Feb 2024 20:26:28 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 396A068D28B; Thu, 15 Feb 2024 22:26:26 +0200 (EET) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 480E268D27F for ; Thu, 15 Feb 2024 22:26:19 +0200 (EET) Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-6e09493eb8eso1919670b3a.1 for ; Thu, 15 Feb 2024 12:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ob-encoder-com.20230601.gappssmtp.com; s=20230601; t=1708028777; x=1708633577; 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=DXGgfGRfOnT0YF1u6dKYaUMvyfgORgK+R/GooiE+qiQ=; b=lw2si2qkENJBlVjPl0gcTNwcQa984LlqfN3cWHCCGsAOOPS8sb02rqMIb13HtyyDHc g3/hs5VJg0QwEQsRG7rJDO7SBID7haO12lBanRTtxbtV/zf59XjPEVJrfdriCApm4duP DpReEOzzhIEE5db5sEkJ4TudokD80DSZM5ofUGxrgK8K5a1aS0DgnT3sf/PfXTydSTwo m9yRdb0+dKd7Zt/p/uQbkhvJKfZ+AEFbWCcz8v6vhP8UY8+lZfb7xDZ/ctwXnUOOpxgm +qYB513vOaTHGrasXzsxgTm+wNYqqkFAq1FTEyXQE+QX1QvHpRePI2PuE98EqEEQuuXw NJSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708028777; x=1708633577; 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=DXGgfGRfOnT0YF1u6dKYaUMvyfgORgK+R/GooiE+qiQ=; b=OC10XWnHTXr9iaaqYrUJOqGYw0UQtdtNdhbZ7bs+IZt1u37JYbp/lx5Obcttxq5DeP 0RHbL/+0jkO7WOrdGWPtUOycPSE3CT4XQgTz4h5tc3IcgFUz+uoZs7jxNUsu1qJPEp5s sVLUSO7Y0MfaWdZiG0kevUwJGhN0WWOTBvzQp74B1wQxe5GkEHJM9jFEPCq7uOC9FVGM EV5SLViK5BgiZIu6gakK2s4YZ546vrgh1WRSSF/NXNbN9aBeka42BJL0wEp+FNF/9tE0 ZuK5ZJGeT89/53BCbU4ohmBTY7y3WzQBixki/0sxamxMMzlA9B4kkb1YFaDyGi/a2er1 Zmnw== X-Gm-Message-State: AOJu0YzgxReE5UcVPvpfVZuEnhhJd83w97hBkiRkOa+4UKXWly5y3ZFJ PJHtey/ExF5fzmVkf4ji5cYzKR5bMtdOUEDvBjzBbs8rx9I2yxCvi7fv3IVXX72hL2IVUJ0FLnH sHAkw+ggGJe9HBKTJiOQBfpIeiSUGzveTZMGJVAlJC64DQu6r X-Google-Smtp-Source: AGHT+IFDuJYBbuIcFX+ecjCQcBahxwnaxj2QVPJ/rgE6q0tprXvHRIfNE5Q6IIp7qqc8dYlUj/dyUrjmkSzDxOQxXBo= X-Received: by 2002:a17:902:cec7:b0:1db:a332:f426 with SMTP id d7-20020a170902cec700b001dba332f426mr530122plg.6.1708028776478; Thu, 15 Feb 2024 12:26:16 -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> <170799405543.32390.14003661310804711658@lain.khirnov.net> <0c3c8b9b-927e-470d-9272-67536279ba15@gyani.pro> <170801340414.21676.5189683358387742257@lain.khirnov.net> In-Reply-To: From: Kieran Kunhya Date: Thu, 15 Feb 2024 20:26:08 +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 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. 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".