Closed DimkaTsv closed 1 month ago
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.
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.
Can confirm fix, at least for cases i tested (HQVBR upscaled to 4k and to 8k), issue closed.
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).
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:
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 fileVCEEnc 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 fileMKVToolNix 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?