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 1DCEB49AFA for ; Tue, 2 Apr 2024 05:26:08 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5CD4768D193; Tue, 2 Apr 2024 08:25:17 +0300 (EEST) 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 3B6B768D0B0 for ; Tue, 2 Apr 2024 08:25:09 +0300 (EEST) Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (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 4V7xCk50L7z9sZq for ; Tue, 2 Apr 2024 07:25:06 +0200 (CEST) Message-ID: Date: Tue, 2 Apr 2024 10:55:05 +0530 MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org References: <9be400cf-949f-4eb1-93a1-b352a1b807e6@gyani.pro> Content-Language: en-US From: Gyan Doshi In-Reply-To: <9be400cf-949f-4eb1-93a1-b352a1b807e6@gyani.pro> X-Rspamd-Queue-Id: 4V7xCk50L7z9sZq Subject: Re: [FFmpeg-devel] FFmpeg TC input needed 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: Ping. As the TC rules matter has been concluded, this should go ahead. Regards, Gyan On 2024-02-17 05:15 pm, Gyan Doshi wrote: > Issue: > > Patch: avcodec/s302m: enable non-PCM decoding > URL: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffmpeg@gyani.pro/ > > The issue needing resolution is whether the patch should be added to > the existing s302m decoder or should that decoder > be removed and all old and new patched features inlined into the > mpeg-ts demuxer. > > Summary: > > SMPTE ST 302 specifies for carriage of LPCM media in MPEG-TS. SMPTE ST > 337 enables this for non-PCM codecs. The payload > has a custom layout so it can't be directly processed hence lavc/s302m > decodes the packet data to yield LPCM media. But > it can only deal at present with LPCM payloads, meaning that non-PCM > payloads need to be exported to a raw bytestream > format and then decoded in a 2nd step, which prohibits direct > transcoding of live/streaming inputs. This patch corrects > the identification process for non-PCM payloads, reformats the payload > and then carries out in-place decoding by calling > a nested decoder similar to the ftr or imm5 decoders in lavc. > > In the v1 patch review, Andreas, in response to the proposed doc entry > describing the feature capability of multiple > or differing payloads in a s302m stream, suggested[1] that s302m > should be a bitstream filter instead, but I did not > see that as an actionable suggestion as he immediately listed the bsf > limitations preventing the possibility. I also > had not seen an actual sample of s302m with multiple embedded streams. > Kieran also observed[2] that he had not seen > such a stream in the wild. So the added features of this patch, > wherever they are ultimately located, shall not yield > more than one media stream. Anton suggested[3] that the decoder should > instead be a demuxer. I saw no other objections > to the architecture of the patch. > > I posted the v2 patch, incorporating some changes suggested by > Andreas, 4 days later. This had gone uncommented for > over two weeks when I posted a notice stating an intention to push. > Anton posted[4] a new objection that "If it > dynamically generates nested decoders, then it's not a proper codec in > our model". This new objection is not connected > to multiple streams but only to a codec 'model' that I don't see > described anywhere and which contradicts the > implementations of multiple decoders with a nested decoder, including > the ftr and imm5 decoders, which are most similar > in design to the patched s302m decoder. Anton later on mentioned[5] > that nested decoders are "a constant source of > issues". However, I didn't find anything on trac reporting an issue > with the nested decoders of ftr and imm5 nor > anything on ffmpeg-devel-ml or ffmpeg-user-ml. Nothing in their commit > history either points to architectural bugs. > These decoders have been around for 6 years among themselves. The > testing of the patched s302m decoder over the past > month by myself, an OTT provider and others shows no issues either. > Finally, Anton speculates[6] that the burden of > fixes will likely fall upon him. In none of his objections, till the > time of writing, did I see specific concerns with > the patch. > > There are some limitations in shifting this decoder wholesale to > inside the MPEG-TS demuxer. A s302m stream may contain > some non-media payload accompanying non-PCM media i.e. S-ADM metadata. > At present, I have neither the samples nor the > specification needed in order to locate and extract or parse this > metadata. Formatting the payload data inside the > demuxer will lead to irrevocable loss of such metadata if present. > However, a decoder patch allows simultaneuous output > of both a decoded stream alongside a copied stream. The end-user can > then do with the raw data whatever they wish. > > Ultimately, s302m is specified an an elementary stream inside a > MPEG-TS container. Its internal handling is better left > to a dedicated module like a decoder. A bitstream filter might be a > better fit if s302m streams with multiple media > payloads ever start appearing - none have, so far - but for single > media payloads, a decoder remains the best place. > > Regards, > Gyan > > [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320119.html > [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320321.html > [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320258.html > [4]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321514.html > [5]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321523.html > [6]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321539.html > > _______________________________________________ > 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". _______________________________________________ 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".