DGDemux development

User avatar
Bullwinkle
Posts: 338
Joined: Thu Sep 05, 2019 6:37 pm

Re: DGDemux development

Post by Bullwinkle »

Thinking is not optional, Sherman.

Domi, Levi has a message for you:

https://www.youtube.com/watch?v=qXavZYeXEc0
User avatar
Natasha
Posts: 150
Joined: Wed Nov 20, 2019 11:11 am

Re: DGDemux development

Post by Natasha »

You people are demented. Mr. Big will not like this.
User avatar
Curly
Posts: 712
Joined: Sun Mar 15, 2020 11:05 am

Re: DGDemux development

Post by Curly »

It's the heart that sings.
Curly Howard
Director of EAC3TO Development
User avatar
Natasha
Posts: 150
Joined: Wed Nov 20, 2019 11:11 am

Re: DGDemux development

Post by Natasha »

Cry me a river.

Image
User avatar
Boris
Posts: 92
Joined: Sun Nov 10, 2019 2:55 pm

Re: DGDemux development

Post by Boris »

Listen up! We got big shipment from Wuhan:

* masks
* gowns
* gloves
* test kits

And big clearance special on dog meat! Send PM for details. We are here for you.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

domi, Sherman asked me to help him a little with this but I am out of energy for today. Will answer tomorrow morning. Thanks for your patience.
DAE avatar
domy
Posts: 28
Joined: Fri Mar 20, 2020 10:50 am

Re: DGDemux development

Post by domy »

No worries, it's nothing urgent at all :)

I figured out how to bypass eac3to and make ffmpeg decode the THD stream while ignoring errors (ffmpeg -i file.thd -ac 1 out.thd, version 4.2.2), but it prints a lot of errors and the final flac file is 5 seconds short by the end for Monster's University (movie length is 1:43:48.389, flac output is 1:43:43.281). The movie itself sounds perfectly in sync throughout though, so this is probably a case of ffmepg's THD decoder being quite strict to the spec and dropping invalid frames, maybe? I haven't yet watched it through entirely so I can't tell you if these errors are audible, but I can imagine that it might cause problems with some THD decoders out there. Either way I can't generate a correct wav/flac bitstream.

Here's an excerpt of the aforementioned errors:

Code: Select all

[11:24] ~\Desktop\dgdemux_output\monsters-university> ffmpeg -i '.\00800 PID 1100 48000 8ch eng DELAY 0ms.thd'
-ac 1 monster-university-thd-mono.flac
ffmpeg version 4.2.2 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9.2.1 (GCC) 20200122
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enabl
e-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enab
le-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enabl
e-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 -
-enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enabl
e-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --en
able-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-l
ibopenmpt
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Input #0, truehd, from '.\00800 PID 1100 48000 8ch eng DELAY 0ms.thd':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Audio: truehd, 48000 Hz, 7.1, s32 (24 bit)
Stream mapping:
  Stream #0:0 -> #0:0 (truehd (native) -> flac (native))
Press [q] to stop, [?] for help
Output #0, flac, to 'monster-university-thd-mono.flac':
  Metadata:
    encoder         : Lavf58.29.100
    Stream #0:0: Audio: flac, 48000 Hz, mono, s32 (24 bit), 128 kb/s
    Metadata:
      encoder         : Lavc58.54.100 flac
[out_0_0 @ 0000020f16250280] 100 buffers queued in out_0_0, something may be wrong.
[truehd @ 0000020f162d6840] End of stream indicated./s speed=41.7x
[truehd @ 0000020f162d6840] Lossless check failed - expected 00, calculated 9f.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] Invalid blocksize.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] quant_step_size larger than huff_lsbs
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x00fe)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 1 times
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1b8b)
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1e07)
Error while decoding stream #0:0: Invalid data found when processing input
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 4 times
[truehd @ 0000020f162d6840] Invalid channel 9 specified as output from matrix.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1781)
[truehd @ 0000020f162d6840] Invalid blocksize.
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1f80)
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] Invalid huff_lsbs.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] Invalid huff_lsbs.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x04d1)
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x02a9)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 8 times
[truehd @ 0000020f162d6840] Number of primitive matrices cannot be greater than 8.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x0030)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 1 times
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x11b3)
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x0fe2)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 9 times
[truehd @ 0000020f162d6840] Invalid blocksize.
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 3 times
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1c82)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000020f162d6840] quant_step_size larger than huff_lsbs
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1d20)
[truehd @ 0000020f162d6840] Invalid blocksize.
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1519)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 1 times
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1a7f)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000020f162d6840] quant_step_size larger than huff_lsbs
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 1 times
[truehd @ 0000020f162d6840] Invalid blocksize.
    Last message repeated 1 times
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x0d95)
[truehd @ 0000020f162d6840] No samples to output.
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 1 times
[truehd @ 0000020f162d6840] Invalid blocksize.
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x05ee)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 1 times
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x1bad)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 7 times
[truehd @ 0000020f162d6840] quant_step_size larger than huff_lsbs
[truehd @ 0000020f162d6840] Invalid blocksize.
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x03ef)
[truehd @ 0000020f162d6840] No samples to output.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] Negative output_shift is not implemented. Update your FFmpeg version to the newest one from
Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[truehd @ 0000020f162d6840] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and c
ontact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
[truehd @ 0000020f162d6840] Negative output_shift is not implemented. Update your FFmpeg version to the newest one from
Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[truehd @ 0000020f162d6840] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and c
ontact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
[truehd @ 0000020f162d6840] FIR filter coeff_bits must be between 1 and 16.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] quant_step_size larger than huff_lsbs
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 3 times
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x04d2)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000020f162d6840] Sum of coeff_bits and coeff_shift for FIR filter must be 16 or less.
[truehd @ 0000020f162d6840] IIR filter order 13 is greater than maximum 4.
[truehd @ 0000020f162d6840] Invalid blocksize.
[truehd @ 0000020f162d6840] No samples to output.
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 7 times
[truehd @ 0000020f162d6840] Invalid blocksize.
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000020f162d6840] Invalid blocksize.
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 3 times
[truehd @ 0000020f162d6840] FIR filter order 10 is greater than maximum 8.
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000020f162d6840] Invalid blocksize.
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x0153)
[truehd @ 0000020f162d6840] restart header sync incorrect (got 0x08c7)
[truehd @ 0000020f162d6840] No samples to output.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000020f162d6840] Invalid blocksize.
[truehd @ 0000020f162d6840] Invalid channel 11 specified as output from matrix.
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 1 times
...
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

domy wrote:
Sat Apr 18, 2020 4:51 am
No worries, it's nothing urgent at all
It is urgent because we don't want to be demuxing invalid files. Investigating...
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

Hey domy, I'm using 00801.mpls from MONSTERS_UNIVERSITY. Is that what you are using? We need to be using the same source.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

Let's address the first issue with ATMOS stripping. I demuxed the THD track from MONSTERS 00801.mpls with the do-not-split option unchecked. I copied the file into my ffmpeg 4.2.2 bin directory. I opened a CMD prompt there and did the stripping without issues:

Code: Select all

C:\Standalone\ffmpeg 4.2.2\bin>ffmpeg -i dgdemux.thd -c:a copy -bsf:a truehd_core dgdemux_.thd
ffmpeg version git-2020-04-01-afa5e38 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 9.3.1 (GCC) 20200328
  configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
  libavutil      56. 42.102 / 56. 42.102
  libavcodec     58. 77.101 / 58. 77.101
  libavformat    58. 42.100 / 58. 42.100
  libavdevice    58.  9.103 / 58.  9.103
  libavfilter     7. 77.101 /  7. 77.101
  libswscale      5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Input #0, truehd, from 'dgdemux.thd':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Audio: truehd, 48000 Hz, 7.1, s32 (24 bit)
Output #0, truehd, to 'dgdemux_.thd':
  Metadata:
    encoder         : Lavf58.42.100
    Stream #0:0: Audio: truehd, 48000 Hz, 7.1, s32 (24 bit)
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
size= 4756512kB time=01:44:18.41 bitrate=6226.1kbits/s speed= 366x
video:0kB audio:4756512kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

C:\Standalone\ffmpeg 4.2.2\bin>
Audacity now loads the stripped file without issues. Let's try to get closure on this before we go to the rest, as there may be a common issue. I do see you changed the order of the options. Please try with my order. Also, it looks like we have different component versions (e.g., look at libavformat) and build configurations, but both claim 4.2.2. :scratch:
DAE avatar
domy
Posts: 28
Joined: Fri Mar 20, 2020 10:50 am

Re: DGDemux development

Post by domy »

Ahh, I was using powershell. It works with cmd. I'm using 00800.mpls, do-not-split unchecked, ffmpeg 4.2.2 as well.

So, this is kind of a weird situation: If I import the THD core into Audacity, the length of the audio stream is 1:43:43.290 (298,717,920 samples). If I force ffmpeg to decode it by transcoding to flac*, the resulting file has 1:43:43.281 (298,717,504 samples). The demuxed h265 stream has 149,333 frames, amounting to a duration of 1:43:48.431 - that's about 5 seconds longer than the THD stream. But, it seems the THD stream really is 1:43:48; ffmpeg stops transcoding at :48, and playing the THD file with mpv lets me seek all the way up to :48. If I mux THD+H265 together with MKVtoolnix 45.0.0, the movie is (seemingly perfectly) in sync with the THD audio at any point I seek to. Playing back the movie without any seeking also keeps sync just fine.

* the transcoding command, super simple:

Code: Select all

ffmpeg -i dgdemux.thd dgdemux_mono.flac
The Atmos stripping completes without errors, but I believe ffmpeg does this with only minimal parsing (I get a speed of about 200x when doing this). Transcoding it is significanly slower (about 35x on my machine) and reports heaps of errors.

I suspect that DGDemux now outputs some flawed THD frames at or near the segment boundaries (given the ffmpeg errors), which probably causes ffmpeg to just remove them from the output. I guess the playback decoder ignores the errors and plays the audio anyway, even if the checksum or whatever is wrong - that would explain why the movie is nicely in sync and plays fine (at least in mpv), despite the transcode errors. But again, that's just my best guess given the evidence.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

Well that's weird that Powershell acts so differently. I'll have to start over with 00800.mpls. There shouldn't be a 5-second discrepancy between audio and video. Let's see if I can reproduce that.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

Just not seeing it, domy.

Demuxed video and thd track from 00800.mpls. Indexed the elementary video and obtained 149332 frames. That leads to 6228.38 seconds at 24000/1001. Then I used a tool I have to count frames in the (not ATMOS stripped) THD and that gave 6228.39 seconds.

Code: Select all

D:\Don\Programming\C++\TrueHD\x64\Debug>truehd dgdemux.thd
58693 major, 7415375 minor, 7474068 total, 6228.390000 duration
So it seems your method for determining the duration of the THD file is suspect. I can give you my little app if you want it. I wrote it myself. And sync is great so... Now about the eac3to errors and flac transcoding, let's get this discrepancy sorted out first before moving to them.

PS: Can we talk about total seconds and not hours:minutes:seconds?
DAE avatar
domy
Posts: 28
Joined: Fri Mar 20, 2020 10:50 am

Re: DGDemux development

Post by domy »

Sorry, let me clarify: I know that the THD stream is in fact 6228 seconds long. What I mean is that when you let ffmpeg transcode the THD stream, it spits out a bunch of errors and what comes out is only 6223 seconds long. I don't have any other way to analyze the actual audio samples but to go through ffmpeg (I think?).

As a side note, I would argue that this is an issue since most AV software uses ffmpeg under the hood, and I think a THD stream that ffmpeg decodes without errors is all but guaranteed to play nice with every player/decoder out there.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

OK, thank you, domy. Now we're cooking with gas. It could be that we need to re-write some checksums when deleting minor frames (which may be a pain in the patootie but it's what it is). Have to check the spec. Tomorrow. Right now, it's nap time. :D

Really appreciate your patience and assistance! It will be great to get this working flawlessly. :salute:
User avatar
Levi
Posts: 52
Joined: Sat Apr 18, 2020 6:12 pm

Re: DGDemux development

Post by Levi »

Curly wrote:
Fri Apr 17, 2020 12:14 pm
It's the heart that sings.
Bless you Curly for your wisdom. One day we will meet in the hereafter. We will sing together.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

So, I was able to verify the issue. After some investigative steps I ended up just demuxing without gaps correction to get the reference stream. ffmpeg could convert it to flac with the proper duration (there are some warnings but they appear to be inconsequential). Then I copied the stream to a new file and manually deleted the first minor frame using a hex editor. My tool correctly counted frames and showed one less minor frame, so I am sure I edited it correctly. Now, when transcoding to flac this appears:

Code: Select all

Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 9 times
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x1f9e)
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x0d96)
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000022d6ef412c0] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x1eff)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 1 times
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x13dc)
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x0d93)
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x1fef)
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x1d59)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 7 times
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x07e7)
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 0000022d6ef412c0] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x139e)
[truehd @ 0000022d6ef412c0] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 4 times
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x17cb)
[truehd @ 0000022d6ef412c0] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x12df)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[truehd @ 0000022d6ef412c0] restart header sync incorrect (got 0x079f)
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 4 times
[truehd @ 0000022d6ef412c0] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
After that the conversion continues without further such errors. It's clear that the ffmpeg parser is not liking this very much. My next step is to inspect the ffmpeg source code for insight to why it thinks there is invalid data, and if necessary run it in a debugger etc. I suppose the buffering is getting confused by the timestamp jump. I may also try simply offsetting all timestamps backwards to account for the deleted frame, just to see what happens.

Likely gonna have to remove this feature until this is resolved.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

Might be making some progress. We already know that transcoding the demuxed gaps-adjusted THD to flac spits out tons of errors and loses 5 seconds. As I mentioned, I decided to minimize things and just manually delete the first minor frame. I had mentioned that it spit out errors. But now, going through things again, I noticed two things:

1. The really serious errors are not there for the manually edited stream compared to the gaps-adjusted stream.

2. The duration was correct at 6228 seconds! I hadn't checked that previously.

Aha! So now I have a new theory. I must not be properly deleting minor frames when demuxing, i.e., it is not doing the same thing as when I manually delete them. Off to double check all that...
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

Houston, we have a problem. A big problem!

I modified the gaps processing to let me do just the first gap correction and then disable further correction. So it deletes just one minor frame, similar to manually removing one as I had done. The stream then transcoded to the expected 6228 seconds, i.e., not missing 5 seconds. So, after all this perhaps it's clear what is going on. The buffer model can handle one or a few frame deletions but if there are too many the buffering breaks completely (we have 129 deletions for MONSTERS; that is a lot of buffering). This seems analogous to video. You can't just delete frames in the coded domain without screwing up the VBV buffering (not to mention breaking references, though not applicable to audio).

To even have a hope of doing this, we would have to find a way to properly reset all timestamps based on the access unit sizes and the buffering model. And there are lots of timestamps (in time for the access unit and out times for each substream). We'd have to do much of the work of a THD encoder. That is sadly not going to happen, or should I say, I'm not going to attempt that. It's interesting that in the last post of the lavfilters thread earlier cited the laMakeMKV guy speculates about this and asks explicitly how it might be done. There is no response.

I'm going to sleep on this.
User avatar
Levi
Posts: 52
Joined: Sat Apr 18, 2020 6:12 pm

Re: DGDemux development

Post by Levi »

Musicians always keep things in perspective.

https://youtu.be/krxU5Y9lCS8?t=155
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

Uh huh. Actually I plan to have 3 selectable options:

1. Don't do any gaps processing. Warn of desync.
2. Do gaps processing. Warn of file incompatibility.
3. Secret method to generate clean in-sync FLAC file not yet revealed. Loses ATMOS.

I am testing the concept for 3 and if it works I will explain.
DAE avatar
renols
Posts: 149
Joined: Tue Feb 22, 2011 2:34 am

Re: DGDemux development

Post by renols »

Hi.

Not knowing anything about thd structure or specs here, so below quetions may show a lack of technical knowledge.

What would the danger of using a file made by (2) be?

Is just a question if eac3to throwing error if one tries to make a FLAC file out of it, or can there be more serious issues.

Can it also cause some problems on devices used to play back the muxed mkv file afterwards. That would be an issue of course. I guess it depends wether the actual device cares about the thd spec, or just plays the file regardless.

Other software like eac3to and makemkv would have the same issues when dealing with seamless branching, in the amounts we are talking here?

If using (1), how many m2ts files would it take to get an "unacceptable" desync value. Some playlists may just 5-10 m2ts files. Does it even get noticable using (1) in such cases?

Thanks for really getting to the bottom of this. Really appreciate it!

renols
DAE avatar
domy
Posts: 28
Joined: Fri Mar 20, 2020 10:50 am

Re: DGDemux development

Post by domy »

MakeMKV somehow manages to do THD gaps processing while also outputting a correct stream. I don't yet know how well it processes gaps, but its Monsters University THD stream is "only" about 42ms short by the end. That's better than no processing (which would make it about 110ms too long by the end), but still not ideal.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky »

Good morning boys and girls! Let me first reply to the posts and then share exciting developments in a following post.
renols wrote:
Thu Apr 23, 2020 2:36 am
What would the danger of using a file made by (2) be?

Is just a question if eac3to throwing error if one tries to make a FLAC file out of it, or can there be more serious issues.

Can it also cause some problems on devices used to play back the muxed mkv file afterwards. That would be an issue of course. I guess it depends wether the actual device cares about the thd spec, or just plays the file regardless.
That's not definitively known. We do know that players seem able to play the gaps-adjusted THD file without issues. That is why I will have an option to either perform or not perform the correction.
Other software like eac3to and makemkv would have the same issues when dealing with seamless branching, in the amounts we are talking here?
EAC3TO is just totally bad with these disks. There has been an open bug about it that has languished for over a year and madshi has said he is interested in other things these days. Regarding MakeMKV see my reply to domy below.
If using (1), how many m2ts files would it take to get an "unacceptable" desync value. Some playlists may just 5-10 m2ts files. Does it even get noticable using (1) in such cases?
Without correction there is about a 0.8ms desync at each file gap. So 5 gaps would be fine; 134 gaps (MONSTERS) would be unacceptable.
domy wrote:
Thu Apr 23, 2020 2:50 am
MakeMKV somehow manages to do THD gaps processing while also outputting a correct stream. I don't yet know how well it processes gaps, but its Monsters University THD stream is "only" about 42ms short by the end. That's better than no processing (which would make it about 110ms too long by the end), but still not ideal.
I don't know what Mike is doing. I guess one of two things: 1) he found a way to patch timestamps, or more likely 2) he is deleting full audio GOPs (i.e., the major and all following minor frames). The second would produce a sync granularity that is dependent on the length of the audio GOP; the longer, the less fine the correction can be. I intend to come back to this and play around more with timestamp patching. I don't like full GOP deletion. I will also get in touch with Mike and see if he is willing to share what he is doing. And I can also binary compare files to try to reverse engineer what he is doing. But for now, given that we have developed a method that maintains sync within about 1ms throughout in the final FLAC file, that is not pressing (see following post coming after my lunch LOL). ;)

BTW, DirectTV requires desync to be <= 25 milliseconds, so 42ms out would be considered unacceptable.
User avatar
Bullwinkle
Posts: 338
Joined: Thu Sep 05, 2019 6:37 pm

Re: DGDemux development

Post by Bullwinkle »

Eenie meenie chili beanie, the spirits are about to speak. Full Moose Power here at your service. High-level hoomin gonca has elsewhere alluded to the magnitude of this incredible force. :salute: Nobody calls me meenie!

Rocky's brain is aching this morning so I will take over while he takes cover. It is after yesterday's lunch, dontcha know? And watch out, I'm having liver for breakfast. Shut up, not Moose liver!

Here is what we did to achieve 1ms sync accuracy for MONSTERS_UNIVERSITY. Just so you know, the concept came from my awesome Moose Mind and the coding and concept testing came from Rocky. Silly billies, the plan is to do the cuts in the uncompressed domain, where we have cut granularity at the audio sample level and can avoid all the disgusting buffering/GOP/timestamp issues altogether. Presto!

1. Demux the THD stream without correcting the gaps but instead generate a cutlist file that specifies the cuts to be made (indexed by time). Of course the raw THD is demuxed as usual (we'll call it file.thd). The cutlist is in the form of a sox-compatible trim list. Don't forget that the cutlist is generated using our SUPER SECRET Bresenham-like algorithm but implemented for audio instead of pixels (https://www.cs.helsinki.fi/group/goa/ma ... esenh.html). Moving the next pixel up or not is equivalent to removing audio or not. No attempt is made to identify duplicate audio frames or other such nonsense (what if a stream has valid repeated frames?). Oops, not secret anymore. Here is an example that specifies cuts of 1 second at time 5, and 4 seconds at time 8 (in practice these are specified with submillisecond accuracy):

trim 0 =5 =6 =8 =12

You can read the sox manual to understand the syntax. OK, we now have a wonderful cutlist conceived through the incredible power of the Moose. You can see the actual cutlist for MONSTERS in the next post.

2 (usually follows 1). Now we transcode the THD file to W64. That's an easy one (ignore warnings):

ffmpeg -i file.thd -c:a pcm_s24le -ar 48000 -rf64 never file.w64

3. Now we simply apply the cutlist to file.w64. For a while there Sherman was going to write a utility to do that (cough) but then in an amazing burst of brilliant Moose Intellect I discovered that sox.exe can do this. Kinda explains why I made the cutlist in sox-compatible syntax. Got it? Hoomins can be slow but think it over.

sox file.w64 trimmed.w64 trim cutlist

Of course cutlist here is simply cut-and-pasted from the step 1 cutlist file. Ha! Fans of all that is good and correct, we now have a wonderful in-sync w64 file that we can use directly if we want. But most hoomins are smart enough to know that we should probably make a FLAC file, so...

4. Transcode the adjusted file to FLAC:

ffmpeg -i trimmed.w64 trimmed.flac

And Bob's yer uncle!

It has not escaped the Powerful Moose's attention that this process can be fully automated. We can distribute ffmpeg and sox as long as the proper incantations are included per licenses. :salute: ffmpeg and sox.

The smartest hoomins (few and far between) are thinking: uh, if you can cut at sample level, why isn't the sync within one sample duration (0.02ms)? Good question. It all depends on the Bresenham threshold that we use. Currently, we are using 1ms. If we make it too small then the cutlist becomes too large and CMD falls over when we try to include it in a sox command line. See, y'all, the power of the Moose?

Bow down in humble acclamation!

Finally, I am itching to exercise my new mod powers so if someone could be so kind as to misbehave I would be a really grateful Moose. Now that I am a mod I don't have to play Mr Civil anymore. Curly would say nyuk nyuk. And if you could really misbehave maybe we could have a stomping, only if absolutely necessary of course. Snort!
Post Reply