[FFmpeg-devel] [PATCH 2/3] avformat: Support s337m in mxf/wav/w64

[Tomas Härdin]

tis 2019-07-30 klockan 21:07 +0200 skrev Carl Eugen Hoyos:
> Am Di., 30. Juli 2019 um 21:04 Uhr schrieb Tomas Härdin <tjoppen at acc.umu.se>:
> > tis 2019-07-30 klockan 15:24 +0200 skrev Carl Eugen Hoyos:
> > > 
> > > > Am 30.07.2019 um 14:02 schrieb Tomas Härdin <tjoppen at acc.umu.se>:
> > > > 
> > > > fre 2019-07-26 klockan 18:45 +0200 skrev Nicolas Gaullier:
> > > > 
> > > > > diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> > > > > index 52194f54ef..501c21f220 100644
> > > > > --- a/libavformat/wavdec.c
> > > > > +++ b/libavformat/wavdec.c
> > > > > @@ -41,6 +41,7 @@
> > > > > #include "riff.h"
> > > > > #include "w64.h"
> > > > > #include "spdif.h"
> > > > > +#include "s337m.h"
> > > > > 
> > > > > typedef struct WAVDemuxContext {
> > > > >     const AVClass *class;
> > > > > @@ -593,6 +594,8 @@ break_loop:
> > > > >     } else if (st->codecpar->codec_id == AV_CODEC_ID_ADPCM_MS &&
> > > > > st-
> > > > > > codecpar->channels > 2) {
> > > > >         st->codecpar->block_align *= st->codecpar->channels;
> > > > >     }
> > > > > +    if (s->dolby_e_probe)
> > > > > +        s337m_probe_stream(s, &st);
> > > > 
> > > > The same goes here - these codecs should have corresponding TwoCCs.
> > > 
> > > There is definitely no TwoCCs for these kind of files, same as for
> > > DTS and AC-3. (I don't know about Dolby E in mxf.)
> > 
> > MXF has a UL registered for Dolby-E:
> > urn:smpte:ul:060e2b34.04010101.04020202.03021c00
> > We should continue to reject files that don't use it
> 
> Imo, we should auto-detect as much as possible as it was done in
> FFmpeg for the last decade.

I actually worded this a bit incorrectly; the file *is* PCM, so
everything is fine as far as mxfdec is concerned. See below

I also notice this UL is already in mxf.c, but added commented out by
Baptiste back in 2006..

> > > A probe function is definitely needed, it maybe should be more
> > > similar to existing lavfi probe functions though.
> > 
> > It's easy enough to probe this in .wav since it only involved reading a
> > few bytes from the data chunk, even if a proper TwoCC would be highly
> > preferable.
> 
> There is no TwoCC.
> 
> > Both these situation could be handled by avformat_find_stream_info() if
> > there's some way to detect that a file is using AES3 in advance, and
> > delay setting codec_id until the first audio packet has been inspected
> 
> First step is a demuxer, wav can then use the probe function.

It demuxes just fine. It's PCM audio in an AES-BWF essence container.

Probing is not what you want, at least not automatic probing. A generic
lavf format option is needed, because Dolby-E can be contained in any
format that supports 16-bit PCM. Which is pretty much all formats.
Nicolas is on the right track, and my gut feeling about per-format
options was wrong.

FFmpeg has no way of knowing the user's intent without options. You'll
have the outer product of at least these cases:

* a file contains PCM data, which does not probe as Dolby-E
* a file contains PCM data, which probes as Dolby-E
* a file contains Dolby-E data, tagged as such (with UL or TwoCC)

* the user has the computer FFmpeg is running on hooked up to another
machine via mini tele or RCA connectors
* the user has the computer FFmpeg is running on hooked up to another
machine via S/PDIF

* the other machine has a Dolby-E decoder, and it should be used
* the other machine has a Dolby-E decoder, and it should not be used
* the other machine has no Dolby-E decoder

So, a general solution is needed. When the user knows the audio is
Dolby-E then they can obviously just override the decoder, if they want
(not always). Another typical case is "if you think the audio is Dolby-
E, automatically decode it so I don't blow my speakers!". An option
could allow avformat_find_stream_info() to wait for the first audio
packet and probe it, and not take what the demuxer says at face value.

/Tomas