Encoding H265 for UHD-BD

[Thaddäus]

Hello,

first of all: This is my first attempt of encoding and burning something for UHD, but I ran into a strange problem.

My player is a Panasonic UBP-824, the European version of the 820 and AFAIK it's not capable of reading BD-R XL. Now I was messing with a film that actually fit onto a BD-50. I replaced the audio-tracks etc. and also added a Dolby Vision-layer (the original just had HDR10) and muxed it using tsMuxeR. Playback starts fine, but when bitrates exceed around 60-65 MBit/s for a few seconds, it starts to stutter.

First I thought it was an issue with my Dolby Vision-experiment, but even when I just left it as it was with HDR10 I'm having the same issues. So I assumed it has something to do with limitations on the BD-R, hence why I tried to reencode the video and limit the bitrate to 60000 kbps. Here's the command-line I used:

ffmpeg.exe -hwaccel_output_format cuda -probesize 100MB -i input.m2ts -pix_fmt yuv420p10le -an -f yuv4mpegpipe -strict -1 - | x265-10b.exe --y4m --fps 24000/1001 --input-csp 1 --input-depth 10 --output-depth 10 --no-interlace --preset medium --vbv-maxrate 60000 --vbv-bufsize 60000 --uhd-bd --bitrate 50000 --pass 1 --slow-firstpass --sar 1 --hrd --aud --chromaloc 2 --hdr-opt --colorprim bt2020 --transfer=smpte2084 --colormatrix bt2020nc --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" - -o nul

ffmpeg.exe -hwaccel_output_format cuda -probesize 100MB -i input.m2ts -pix_fmt yuv420p10le -an -f yuv4mpegpipe -strict -1 - | x265-10b.exe --y4m --fps 24000/1001 --input-csp 1 --input-depth 10 --output-depth 10 --no-interlace --preset medium --vbv-maxrate 60000 --vbv-bufsize 60000 --uhd-bd --bitrate 50000 --pass 2 --sar 1 --hrd --aud --chromaloc 2 --hdr-opt --colorprim bt2020 --transfer=smpte2084 --colormatrix bt2020nc --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" - -o output.hevc

After burning it again, it plays much better than before, but it still has 5-6 scenes where it starts to stutter for a couple of seconds. Checking the bitrates, it seems that my 60000 kbps-limitation was just ignored and I'm running more or less into the same problem that I had with the original video. The only difference is that it's not that permanent. I've attached a visualization of the bitrates from my results.

As mentioned before, it's the first time I'm trying to encode something for UHD, but perhaps someone can point me at the reason why it still uses higher bitrates which result in those playback-issues on the Panasonic.

Thanks in advance for your help!

[cubicibo]

tsMuxer does not make advanced considerations to the buffer and bandwidths to deliver packets. Hence stuttering could be an overflow or underflow of individual elementary decoders due to the mux, and not due to your encode parameters which are UHD BD compliant.

[Thaddäus]

So you think the issue isn't the actual encode, but what tsMuxeR creates from it? So I might not even need the reencoded version and I can use the original stream as I tried in first place? And if so: How can I get around this issue?

And maybe as an additional info: The stuttering only happens on the Panasonic-player (as well as on the PS 5). Playing it with VLC works fine and it even worked on a Panasonic UHD-recorder of a friend.

[cubicibo]

There is no free software ITU H.222 compliant muxer, unfortunately.

Few suggestions you could try:
- Use CBR for all streams.
- Work with lower target bitrate.
- Have more asymmetry in vbv-bufsize and vbv-maxrate. maxrate should be larger than bufsize to have packet lifetime smaller than 1 second in the decoder (BD spec. constraint).

No guarantee any of these will work. DVD-Logic suggests --vbv-maxrate 80000 --vbv-bufsize 50000 --bitrate 50000 for content with HDR FWIW.

[Thaddäus]

Too bad, so adjusting any values in tsMuxeR or running it through BD-Rebuilder etc. afterwards won't help either?

I also tried to check the bitrates of my reencode again by muxing it into MKV and FFBitrateViewer gives me the same curve as ahead with the m2ts. I actually thought vbv-maxrate 60000 and vbv-bufsize 60000 would limit the bitrate to 60 MBit/s, but as you can see it goes higher a lot of times (at 33 minutes even with a peak over 90000 kBit/s) and the areas with the high density in the curve above 60000 (around 10 minutes, 25 minutes or at the end between 80 and 85 minutes) that's where the playback starts to stutter on the Panasonic.

[FranceBB]

Here's the command-line I used:

--bitrate 50000 --vbv-maxrate 60000 --vbv-bufsize 60000

it seems that my 60000 kbps-limitation was just ignored

I know this one and fun fact I ran into the exact same issue (https://forum.doom9.org/showthread.php?p=1967003) (albeit on a different hardware and on x264 but it's the same for x265) and the culprit is the buffersize.
The buffer size calculation needs to be done as follows:

buffersize = bitrate / fps

So, in your case, given a bitrate of 50 Mbit/s and a framerate of 23,976, it would be 50000/24 = 2084
Try with that and you'll see that the bitrate will stay within the specified range. ;)


I actually thought vbv-maxrate 60000 and vbv-bufsize 60000 would limit the bitrate to 60 MBit/s.

Yeah, it's very unintuitive and I fell down the same trap, but it doesn't, --vbv-bufsize 60000 at a framerate of 23,976 means 24 * 60 = 1440 Mbit/s, so 1.4 Gbit/s max oscillation.
Obviously x265 won't generate such a thing, but still...
Ever since I started using the buffersize = bitrate / fps formula I've never had issues with any of my encodes with hardware decoders. :)

[Thaddäus]

Will try with a short test-encode of a scene! Thanks! :)

EDIT: Just one more thought: You're saying the values I used before can create a 1.4 Gbit/s oscillation (in theory). But wouldn't an oscillation of just 2084 only allow very small variations from the average bitrate and it'll give me more of a CBR-result?

[Thaddäus]

OK, so lowering the vbv-bufsize to 2084 is giving me some errors during encoding. When it starts it says "VBV buffer size cannot be smaller than one frame, using 2502 kbit" and then again there are some VBV underflow-messages throughout.

[cubicibo]

The buffer size calculation needs to be done as follows:

buffersize = bitrate / fps

So, in your case, given a bitrate of 50 Mbit/s and a framerate of 23,976, it would be 50000/24 = 2084
Try with that and you'll see that the bitrate will stay within the specified range. ;)



You are brute-forcing CBR with this approach. This should never be used in practice as TS muxing overhead can lead to underflows in the video pathways (buffers and main decoder).
Furthermore, it is absolutely normal for VBV encodes to show sequences of spikes and pits.

Anyway, you can further reduce the oscillations with the "strict-cbr" option. And, if needed, you can still try FranceBB suggestion to "force" CBR or reduce oscillations by reducing the VBV values. Just remember that vbv-maxrate must be larger than the vbv-bufsize, and do not use the bare minimum, no chance it will work appropriately with Blu-ray players.

[Thaddäus]

Did some testing now with a 1000 Frames encode and here's what I got:

-vbvbufsize 50000 -maxrate 80000
Average Bitrate: 49892 kbit/s, Maximum: 78056 kBit/s - meets the target average bitrate and also stays within the maxrate of 80000 kBit/s

-vbvbufsize 2084 -maxrate 60000
Average Bitrate: 42391 kBit/s, Maximum: 46448 kBit/s - stays within the desired limit, but doesn't even reach the target bitrate of 50000 and is almost CBR, had VBV underflow-warnings during encoding and the results have some blocking-artifacts (perhaps due to the warnings)

-vbvbufsize 50000 -maxrate 60000
Average Bitrate: 49796 kBit/s, Maximum: 78129 kBit/s - very similar to the first attempt with maxrate 80000, desired maxrate of 60000 exceeded

-vbvbufsize 10000 -maxrate 60000
Average Bitrate: 49138 kBit/s, Maximum: 64516 kBit/s - almost there, might already work

-vbvbufsize 5000 -maxrate 60000
Average Bitrate: 48095 kBit/s, Maximum: 60317 kBit/s - almost meets the desired maximum, but the average is 1900 kBit/s under the target

-vbvbufsize 7500 -maxrate 60000
Average Bitrate: 48741 kBit/s, Maximum: 61567 kBit/s

Of course this was just a 1000 Frames test-encode, but assuming the results would be similar for the entire film, the last settings might work out.

As I said: All I want it to do is to playback fine from a BD-R DL on the UHD-player. I don't want to force it into CBR, it should just take the specified values for the maximum bitrate into account, so I'm not going to run into those playback-issues again. Would you say the settings with vbvbufsize 7500 and maxrate 60000 would be OK for that or might this just lead to other problems again?

That also leads me to another question: I already mentioned that I've added a Dolby Vision-layer from a Web-source to the HDR10 from the original disc. I did that by using DDVT Tools to extract the RPU and for the EL-layer I tried to use UniFab to create a 1080p-encode at 2500 kBit/s CBR from the BL-layer and later injected the RPU to that newly created 1080p-encode. However, it turns out that the video is also not really CBR. Bitrates are VBR with a peak of over 17000 kBit/s. So I wonder if I could also use a dummy-video that's being encoded at 1080p in H265, 10 Bits and just has the same amount of frames as the BL, e.g. a blank clip encoded at 1000 kBit/s CBR. Or does it really have to be a (shitty) encode of the actual film?

[cubicibo]

VBV maxrate does not define any physical bitrate. The value used will not reflect the actual bitrate of the stream.
Essentially VBV is just a constraint for the encoder. It simulates a very basic decoder at the encoder output with a bitrate of maxrate and some buffering capacity. However, the actual output video stream could use up to vbv-maxrate + vbv-bufsize data to display something. The bitrate here would be much larger than vbv-maxrate. And this is why after a spike you have a pit, and the depth of the pit depends on the "excess" bitrate you used in comparison to vbv-maxrate.

You can read an alternate explanation here (https://forum.doom9.org/showthread.php?t=147460) if mine is not convincing.

[Thaddäus]

Thanks for the explanation!
I just figured out during playback that the stuttering was connected to the bitrate exceeding about 65 MBit/s for a couple of seconds or going even higher, hence why I'm desperately trying to limit it to 60000. But yeah, knowing what vbvbufsize does it makes sense, although the maxrate-value leads to confusion then. Though it doesn't really make the choice easier which settings to use to get results that will work. Given the results of my test-encode, I'm hopefully safe with the vbvbufsize 7500 and maxrate 60000-settings. Perhaps other settings could work too, but from what I saw during my previous attempts, the issue was definitely there when bitrates went into the 70 MBit/s-regions or even higher. Until 65 MBit/s it was a matter of how long bitrates were around that value (that's when most likely the buffer of the player ran out of space) and with values up to 60 or lower it ran smoothly all the time.

Surprised though that I couldn't find out much information about similar issues. I know people aren't burning discs a lot anymore, but when I found questions from someone who was trying to burn any UHD-stuff onto a BD-R, I never ran into posts about issues with stuttering playbacks due to high bitrates etc.

[cubicibo]

You could play with --min-vbv-fullness and --max-vbv-fullness to give very little leeway to the encoder with respect to bitrate spikes, but there is no guarantee you will have a compliant encode.

[Thaddäus]

I'll try and see what happens with vbvbufsize 7500 / maxrate 60000. Fingers crossed it'll end up with a playable result! :)

But maybe someone can give me an answer about my other question too, regarding the DV-layer:

That also leads me to another question: I already mentioned that I've added a Dolby Vision-layer from a Web-source to the HDR10 from the original disc. I did that by using DDVT Tools to extract the RPU and for the EL-layer I tried to use UniFab to create a 1080p-encode at 2500 kBit/s CBR from the BL-layer and later injected the RPU to that newly created 1080p-encode. However, it turns out that the video is also not really CBR. Bitrates are VBR with a peak of over 17000 kBit/s. So I wonder if I could also use a dummy-video that's being encoded at 1080p in H265, 10 Bits and just has the same amount of frames as the BL, e.g. a blank clip encoded at 1000 kBit/s CBR. Or does it really have to be a (shitty) encode of the actual film?

[Z2697]

EL is never ever some replica of the actual film.
It's either all zero (MEL) or some processed difference of bitdepth (FEL).

In your case it should be MEL if it even makes sense

[Thaddäus]

OK, so I can just create a black clip with the duration of the actual film and encode it as H.265, 10 Bits, HDR10 with a very low bitrate (1500 kBit/s or so)?

In the tutorial I found about adding Dolby Vision from a different source into a disc-strutcture, they were re-encoding the actual film at 1080p in H.265, 10 Bits, HDR10 and injected the RPU to that. But on actual retail-discs it seems to be different, hence why I'm asking. ;)

[halls]

I'll try and see what happens with vbvbufsize 7500 / maxrate 60000. Fingers crossed it'll end up with a playable result! :)

But maybe someone can give me an answer about my other question too, regarding the DV-layer:



...better if u try to make hdr10+ meta from webdl dovi, and inject this meta in to the encode....

EL layer process is not simple as you think.

Check your command line...some info u can get from here:

https://forum.fanres.com/thread-2674.html

[Thaddäus]

I'm currently trying to do the re-encode with the last settings (vbvbufsize 7500, maxrate 60000) and after the first pass finished, there are 7 VBV underflow-warnings. Could this become a problem later when trying to play it on an UHD-player or can I just ignore them? Or are they probably gone after the second pass?

[benwaggoner]

I'm currently trying to do the re-encode with the last settings (vbvbufsize 7500, maxrate 60000) and after the first pass finished, there are 7 VBV underflow-warnings. Could this become a problem later when trying to play it on an UHD-player or can I just ignore them? Or are they probably gone after the second pass?
Maybe? But probably not? It depends on the magnitude of warnings.

Also, VBV is a surprisingly challenging thing to define and measure reproducibly, so having some warnings is quite common. Backing off vbv-bufsize and vbv-maxrate another 5000 might make them go away. If they don't, it's probably not an actual rate control problem.

[Thaddäus]

In pass 2 I got more VBV underflow-warnings, but on different timecodes than in the first pass. However, I tried again to master the results into my Blu-ray-structure and finally it plays smoothly on the Panasonic from beginning to the end. :)

[cubicibo]

VBV compliance guarantees that a hardware decoder will not have an issue.
VBV non-compliance does not guarantee that a hardware decoder will have an issue.

At the end of the day, VBV is only shaping the datastream at the elementary stream level with some key constraints. The muxer remains responsible for scheduling the packets and ensure proper management of all the buffers in the decoder. Again, it all comes down to the muxer. Since tsMuxer does not perform proper buffer management, it may fail to schedule packets appropriately for files with highly variable bitrates and this is exactly what you have witnessed with your trials. Glad you sorted it out.