| Message ID | 20201002222346.1196-1-nicolas.gaullier@cji.paris |
|---|---|
| Headers | show |
| Series | avformat: wav-s337m support + new probe_stream option | expand |
Am Sa., 3. Okt. 2020 um 00:24 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? > * 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. Carl Eugen
>> 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) - 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. > >Carl Eugen Most of the time, broadcast users just want to pass-through dolby E: typically they mux m2v/wav essence files to an mxf file. Downstream broadcast hardwares or applications can probe the stream and transcode the detected dolby_e stream to an ac-3 stream which can be distributed. Without an option to disable dolby_e stream probing, it would be strictly impossible to do this. In the future, one can imagine that broadcast muxers mxf/wav/.. would be able to support dolby_e by automatically submuxing to s337m with correct guard-band/phase, and that could be interesting to repair a bad s337m submux, but this is a long way... Apart from that, it seems some users would like to be able to disable stream probing, so it seems it is an opportunity to add this AVOption right now. Nicolas
On Mon, Oct 5, 2020 at 6:23 AM Nicolas Gaullier <nicolas.gaullier@cji.paris> wrote: > 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) FYI: I've got patches to output AC-3 as S337 over the decklink SDI output. However doing Dolby-E is harder because the start of the frames are expected to be aligned with the start of the video frame (i.e. typically against a VREF signal). I haven't figured out how to do this reliably with the decklink APIs, but it might be possible. Capture of S337 using decklink is a bit easier, although it means reproducing a bunch of the probing/detection logic found in the other avformat demuxes. Passing the data through to the s337m avformat module might also be an option but it's harder since the s337m module expects AVIOBufs which is more difficult to provide. Devin
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
>> - 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. With things moving from SDI to IP, I think this is going to be commonplace. I have two s302m samples with DolbyE 20 bits, one muxed in AES 20 bits, another in AES 24 bits, I can share short samples. >> >> * 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). Here is one of my personal real-life use cases : we have a big old archive with .mpg files that holds mp2 stereo audios plus additionnal .wav files for titles that provide DolbyE (those two formats were choose because they were the best mezzanine formats, the most supported). Now, I typically wants to build a fresh new mxf holding the DolbyE : ffmpeg -i input.mpg -i input_1.wav -map 0:v -map 1 -c copy output.mxf This fails because dolby_e is not supported by the current mxf wrapper (nor the 44.8KHz of my DolbyE @25fps). So I have to use the new option: ffmpeg -i input.mpg -probe_streams 0 -i input_1.wav -map 0:v -map 1 -c copy output.mxf Ouput.mxf will be generated as a standard mxf with pcm audio, which is fine (Dolby E signalisation in mxf is possible but very rarely used in my experience - aside ZDF). Note many people (I would think I am not the only one) already use scripts to pass-through DolbyE data with ffmpeg. We will have to update our command lines to insert the new -probe_stream, which is ok, but indeed this is really necessary otherwise some works that could be done in earlier/current ffmpeg will not be possible to do in future ffmpeg. Nicolas
Because of the dependencies, I had to group all the patchs in a serie, but they are 3 functionnal 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) * 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... Here are the updates on the s337m serie since the last revision: * an error message has been removed in s337m_get_offset_and_codec because it could never be seen in the actual implementation and thus seemed useless * the decoding test has been replaced by a demuxing test (Tomas review) The test sample 512.wav can be downloaded here : https://0x0.st/zdW-.wav Thank you for the review! Nicolas Nicolas Gaullier (9): avcodec/dolby_e: set constant frame_size avformat/s337m: Split read_packet/get_packet avformat/s337m: Consider container bit resolution avformat/s337m: New ff_s337m_probe() avformat/wavdec: s337m support avformat/wavdec.c: Reindent after last commit avformat/wavdec: fix s337m/spdif probing beyond data_end avformat/wavdec: Test s337m avformat: Add probe_stream option doc/formats.texi | 3 ++ libavcodec/dolby_e.c | 1 + libavformat/avformat.h | 9 ++++- libavformat/options_table.h | 1 + libavformat/s337m.c | 69 ++++++++++++++++++++++++++++++++----- libavformat/s337m.h | 54 +++++++++++++++++++++++++++++ libavformat/utils.c | 2 ++ libavformat/version.h | 2 +- libavformat/wavdec.c | 53 +++++++++++++++++++--------- tests/Makefile | 1 + tests/fate/audio.mak | 3 ++ tests/ref/fate/s337m-wav | 11 ++++++ 12 files changed, 181 insertions(+), 28 deletions(-) create mode 100644 libavformat/s337m.h create mode 100644 tests/ref/fate/s337m-wav