Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. Domains: forum.doom9.org / forum.doom9.net / forum.doom9.se |
3rd July 2024, 19:18
|
#41 | Link | |||||||||||||||
|
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,384
|
Oh wow, that's a very long feed... I mean, you're gambling a lot when you leave the recording go for such a long time, it's pretty insane and risky.
On EVS Ingest Scheduler (xtaccess hardware encoder), we generally record at blocks of 1h to be safe (max 2h) to avoid corruption and we definitely never exceed the 4h mark. Recording an 8h feed in one single part is a pretty bold move. Anyway, welcome to Doom9!  By the way, you should update your Mediainfo installation 'cause Jerome has now introduced all the proprietary DolbyE metadata detection, including the dialnorm etc.  In an official Dolby decoder, the dialnorm is interpreted to output the audio to the level described there. In other words, the audio inside could be at any level (let's say -18 LUFS), but if the dialnorm says -23 LUFS the decoder would output it to -23. This is the same kind of logic that is used in AC3, in fact AC3 and DolbyE share the same kind of metadata. Anyway, I always ignore the dialnorm value and decode the audio as-is, then I decide myself whether I wanna do something with it or not. This is the mediainfo of the source using Mediainfo 24.06 which includes the DolbyE metadata detection patch: Quote:
Now, as we can see, we have a pretty standard file with: Video: FULL HD H.264 20 Mbit/s 4:2:0 25i Limited TV Range 8bit planar BT709 SDR Audio: CH.1-2 MP2 384 kbit/s 2ch 48000Hz English Full Mix CH.3-4 MP2 384 kbit/s 2ch 48000Hz Mute CH.5-6 DolbyE 5.1 + 2.0 (1300 kbit/s + 505 kbit/s) I started indexing with LWLibavVideoSource() and LWLibavAudioSource() and I've got 781375 frames, namely 08:40:55.00 This is when I indexed the video and CH.1-2: Quote:
Quote:
The audio tracks seem to be having some problem, though. This is expected given how lengthy the recording was. When I try to index CH.1-2, I get 07:26:48.28 before it crashes, while when I try to index CH.3-4 I get 07:26:48.68 before it crashes. A part of those also seems to be corrupted. Anyway, I decoded and re-encoded them both to PCM 24 bit 48000Hz muxed as RF64 wav: Quote:
Quote:
Quote:
At this point I had to deal with CH.5-6, which is the DolbyE 5.1 + 2.0 track. I noticed that you tried to decode it with the u8 procedure yourself, however keep in mind that we're talking about a .ts container, not about an .mxf container. This means that the DolbyE track wasn't muxed as a standard SMPTE ST 337 but rather as SMPTE ST 302. This means that we have to index the DolbyE 5.1 + 2.0 SMPTE ST 302 track and remux it as DolbyE 5.1 + 2.0 SMPTE ST 337.wav before we can decode it 'cause FFMpeg only expects SMPTE ST337. To do this, we need to index CH.5-6 (i.e stream 3) and save it, however, since it's corrupted/truncated, when I do this: Quote:
Quote:
it gets stuck without outputting anything. It just... stalls. I tried to use Quote:
Quote:
As to FFAudioSource(), I tried with Quote:
Quote:
Quote:
Quote:
Quote:
Last edited by FranceBB; 3rd July 2024 at 19:25. |
|||||||||||||||
|
|
|
3rd July 2024, 19:19
|
#42 | Link | |||
|
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,384
|
Anyway, we got closer to the end result as we've now got a 7h 20m DolbyE 5.1 + 2.0 file muxed in wav as SMPTE ST337.
Quote:
Now this is what we can decode 'cause it's muxed as SMPTE ST 337. Even just playing it with MPV works:  Now, before we go on with this, I know what you meant when you said that you couldn't get past 6h 30m. This is because if we apply the u8 trick on that file like this: Quote:
Dolby E data size 1037087 in SMPTE 337M is not implemented. so, effectively, it stops after 06:30:31.48.  What we can however do is use Avisynth to decode it and the GetChannels() function to get the 5.1 first and the + 2.0 then. In other words: Quote:
By looking at this with VideoTek() we can see that the channels are correctly presented as FL FR CC LFE LS RS:    I thought "nice, so at this point it's just a matter of saving the decoded output", but no. Unfortunately LWLibavAudioSource() also suffers from the same limitation affecting FFMpeg 'cause they're both based on libav. In other words, after 6h 30m, everything is silent. As for WAVSource(), it just fails to decode it, while BestAudioSource() decodes it completely silently, so does DirectShowSource() using the LAV Decoder. PotPlayer does play it, though, so at this point I wonder whether it can go past the 6h 30m mark. When I seek forward on MPV, it does allow me to decode past the 6h 30m mark, here I am at 6h 50m and I can guarantee you that there's sound:  I'll try to do something more about this tomorrow, but right now I'm uploading the following files: - Isle of Wight Festival (21-6-24) (1080i) (Feed) (Dolby-E)_stream1_CH56.wav This is the full DolbyE 5.1 + 2.0 stream extracted from the .ts file. - Isle of Wight Festival (21-6-24) (1080i) (Feed)_CH12.wav This is the decoded MP2 Stereo of CH.1-2. - Isle of Wight Festival (21-6-24) (1080i) (Feed)_CH34.wav This is the decoded MP2 Stereo of CH.3-4. - Isle of Wight Festival (21-6-24) (1080i) (Feed)_CH56_51_Truncated.wav This is the decoded DolbyE 5.1 of CH.5-6 but truncated to 6h 30m when the decoder chokes and gives up. In theory it should be possible to trim it and then decode it in two parts, but I have to think about a way to do this. Link: https://gofile.io/d/b8JYyA Last edited by FranceBB; 4th July 2024 at 08:13. |
|||
|
|
|
|
4th July 2024, 09:18
|
#43 | Link | ||||
|
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,384
|
I'm a bit at a loss, 'cause I thought: "well, I could simply trim this".
You see, one of the properties of DolbyE is that - as long as the guardband (i.e the frame loc / line positioning) is in a valid position - any application can trim it without compromising its integrity, regardless on whether it understands DolbyE or not. This is because DolbyE is carried in chunks and basically the guardband value tells you the position of the chunks in the stream and whether you can trim them or not. Different framerate and resolution files need different guardband and so on. For instance, FULL HD 25i files generally desire a guardband at around line 22, while UHD 50p ones desire one at around line 42.  In the case of this recording, the guardband is at line 33, which is not ideal, but still in a valid position, so we can trim. What I've done then is split the file in two and essentially create a second part starting from 6h 30m 31s like so: Quote:
which led to the following 50 min 45 seconds DolbyE file containing the last part of the concert: Quote:
At this point I tried to decode it like so: Quote:
 but no, the decoder chokes quickly after and crashes after as little as 1 minute. At this point I'm at a bit of a loss. I mean, with MPV I can play it all the way through, so there MUST be a way to do this, but I'm still thinking...  Still, armed with a lot of good will, I decided to use the official Dolby DP600 to decode the stream and see where it would get me. I therefore remuxed the audio in a proper RF64 wav container like so: Quote:
Program Configuration: 5.1 + 2 Frame Rate: 25 fps Bit Depth: 20-bit Guard Band: line 33 Program 1 Description: CTV OB9 3 Program 2 Description: Program 2 Unfortunately, however, when I started the decoding process it immediately failed with: Audio Extract Started Audio Extract Ended Dolby E Decoding Started Error: Unable to read Dolby-E Metadata So... looks like not even an official Dolby product can properly decode this file (although it could be the fact that I remuxed it with FFMpeg as I can't feed .ts directly to the DP600)... Anyway, I've opened a ticket in the FFMpeg bug tracker https://trac.ffmpeg.org/ticket/11084 Hopefully someone will take a look at that. Last edited by FranceBB; 4th July 2024 at 11:00. |
||||
|
|
|
|
4th July 2024, 14:33
|
#45 | Link |
|
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,384
|
Well... well... well... I've got very good news for you, @r3sistant, I got it. I managed to decode it.
  So... first thing first: what happened was that you had a signal issue while you were recording the file. This led to a CRC error in the DolbyE bitstream. Now, when DolbyE is recorded, it's generally played back via hardware playback ports that create a stream that is transmitted via SDI, then it goes into a Dolby hardware decoder which decodes it as PCM discrete mono and last but not least the signal goes into an hardware encoder that creates the final AC3 before everything is multiplexed and beamed for consumers. When you have an issue with the bitstream, you have a CRC error, namely an "absence of coding". Given that the decoding is done via hardware, this simply leads to a moment in time in which there's silence (i.e mute) in the decoded PCM and therefore silence (i.e mute) in the re-encoded AC3 that it's sent to consumers. When the bitstream comes back and the DolbyE coding is restored at the next chunk, the decoder goes on decoding it and everything is back to normal. This "silence" would be just as long as the CRC error is, ranging from a few frames up to several seconds. Now, here we're not playing anything, we're decoding it via software using the decoder inside FFMpeg, which means that we're doing a software decoding instead. This in turn means that once we get to the point in which there's a CRC error, the decoder simply crashes. What I said in the previous post, however, still holds true, namely that - as long as the guardband / frame loc / line position is within a legal value - we can trim a DolbyE bitstream wherever we want without having to care about screwing it up and this is exactly what I've done as the file had a line positioning of 33 which is valid (albeit not recommended for FULL HD 25i). I found the affected parts in which you had a CRC error in the recording, trimmed them out until the next chunk was there, and then I fed it to the decoder, then, I appended all trimmed parts together and I've got the final file. Out of 7h and 20 minutes, the final file was 07:12:09.88, which means that overall 480 seconds (i.e 8 minutes) were lost due to CRC errors. Here's the final link: https://gofile.io/d/yCQf7L - Isle of Wight Festival (21-6-24) (1080i) (Feed)_CH12.wav - Isle of Wight Festival (21-6-24) (1080i) (Feed)_CH34.wav - Isle of Wight Festival (21-6-24) (1080i) (Feed)_CH56.wav There you can find CH.1-2 2.0, CH.3-4 2.0, CH.5-6 5.1, all nicely decoded as PCM 24 bit little endian 48000Hz muxed as RF64 wav. Another day, another mystery solved, another DolbyE file decoded. Open source rocks.
|
|
|
|
|
15th August 2024, 21:14
|
#46 | Link | ||
|
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,384
|
I updated the guide in the main page to include the commands for FFMpeg 7.x given that -map_channel was deprecated in favor of the pan audio filter.
It will still be valid for FFMpeg 6.x and older, though, but it won't work with FFMpeg 7.x and newer as it requires the use of the pan audio filter. For FFMpeg 6.x or older: Quote:
Quote:
|
||
|
|
|
|
10th October 2025, 17:03
|
#48 | Link |
|
Registered User
Join Date: Mar 2007
Posts: 202
|
@FranceBB,
This doesn't seem to work with ffmpeg 8.x. I've tried these steps: Code:
ffmpeg -i "XDCAM50_DolbyE_51_20.mxf" -map 0:1 -acodec pcm_u8 -f u8 -y "stream1.u8" ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -af "pan=mono|c0=c0" -y "FL.wav" Tried with both your MXF and MOV sample files. Note that when using -acodec copy as you wrote, it produces the error: "u8 muxer supports only codec pcm_u8 for type audio", therefore I used acodec pcm_u8. Last edited by leoenc; 12th October 2025 at 18:39. |
|
|
|
|
29th January 2026, 17:01
|
#49 | Link | |||
|
Registered User
Join Date: Dec 2020
Posts: 22
|
Quote:
Quote:
Correct is to use -c:a pcm_s16le -f s16le if your dolbyE stream is 16bit and -c:a pcm_s24le -f s24le if your dolbyE stream is 20 bit. The following batch should decode dolbyE from any input file in one go and write the decoded channels into a multichannel mkv output. After saving this to a .bat file on windows, just drag/drop a file on the batch. Make sure ffmpeg is in the PATH (or write the path to ffmpeg in the batch) Quote:
Last edited by emcodem; 31st January 2026 at 22:48. |
|||
|
|
|
 |
| Thread Tools | Search this Thread |
| Display Modes | |
|
|
Linear Mode
