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 4FE7848C3C for ; Tue, 23 Jan 2024 08:32:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A78BE68CDFB; Tue, 23 Jan 2024 10:32:56 +0200 (EET) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5C36E6881B1 for ; Tue, 23 Jan 2024 10:32:49 +0200 (EET) Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.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-102.mailbox.org (Postfix) with ESMTPS id 4TK0hb12Cnz9sWy for ; Tue, 23 Jan 2024 09:32:47 +0100 (CET) Message-ID: <701ee720-c82e-4149-ae2a-a8d75b70f349@gyani.pro> Date: Tue, 23 Jan 2024 14:02:44 +0530 MIME-Version: 1.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20240123064948.455-1-ffmpeg@gyani.pro> From: Gyan Doshi In-Reply-To: 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-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: On 2024-01-23 01:26 pm, Kieran Kunhya wrote: > On Tue, 23 Jan 2024 at 06:50, Gyan Doshi wrote: > >> Set up framework for non-PCM decoding in-place and >> add support for Dolby-E decoding. >> >> Useful for direct transcoding of non-PCM audio in live inputs. >> > Does this handle a Dolby E packet spanning multiple S302M packets? I'm not > saying you should support this as it's rare and very annoying to implement > but it does happen. No, this does not handle spanned payload. I have access to a sample where it looks like the packetizer got mis-aligned and I think cases like those are better handled by a parser. Adding support for multiple payload packets in one 302m packet is on my to-do although the parser is better suited for that as well as the last payload packet might be fragmented. Regards, Gyan _______________________________________________ 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".