Am Mo., 5. Okt. 2020 um 12:23 Uhr schrieb Nicolas Gaullier <nicolas.gaullier@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
