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 E2B2C49CCE for ; Mon, 8 Apr 2024 13:12:57 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6574668D276; Mon, 8 Apr 2024 16:12:54 +0300 (EEST) 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 43EF868CF0F; Mon, 8 Apr 2024 16:12:42 +0300 (EEST) Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.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 4VCqJR2CD7z9sj8; Mon, 8 Apr 2024 15:12:39 +0200 (CEST) Message-ID: Date: Mon, 8 Apr 2024 18:42:36 +0530 MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org, tc@ffmpeg.org References: <9be400cf-949f-4eb1-93a1-b352a1b807e6@gyani.pro> Content-Language: en-US From: Gyan Doshi In-Reply-To: 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 x2. On 2024-04-02 10:55 am, Gyan Doshi wrote: > 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". _______________________________________________ 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".