x264 for Blu-ray - Video Underflows

[RainbowThief]

Occasionally when compiling a Blu-ray project I get a warning that there are video underflow errors. Can anyone suggest a way to fix this?

I encode on an iMac 5k 27" (Big Sur) via terminal/ffmpeg. Blu-ray authoring is done using Sony DoStudio.

A typical encode would be 30k/35k to 40k, with a buffer of 30k. Very slow, tune film.

-c:v h264 -preset veryslow -tune film -b:v 30000k -maxrate 40000k -bufsize 30000k -level 4.1 -pix_fmt yuv420p -x264-params bluray-compat=1: open-gop=1:slices=4:keyint=24:colorprim=bt709:transfer=bt709:colormatrix=bt709: pass=1 (then pass=2)

x264 core 164 r3075 66a5bc1

Here is a sample compile error message:

[FranceBB]

Try with:

x264.exe "\\VBOXSVR\Share_Windows_Linux\temp\AVS Script.avs" --x264-binary "x264.exe" --bitrate 25000 --preset medium --profile High --ref 4 --level 4.1 --keyint 24 --slices 4 --bframe 3 --deblock -1:-1 --bluray-compat --overscan show --range tv --log-level info --thread-input --opencl --colormatrix bt709 --transfer bt709 --colorprim bt709 --videoformat component --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --aud --pass 1 --output NUL

x264.exe "\\VBOXSVR\Share_Windows_Linux\temp\AVS Script.avs" --x264-binary "x264.exe" --bitrate 25000 --preset medium --profile High --ref 4 --level 4.1 --level-force --keyint 24 --slices 4 --bframe 3 --deblock -1:-1 --bluray-compat --overscan show --range tv --log-level info --thread-input --opencl --colormatrix bt709 --transfer bt709 --colorprim bt709 --videoformat component --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --aud --pass 2 --output "\\VBOXSVR\Share_Windows_Linux\temp\raw_video.h264"


ffmpeg.exe -i "\\VBOXSVR\Share_Windows_Linux\temp\AVS Script.avs" -vn -sn -af loudnorm=I=-24:LRA=10:tp=-2 -c:a dca -b:a 1536k -ar 48000 -strict -2 "\\VBOXSVR\Share_Windows_Linux\temp\audio.dts"
ffmpeg.exe -i "\\VBOXSVR\Share_Windows_Linux\temp\AVS Script.avs" -vn -sn -af loudnorm=I=-24:LRA=10:tp=-2 -c:a ac3 -b:a 384k -ac 2 -ar 48000 "\\VBOXSVR\Share_Windows_Linux\temp\audio.ac3"

"C:\Program Files\MKVToolNix\mkvmerge.exe" --output "\\VBOXSVR\Share_Windows_Linux\temp\raw_video.mkv" --language 0:und ^"^(^" \\VBOXSVR\Share_Windows_Linux\temp\raw_video.h264 ^"^)^"

ffmpeg.exe -i "\\VBOXSVR\Share_Windows_Linux\temp\raw_video.mkv" -i "\\VBOXSVR\Share_Windows_Linux\temp\audio.dts" -i "\\VBOXSVR\Share_Windows_Linux\temp\audio.ac3" -map 0:0 -map 1:0 -map 2:0 -c:v copy -c:a copy -c:a copy -metadata provider_name="Bluray" -metadata service_provider="Bluray" -metadata service_name="Bluray" -mpegts_original_network_id 0x1122 -mpegts_transport_stream_id 0x3344 -mpegts_service_id 0x5566 -mpegts_pmt_start_pid 0x1500 -mpegts_start_pid 0x150 -mpegts_service_type "digital_tv" -mpegts_flags "resend_headers" "\\VBOXSVR\Share_Windows_Linux\temp\final.m2ts"

pause

and then mux that file with Scenarist or whatever you're using to the BD. It should work.

[RainbowThief]

Thanks for the feedback, I don't know what the AVSscript you have linked to is?

I'm not sure what actually causes a video underflow error - can somebody explain? Does it relate to the encoded 264 file, or a combination of all video and audio (and subtitle) streams?

In my error message posted above, does this mean the error occurs just 2.54 seconds into the 94 minute video file?

[FranceBB]

Originally Posted by RainbowThief

Thanks for the feedback, I don't know what the AVSscript you have linked to is?

It's just an indexer with the source. In your case, since you're based on OSX, it can just be FFMpeg -i which decodes the source and passes it to x264 with the parameters listed above.
About the buffer, looks like x264 is struggling to keep the bitrate within the constraints as there's something that caught it by surprise, which is weird considering that you're using a two pass encode so it should be prepared. Anyway please test with the parameters I gave you.

[RainbowThief]

Thanks - which particular parameters should I try adding to my command string?

[RainbowThief]

These are not recognised by terminal on Mac:

-log-level info -thread-input -opencl

[FranceBB]

Originally Posted by RainbowThief

These are not recognised by terminal on Mac:

-log-level info -thread-input -opencl

No problem, they're not important.

[jpsdr]

Sometimes the issue is not only with video, but audio + video bitrate which goes too high. I had once the issue of muxing a Blu-Ray with Scenarist and according the audio i add to the video, run (or not) with buffer underflow. When it happens, i change [--vbv-maxrate 40000 --vbv-bufsize 30000] to [--vbv-maxrate 39000 --vbv-bufsize 29500]. If it's still happening, i go to [--vbv-maxrate 38000 --vbv-bufsize 29000]. You can also try [--vbv-maxrate 39900 --vbv-bufsize 29950], to see if it's not x264 just going a little out of spec...

Edit : You lack --bluray-compat --aud --min-keyint 1 --mvrange 511 --ref 4 --bframe 3 options for targetting Blu-Ray, and --level-force can be good also.
Also, after a "talk" with mp3dom, it seems that in the very specific case of targetting Blu-Ray, disabling MBTree produce a little better results, so --no-mbtree can improve.
Not mandatory, but --b-pyramid strict --open-gop can also improve.

[FranceBB]

Added them to my usual command line too, thanks for the tip.

[mp3dom]

x264 have too much bitrate oscillation and can easily go above 40 Mbps. Even if "theoretically" the stream is compliant (adhere to VBV restrictions), when muxing it can quite easily create over/underflows. Not to say that, when the things gets more complicated (i.e. multi-angle or different streams joined with seamless connection) it's a total mess of underflows and "invalid atc delta" errors. The solution is to lower the avg/max bitrate and/or vbv-bufsize, to make the bitrate spikes less frequent.

[RainbowThief]

It seems it's the two dts files that are causing the error. If I use the uncompressed wav files there are no underflow errors.

[mp3dom]

dts stereo vs. lpcm stereo or dts 5.1ch vs. lpcm stereo?
This seems a bit odd, because there are only a very few instances where a dts file can be higher than lpcm (with same number of channels) and are mainly when you set the dts-core to have the same or higher bitrate than the lpcm itself.

[Sharc]

Originally Posted by mp3dom

x264 have too much bitrate oscillation and can easily go above 40 Mbps. Even if "theoretically" the stream is compliant (adhere to VBV restrictions), ......

Spikes followed by dips in the subsequent GOP which - in worst case - tend to temporary blocking artefacts. Can happen, yes.

[mp3dom]

Originally Posted by Sharc

Spikes followed by dips in the subsequent GOP which - in worst case - tend to temporary blocking artefacts. Can happen, yes.

Yep, I know that effect very well.