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 2FD0E46578 for ; Sat, 17 Feb 2024 11:46:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5DEB068D278; Sat, 17 Feb 2024 13:45:59 +0200 (EET) Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0D8A668D24D; Sat, 17 Feb 2024 13:45:48 +0200 (EET) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::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-101.mailbox.org (Postfix) with ESMTPS id 4TcRnj2N1Tz9sd7; Sat, 17 Feb 2024 12:45:45 +0100 (CET) Message-ID: <9be400cf-949f-4eb1-93a1-b352a1b807e6@gyani.pro> Date: Sat, 17 Feb 2024 17:15:43 +0530 MIME-Version: 1.0 Content-Language: en-US To: FFmpeg development discussions and patches From: Gyan Doshi X-Rspamd-Queue-Id: 4TcRnj2N1Tz9sd7 Subject: [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 Cc: tc@ffmpeg.org 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: 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".