[FFmpeg-devel] [PATCH v4 0/9] avformat: wav-s337m support + new probe_stream option

Carl Eugen Hoyos ceffmpeg at gmail.com
Thu Oct 8 10:53:36 EEST 2020


Am Mo., 5. Okt. 2020 um 12:23 Uhr schrieb Nicolas Gaullier
<nicolas.gaullier at cji.paris>:
>
> >> Because of the dependencies, I had to group all the patches in a serie, but they are 3 functional parts :
> >> * patch 1 is necessary to fix dolby_e pts that will be part of the
> >> test in patch 8
> >> * patch 2,3,4,5,6,7,8 : s337m support in wav
> >>     this is a rework of a precedent serie
> >> (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=106)
> >
> >Sorry if this is not related at all but isn't dolby-e mostly found in some dvb streams?
> dolby_e is a "professional" codec, it is not used for distribution and not supported by end user chips, so the most common formats are :

> - contribution: mpegts (or dvb for satt etc.) with s302m data -> s337m (this could be interesting for ffmpeg to support it)

I believe we only had such samples until recently.

> - broadcast muxers: mxf, mov, gxf, lxf : in s337m, within stereo tracks or most commonly sadly split into mono tracks (limited support for a simple case such as mxf stereo would still be welcome). There is also a newer form with AMWA-AS 11 with audio samples not encoded, but with single separated audio metadata bistream in VANC : this is not strictly "dolby E", just the metadata part of it (dialnorm et.), and currently dolby_e.c does not support parsing these metadata.
> - wav
>
> >> * patch 9 : AVOption to disable codec auto-detect : it seems it is a
> >> general request from many users, and it is also critical here for dolby_e as many broadcasters will still need to just pass-through dolby_e data as they already do.
> >> Thus, the patchset 2,3,4,5,6,7 should not be applied without the last patch 9 applied quickly behind...
> >
> >As said, this surprises me, please elaborate.
> >
> Most of the time, broadcast users just want to pass-through dolby E

What I meant was:
What did you try to pass-through (command line)?
I still believe that your new option is not necessary or at least not
needed for this
use-case (but I may of course be wrong).

Carl Eugen


More information about the ffmpeg-devel mailing list