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 5C299457E4 for ; Wed, 22 Feb 2023 10:07:22 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 367E568BFFE; Wed, 22 Feb 2023 12:07:19 +0200 (EET) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B795768BF69 for ; Wed, 22 Feb 2023 12:07:12 +0200 (EET) Received: from laptop.lan (h-79-136-39-105.A258.priv.bahnhof.se [79.136.39.105]) by mail.frobbit.se (Postfix) with ESMTPSA id D7CA82027A for ; Wed, 22 Feb 2023 11:07:11 +0100 (CET) Message-ID: <18c43fac75f979854574955788202ca0e710d8df.camel@haerdin.se> From: Tomas =?ISO-8859-1?Q?H=E4rdin?= To: FFmpeg development discussions and patches Date: Wed, 22 Feb 2023 11:07:11 +0100 In-Reply-To: References: <20230213180936.815-1-nicolas.gaullier@cji.paris> <20230213180936.815-3-nicolas.gaullier@cji.paris> <50aca536d2be633d23e66dab0457e47b8cde9981.camel@haerdin.se> User-Agent: Evolution 3.38.3-1+deb11u1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution 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: tis 2023-02-21 klockan 10:43 +0000 skrev Nicolas Gaullier: > > I haven't worked enough with S377m to really know, but I do know > > it's a mess. Is there a way to differentiate "regular" packed 20- > > bit audio from S377m in wav? > > > > /Tomas > > There is a relevant overview of S337m in this dolby paper: > https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-tech-doc_1.2.pdf > Page 25, one can read: > SMPTE 337M is the primary method by which Dolby E is able to work in > existing > facilities and with existing devices. The standard is written such > that the same AES3 > interface can be shared with the normal PCM audio usage either by > treating the AES3 > channels independently or by alternating between data and linear PCM > usage. > Devices that are specifically designed for SMPTE 337M/Dolby E > compatibility > should be able to transition easily between both usages. > > The whole design is to not signal, not differentiate "normal PCM > audio usage" from s337m. > And indeed, manufacturers have implemented probing in all their > hardware/software (be it linear/SDI input, or mxf/wav files input > etc.). Right, it's a deliberate mess. > Note: ARD/ZDF mxf file format being "the" world exception here, as > dolby_e/non-pcm must be signaled, made explicit: > > https://www.ard.de/ard/die-ard/ARD-ZDF-HDF02a-AVC-I-100-1080i-25-8-Audio-Tracks-100.pdf This is the correct approach and precisely what I would expect in the MXF space. You make it possible to probe in case you have stupid hardware, but you also explicitly signal it in the container for systems that are capable of carrying that over. I will note that Dolby-E support in mxfdec seems to have been in Baptiste's mind when he first committed the code: > //{ { > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x02,0x03,0x02 > ,0x1C,0x00 }, 15, AV_CODEC_ID_DOLBY_E }, /* Dolby-E */ Since ccba07d12c. It remains commented out to this day. Anyway I don't think this has to hold up this patchset. If it works it works. We can always improve this later if necessary. /Tomas _______________________________________________ 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".