Issue with copying/merging TrueHD 7.1 tracks and preanalysis?. In resulting video on seek through sound loads with delay relative to video.

[DimkaTsv]

Issue description: At least in specific source video. Problem is potentially located in merger. And probably due to size of TrueHD audio tracks proportional to video stream. When i try to transcode it with --audio-copy parameter, and it has TrueHD (MLB-FBA 16-ch 7.1) audio track in source file, when i seek through resulting file, in many places sound comes in late by up to several seconds (but it is still synchronised).

1. If i cut out TrueHD tracks from source file prior to transcode, issue won't appear. But even single TrueHD track is enough to cause problem.
2. Issue becomes more noticeable with upscale (1920x1080->3840x2160) and --vbrhq usage. But if i enable --log-level debug, issue cannot be reproduced for some reason.
3. If i do pass with MKVToolNix afterwards without any changes (aka as is), it will fix problem.
4. Audio load delay affects resulting video globally, no matter what track is selected. But if there was no TrueHD audio in source file, or pass with MKVToolNix was made, there will be no problem.

Bug can be seen in MPC-HC, PotPlayer and VLC. In old Windows Media Player audio plays normally, but on seek video response is delayed. And i cannot reproduce it in Microsoft new Media Player. Probably due to them not being able to read through TrueHD format, as when i try to play TrueHD only sample, there is total silence?

---

Sources: Fragmented 2 minute source for reproduction: https://drive.google.com/file/d/1ExibO124nUvaKBDAON2jRX542fxX2SOg/view?usp=sharing Bugged sample: https://drive.google.com/file/d/128i7hItK0yZ8t6u1XLqPVQ0mB5aiiy02/view?usp=sharing

To check for bug, just open video and try to click on timebar (aka seek through) in random places. Issue is especially noticeable by seeking in range of 1:10 to 1:40.

---

Used commands: C:\Users\-----\Videos\Processing>C:\Users\-----\Desktop\Utilites\VCE_Encoder\VCEEncC_x64\\VCEEncC64.exe -i C:\Users\-----\Videos\Processing\[2xTrueHD]The.Boy.and.the.Heron.1080p.BDRemux.AVC.TrueHD.Atmos.7.1-SOFCJ.mkv -o "[2xTrueHD]The.Boy.and.the.Heron.1080p.BDRemux.AVC.TrueHD.Atmos.7.1-SOFCJ_processed.mkv" --codec HEVC --profile main --tier high --level 6.2 --preset slow --vbrhq 15000 --max-bitrate 45000 --output-res 3840x-2 --vpp-resize amf_fsr --pa lookahead=41,sc=high,ss=high,activity-type=yuv,taq=2,ltr=true --audio-copy --chapter-copy --sub-copy

What i tried:

1. AVC (same result)
2. VBR instead of HQVBR --> Less places where sound comes late, but still are
3. Disabling preanalysis seems to make sound work properly? At least based on test fragment.
4. Setting taq=0 reduces amount of delays and their length
5. Setting lookahead=0 completely removes delays, at least based on test fragment.
6. Using --log-level debug completely removes delays.

Additional information... For some reason at cropping ffmpeg doesn't rewrite metadata to reflect proper sizes of either video and audio streams. While VCEEnc properly rewrites size of video stream, it doesn't do same for audio.

That results in this situation.

FFMPEG fresh crop[Click to unfold]

VIDEO Stream size : 19.0 GiB AUDIO Stream size : 397 MiB (98%) Stream size : 397 MiB (98%) Stream size : 3.68 GiB Stream size : 3.60 GiB In 406 MB file

VCEEnc transcoded

VIDEO Stream size : 65.4 MiB (32%) AUDIO Stream size : 397 MiB Stream size : 397 MiB Stream size : 3.68 GiB Stream size : 3.60 GiB In 204 MB file

MKVToolNix pass

VIDEO Stream size : 293 MiB (72%) AUDIO Stream size : 6.47 MiB (2%) Stream size : 6.47 MiB (2%) Stream size : 49.3 MiB (12%) Stream size : 49.3 MiB (12%)

---

Logs and MediaInfo: Debug log won't help, as debug mode eliminates an issue. And metadata is extremely long to fit without proper spoiler-like structure.

---

Also, @rigaya ,and sorry for direct ping. But should HQVBR not follow set bitrate to such large extend? Aka if i set 15000 kbps, but it encodes to about 2500-3000 kbps in 1080p or about 6000-8000 kbps in 4k (for specific source ofc). Is that just HQVBR quirk to limit QP to conserve bitrate, or some hidden bug?

[rigaya]

The audio seek issue is muxing issue, audio and video data in same time muxed into different fragment in mkv. (so it is fixed when remuxed by mkvmerge)

This problem is caused by the large encoding delay when pre-analysis is used, and video processing tends to lag much behind audio processing. Furthermore, TrueHD packets seems to be divided into very small pieces than I have expected, and the number of packets became very large, resulting in the audio packet buffer for muxing being exceeded. This has caused audio and video data in same time muxed into different fragment, and thus having problem when seeking.

I'll adjust audio packet buffer size to fix this.

But should HQVBR not follow set bitrate to such large extend?

I've got same behavior but not sure, there should not be QP limit as VBR mode seems to work fine.

[rigaya]

Thank you for the detailed report and sample files, shall be fixed with VCEEnc 8.23, which allows audio mux queue to extend more dynamically.

[DimkaTsv]

Can confirm fix, at least for cases i tested (HQVBR upscaled to 4k and to 8k), issue closed.