Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Nicolas Gaullier <nicolas.gaullier@cji.paris>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution
Date: Tue, 21 Feb 2023 10:43:10 +0000
Message-ID: <MR1P264MB24835723335B9DEC35EC64B89BA59@MR1P264MB2483.FRAP264.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <50aca536d2be633d23e66dab0457e47b8cde9981.camel@haerdin.se>

>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.).

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

In ffmpeg, we already have spdif probing in wav, so there is nothing really new technically speaking.
Quoting the previous dolby paper, about spdif (IEC61937):
The IEC61937 format is similar to the SMPTE 337M format and can be considered a subset of SMPTE 337M
for some data types (see SMPTE 337M Section 7), however there are significant differences in the two standards.
In particular IEC61937 does not support the Dolby E data type.

Nicolas
_______________________________________________
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".

  reply	other threads:[~2023-02-21 10:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 18:09 [FFmpeg-devel] [PATCH 0/6] wavdev: s337m support Nicolas Gaullier
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 1/6] avformat/s337m: Split read_packet/get_packet Nicolas Gaullier
2023-02-16 10:36   ` Tomas Härdin
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution Nicolas Gaullier
2023-02-16 10:36   ` Tomas Härdin
2023-02-17  9:44     ` Nicolas Gaullier
2023-02-21  9:47       ` Tomas Härdin
2023-02-21 10:43         ` Nicolas Gaullier [this message]
2023-02-22 10:07           ` Tomas Härdin
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 3/6] avformat/s337m: New ff_s337m_probe() Nicolas Gaullier
2023-02-16 10:36   ` Tomas Härdin
2023-02-17 10:12     ` Nicolas Gaullier
2023-02-21  9:41       ` Tomas Härdin
2023-02-21 10:57         ` Nicolas Gaullier
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 4/6] avformat/wavdec: s337m support Nicolas Gaullier
2023-02-16 10:36   ` Tomas Härdin
2023-02-17 10:30     ` Nicolas Gaullier
2023-02-21  9:53       ` Tomas Härdin
2023-02-21 12:30         ` Nicolas Gaullier
2023-02-22 10:10           ` Tomas Härdin
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 5/6] avformat/wavdec.c: Reindent after last commit Nicolas Gaullier
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 6/6] avformat/wavdec: Test s337m Nicolas Gaullier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MR1P264MB24835723335B9DEC35EC64B89BA59@MR1P264MB2483.FRAP264.PROD.OUTLOOK.COM \
    --to=nicolas.gaullier@cji.paris \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git