tuning x265 syntax for UHD /rec2020,HDR10/high quality

[SeeMoreDigital]

Originally Posted by lauguru

hello

How would you write the tweak for x265 of this encode?thanks


Chroma subsampling : 4:2:0 (Type 2)

Out of interest... What is 4.2.0 'type 2' all about? I've noticed it cropping up in a few of my sample files...

[microchip8]

Originally Posted by SeeMoreDigital

Out of interest... What is 4.2.0 'type 2' all about? I've noticed it cropping up in a few of my sample files...

same as yuv420p10.

[nevcairiel]

Originally Posted by SeeMoreDigital

Out of interest... What is 4.2.0 'type 2' all about? I've noticed it cropping up in a few of my sample files...

Its the value of chroma_sample_loc_type_top_field/bottom_field. Basically the location of the subsampled chroma sample. When you reduce 4 samples to just one, you need to remember which location you sampled at.

Type 0 is the "normal" type for 4:2:0 which we've been using for years, also known as the MPEG2-type (MPEG1 was different) - for every 4 Luma samples, the Chroma sample sits in between the two Luma samples on the left

Like this, Luma being X, Chroma o

X X
o
X X

Type 2 is the "new" standard userd in certain UHD specifications, where the Chroma sample sits right on top of the top left Luma sample, ie:
(Chroma location in red)

X X
X X

This distinction is important when upscaling Chroma, because doing it wrong can introduce a slight shift in the chroma.

[SeeMoreDigital]

Originally Posted by froggy1

same as yuv420p10.

Thanks.

Does 'type 2' offer any benefit over regular 4.2.0?

[microchip8]

Originally Posted by SeeMoreDigital

Thanks.

Does 'type 2' offer any benefit over regular 4.2.0?

I'm not sure but nev explained it above much better than my extremely short post. What i meant as yuv420p10 is that you'll only come it across on 10 bits files. I've never seen a Type 2 on 8 bits ones, like never

[nevcairiel]

I don't know why they decided to change it. Maybe because its simpler? But basically, unless you are downsampling your own chroma, you just have to use the value that matches your content.

[sneaker_ger]

Some specs may even require it. E.g. UltraHD Blu-Ray demands type 2 for all BT.2020 content.

[SeeMoreDigital]

Sorry Nev, I missed your post in between posting my reply to froggy.

There's a guy over on the AVforum who's having a problem playing certain "Nvidia Encoded HEVC files" on his LG Oled B6. I asked him to upload a MediaInfo file report and the only odd thing I could see was the 'type 2' tag.

I looked through my HEVC samples and found a few a 'type 2' tag files that play fine on my humble LG 65UH770V.

Anyway, I've asked him to provide some samples.


Many thanks for the replies everyone

[Asmodian]

Originally Posted by nevcairiel

I don't know why they decided to change it. Maybe because its simpler? But basically, unless you are downsampling your own chroma, you just have to use the value that matches your content.

I think it must be this. Scaling for all planes can be done relative to 0,0 at the top left.



Edit: Would 50% downscaling be faster and better quality? After all we already have all the exact chroma samples we need without any shifts or interpolation. This would be pretty common, displaying UHD on FHD displays.

[SeeMoreDigital]

Originally Posted by SeeMoreDigital

...There's a guy over on the AVforum who's having a problem playing certain "Nvidia Encoded HEVC files" on his LG Oled B6. I asked him to upload a MediaInfo file report and the only odd thing I could see was the 'type 2' tag.

Anyway, I've asked him to provide some samples.

Update time... After receiving three samples and running them through eac3to v3.34, it reported the following: -

MKV, 1 video track, 1 audio track, 0:00:29, 48i /1.001
1: h265/HEVC, 3840x2176 48i /1.001 (30:17), 10 bits
2: AC3, 5.1 channels, 640kbps, 48kHz
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[v01] This doesn't seem to be a valid h265/HEVC stream (3).  <ERROR>
Aborted at file position 44040192.  <ERROR>

As you guys can see, not only has the HEVC video stream been encoded with 2176 (instead of 2160) pixels, it's reported as being 48i... Crazy!

And just to make matters even stranger... When I re-muxed his samples into the .m2ts container using TSmuxer GUI v2.6.12, they actually played on my LG 65UH770V

[gonca]

Originally Posted by SeeMoreDigital

Update time... After receiving three samples and running them through eac3to v3.34, it reported the following: -

MKV, 1 video track, 1 audio track, 0:00:29, 48i /1.001
1: h265/HEVC, 3840x2176 48i /1.001 (30:17), 10 bits
2: AC3, 5.1 channels, 640kbps, 48kHz
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[v01] This doesn't seem to be a valid h265/HEVC stream (3).  <ERROR>
Aborted at file position 44040192.  <ERROR>

As you guys can see, not only has the HEVC video stream been encoded with 2176 (instead of 2160) pixels, it's reported as being 48i... Crazy!

And just to make matters even stranger... When I re-muxed his samples into the .m2ts container using TSmuxer GUI v2.6.12, they actually played on my LG 65UH770V

I encode a lot of 4k with NVEnc and I never got those weird results
Could be cmd line or source filter issue

[Qarmaa]

Can someone explain why --uhd-bd option is forcing --no-open-gop option? The problem is Scenarist UHD can't mux seamless connected clips with closed-gop encoded streams. Sure I can turn off --uhd-bd option and manually set parameters that makes compliant UHD BD stream, but with open GOP. That way Scenarist can mux seamless, I'm just aware of compatibility with hardware players.

[Qarmaa]

In addition to previous post. I'm getting following error when trying to mux stream encoded with --uhd-bd (closed GOP):

Error : [MUX] Can not write MUX file(s) : Could not create MUX XML File(Video data in TS2 does not start with a closed GOP.[PlayList: PlayList#1, PlayItem : Clip#2, Clip: Clip#2])

[FranceBB]

@Qarmaa... I think it's to increase compatibility with some players that might have difficulties with a GOP that is too long. In broadcast, a closed GOP is required, not sure about UHD BDs.

[Qarmaa]

Problem solved using last build (not stable). Now video encoded with --uhd-bd mux in seamless correctly.

[TEB]

Originally Posted by FranceBB

@Qarmaa... I think it's to increase compatibility with some players that might have difficulties with a GOP that is too long. In broadcast, a closed GOP is required, not sure about UHD BDs.

Where did u read that in broadcast Closed Gop is required? Ive been working with broadcast for 16 years and ive never closed a gop (besides in ABR stacks)

[excellentswordfight]

Originally Posted by TEB

Where did u read that in broadcast Closed Gop is required? Ive been working with broadcast for 16 years and ive never closed a gop (besides in ABR stacks)

Ye, we use opened GOP on our HEVC-UHD hw-encoder as well. Fixed GOP though.

[FranceBB]

@TEB and @excellentswordfight... I guess our playout playback ports are just particularly picky and demand it, then. For instance, the oldish ones we used for XDCAM50 1080i and the very old ones we used for DV25 576i required closed GOP. They were actually able to play open GOP files, but it wasn't recommended by specs and they said that it should have been avoided, in fact we tried with open GOP files and they took like a lot to seek, they were almost unseekable and this created issues coming back from a commercial break to resume playback at a specific timecode. They are probably one of the cheapest, yet crappiest playout ports. I wouldn't be surprised if other ports used by other companies (like yours) were able to play Open GOP files flawlessly.

[excellentswordfight]

Originally Posted by FranceBB

@TEB and @excellentswordfight... I guess our playout playback ports are just particularly picky and demand it, then. For instance, the oldish ones we used for XDCAM50 1080i and the very old ones we used for DV25 576i required closed GOP. They were actually able to play open GOP files, but it wasn't recommended by specs and they said that it should have been avoided, in fact we tried with open GOP files and they took like a lot to seek, they were almost unseekable and this created issues coming back from a commercial break to resume playback at a specific timecode. They are probably one of the cheapest, yet crappiest playout ports. I wouldn't be surprised if other ports used by other companies (like yours) were able to play Open GOP files flawlessly.

We have videoservers for XDCAM as well that needs closed GOP, I was talking about contribution encoders.

[user1085]

I see that Google has an official documentation page for VP9 HDR encoding with ffmpeg

https://developers.google.com/media/vp9/hdr-encoding/

I took most of the settings from here and changed libvpx-vp9 to libx265 and my Vizio TV detects and plays HDR10 (shows HDR10 info).

ffmpeg -i strobe_scientist_18Mbps.webm -b:v 18000000 -pass 1 \
  -pix_fmt yuv420p10le \
  -color_primaries 9 -color_trc 16 -colorspace 9 -color_range 1 \
  -maxrate 26800000 -minrate 8040000 -profile:v 2 -vcodec libvpx-vp9 /dev/null && \
   ffmpeg -i strobe_scientist_18Mbps.webm -b:v 18000000 -pass 2 \
   -pix_fmt yuv420p10le \
   -color_primaries 9 -color_trc 16 -colorspace 9 -color_range 1 \
   -maxrate 26800000 -minrate 8040000 -profile:v 2 -vcodec libvpx-vp9 \
   strobe_scientist_18Mbps.webm

Few follow up questions on this

• Are the settings above completely different from what's being discussed in this thread? I didn't see discussion around -color_primaries, -color_trc, -colorspace, -color_range
• Is there anything I can add to above command line to improve the encodes?
• The page mentions "HDR requires 2-pass encoding". Is that just for VP9 or is that true for x265 as well?because I'd like to use CRF if possible