Audio decoding errors / Muxing buffer overflow?

[warrex1979]

With some files I immediately receive audio decoding errors.

Step 1: Simple conversion with NVEncC

Command line: NVEncC64 --avsw -i "infile.mkv" --audio-codec aac -o "outfile.mkv"

Errors:

avout: avcodec writer: ignore error(1) on audio #2 decode at 2(0.002)
avout: avcodec writer: ignore error(2) on audio #2 decode at 3(0.003)
avout: avcodec writer: ignore error(3) on audio #2 decode at 3(0.003)
avout: avcodec writer: ignore error(4) on audio #2 decode at 4(0.004)
avout: avcodec writer: ignore error(5) on audio #2 decode at 5(0.005)
[truehd @ 00000224a6cc78c0] restart header sync incorrect (got 0x1c10)
avout: avcodec writer: ignore error(6) on audio #2 decode at 6(0.006)
[truehd @ 00000224a6cc78c0] Invalid blocksize.
avout: avcodec writer: ignore error(7) on audio #2 decode at 7(0.007)
[truehd @ 00000224a6cc78c0] too many audio samples in frame
avout: avcodec writer: ignore error(8) on audio #2 decode at 8(0.008)
[truehd @ 00000224a6cc78c0] substream 0 length mismatch
avout: avcodec writer: ignore error(9) on audio #2 decode at 8(0.008)
[truehd @ 00000224a6cc78c0] substream 0 length mismatch
avout: avcodec writer: ignore error(10) on audio #2 decode at 9(0.009)
[truehd @ 00000224a6cc78c0] substream 0 length mismatch
avout: avcodec writer: failed to decode audio #2 for 11 times.
Error FlushEncoder: 20.

Step 2: Testing decoding of the audio track with ffmpeg

Command line: ffmpeg -loglevel error -i "infile.mkv" -map 0:2 -f null -

Errors: no errors

Step 3: Testing a simple conversion with ffmpeg

Command line: ffmpeg -loglevel error -i "infile.mkv" -map 0:v -map 0:2 -f null -

Errors:

Too many packets buffered for output stream 0:1.

Step 4: Adding -max_muxing_queue_size 1024

Command line: ffmpeg -loglevel error -i "infile.mkv" -map 0:v -map 0:2 -max_muxing_queue_size 1024 -f null -

Errors: no errors

Question: Is it possible that NVEncC also suffers from ffmpeg bug #6375 (https://trac.ffmpeg.org/ticket/6375) altough it outputs different errors? And if so can you work around it by making "-max_muxing_queue_size" available as an option or setting it internally to a safe value?

[warrex1979]

Just found a small test clip online: https://we.tl/Ufd0JVRXec
Source: https://thedigitaltheater.com/dolby-trailers/

[rigaya]

Thank you for the information and also providing a sample video which reproduces the issue. Thanks to the sample, I was able to fix this issue. It was caused by timestamp pattern which I did not expect. (but not related to max_muxing_queue_size.)

NVEnc 4.57 should solve this problem.

[warrex1979]

Seems to work fine at first. But encoding ca. two hour long 1080p content with truehd tracks results in system memory usage which climbs up to 20GB and during the encode the performance of it continuously drops. See the encodes below with the same basic command line as above:

With TrueHD:

NVEncC (x64) 4.57 (r1261) by rigaya, Dec 5 2019 22:53:35 (VC 1923/Win/avx2)
OS Version Windows 10 x64 (18362)
CPU Intel Core i7-6700K @ 4.00GHz [TB: 4.20GHz] (4C/8T)
GPU #0: GeForce RTX 2060 (1920 cores, 1680 MHz)[PCIe3x16][441.8]
NVENC / CUDA NVENC API 9.1, CUDA 10.2, schedule mode: auto
Input Buffers CUDA, 20 frames
Input Info avcuvid: H.264/AVC, 1920x1080, 24000/1001 fps
Vpp Filters copyDtoD
Output Info H.264/AVC high @ Level auto
1920x1080p 1:1 23.976fps (24000/1001fps)
avwriter: h264, #1:ac3/5.1(side) -> aac/5.1(side)/192kbps,
#2:truehd/7.1 -> aac/7.1/192kbps => mp4
Encoder Preset default
Rate Control CQP I:20 P:23 B:25
Lookahead off
GOP length 240 frames
B frames 3 frames [ref mode: disabled]
Ref frames 3 frames, MultiRef L0:auto L1:auto
AQ off
Others mv:auto cabac deblock adapt-transform:auto bdirect:auto
[matroska,webm @ 0000019223b58740] Element at 0x67d174c7e ending at 0x67d1c22c5 exceeds containing master element ending at 0x67d174c77

encoded 180851 frames, 60.94 fps, 2201.90 kbps, 1979.94 MB
encode time 0:49:27, CPU: 23.6%, GPU: 2.3%, VE: 12.7%, GPUClock: 1390MHz, VEClock: 1283MHz
frame type IDR 754
frame type I 754, avgQP 20.00, total size 36.42 MB
frame type P 45213, avgQP 23.00, total size 727.89 MB
frame type B 134884, avgQP 25.00, total size 1215.62 MB

With DTS:

NVEncC (x64) 4.57 (r1261) by rigaya, Dec 5 2019 22:53:35 (VC 1923/Win/avx2)
OS Version Windows 10 x64 (18362)
CPU Intel Core i7-6700K @ 4.00GHz (4C/8T)
GPU #0: GeForce RTX 2060 (1920 cores, 1680 MHz)[PCIe3x16][441.8]
NVENC / CUDA NVENC API 9.1, CUDA 10.2, schedule mode: auto
Input Buffers CUDA, 20 frames
Input Info avcuvid: H.264/AVC, 1920x1080, 24000/1001 fps
Vpp Filters copyDtoD
Output Info H.264/AVC high @ Level auto
1920x1080p 1:1 23.976fps (24000/1001fps)
avwriter: h264, #1:dca/5.1(side) -> aac/5.1(side)/192kbps,
#2:dca/5.1(side) -> aac/5.1(side)/192kbps => mp4
Encoder Preset default
Rate Control CQP I:20 P:23 B:25
Lookahead off
GOP length 240 frames
B frames 3 frames [ref mode: disabled]
Ref frames 3 frames, MultiRef L0:auto L1:auto
AQ off
Others mv:auto cabac deblock adapt-transform:auto bdirect:auto
[matroska,webm @ 0000029c9b678740] Element at 0x5a228224e ending at 0x5a22c453f exceeds containing master element ending at 0x5a2282247

encoded 148578 frames, 359.53 fps, 13872.74 kbps, 10248.25 MB
encode time 0:06:53, CPU: 16.9%, GPU: 5.4%, VE: 68.0%, GPUClock: 1912MHz, VEClock: 1775MHz
frame type IDR 620
frame type I 620, avgQP 20.00, total size 96.31 MB
frame type P 37145, avgQP 23.00, total size 3415.67 MB
frame type B 110813, avgQP 25.00, total size 6736.27 MB

I think there is still something broken. #177 also suggests this. Btw: System memory usage also rises with DTS tracks during the encode but not nearly as fast.

[rigaya]

I've found memory leak in audio processing which seems to be causing the continuous rise in system memory usage, I'll fix it in next release.

[rigaya]

NVEnc 4.58 should fix the memory leak in audio processing, below shows the virtual mem usage of NVEncC when handling trueHD audio.

The mem usage of NVEnc 4.57 continuously rises, but the mem usage of NVEnc 4.58 keeps stable.

[warrex1979]

Thank you. Looks good. No excessive memory usage usage or performance drops on a clip with 2 TrueHD tracks. Currently I cannot see reason to keep this open. Closed.