Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Post-Encode Crop #303

Closed
tazlord opened this issue Jan 30, 2021 · 4 comments
Closed

[Feature Request] Post-Encode Crop #303

tazlord opened this issue Jan 30, 2021 · 4 comments

Comments

@tazlord
Copy link

tazlord commented Jan 30, 2021

Hello,
NVENC's HEVC encoder is designed to follow the h.265 specification. Unfortunately, NVENC follows the specification too well. The lowest size CTB that can be encoded by NVENC is 32x32. This means that a resolution dimension (H or W) that is not a multiple of 32 is not possible (i.e. 2160 or 1080).

For Example:
When encoding a 4K video (3840x2160) using NVENC, 2160 is not a multiple of 32. The result is the video height is padded to 2176 pixels.
Similarly, when encoding HD video (1920x1080), 1080 is not a multiple of 32. The result is the video height is padded to 1088 pixels.

The reason I am asking for this feature is because there are certain popular hardware players that will not accept video streams with the "strange" resolution. I realize that any player that is h.265 compliant should understand the strange resolution and play the video but a very good example of the problem would be with the Xbox Series X/S. If you try to play a video with a height larger than 2160, the Xbox will not play it. Yes, Microsoft should fix that issue. However, I am of the opinion that if the source is as "clean" as possible, there is no need to rely on software/hardware implementations to fix the issue, which can take months or years to fix.

I know there is already an existing crop function here. However, after some testing, it seems to be performing the crop as the first step, before any color space conversion and before the encoding. Since the encoder will pad the video to the next highest multiple of 32, this pre-encode crop doesn't solve the problem.

Is there a way to add a crop function AFTER the encoding so the output video can be restricted to the specified dimensions of the format resolution (i.e. 2160 or 1080)?

Thank you for your time

@rigaya
Copy link
Owner

rigaya commented Jan 31, 2021

I've not heard of a explicit "post-encode" cropping, and I think generally it is done by the decoder.

HEVC encoders will code by 32x32 block, so when you encode fullHD(1920x1080) video, it is internally padded to meet the block size and coded as 1920x1088. The decoder or the player should crop the last 8 pixels after decoding if the resolution is 1920x1080, and I think there are nothing we can do when encoding.

Also, I don't think 4K (3840x2160) or fullHD (1920x1080) is a "strange resolution", as it's very common.

@tazlord
Copy link
Author

tazlord commented Jan 31, 2021

Thank you for the fast reply.
I apologize for my bad explanation. I will try to explain again.

When I spoke of "strange" resolution, I was referring to the product of a 32x32 block.
When encoding a video with NVenc, the following resolutions are produced:
3840x2160 (normal) becomes 3840x2176 (strange)
1920x1080 (normal) becomes 1920x1088 (strange)

This only seems to happen when using NVenc as the encoder. Yes, it makes sense because NVenc will only encode blocks of 32x32 or 64x64 (ITU H.265 compliant). However, when I use x265 (CPU) to encode the same file, I do not see the strange resolution in the metadata.

Below are the dimensions denoted in the metadata for each type of encode (using MediaInfo):

NVenc

{
"Width": "3840",
"Height": "2160",
"Stored_Height": "2176",
"Sampled_Width": "3840",
"Sampled_Height": "2160",
"PixelAspectRatio": "1.000",
"DisplayAspectRatio": "1.778"
}

x265

{
"Width": "3840",
"Height": "2160",
"Sampled_Width": "3840",
"Sampled_Height": "2160",
"PixelAspectRatio": "1.000",
"DisplayAspectRatio": "1.778"
}

As you can see, there is an extra field, "Stored_Height", in the metadata for a video encoded using NVenc. Unfortunately, there is no way for me to know if the x265 output is HEVC compliant and the metadata is simply modified or if the output was cropped after encoding to remove the padding. However, the x265 files do play without any issues on all of my devices and are almost identical to the raw files you can find on retail UHD Blu-Ray discs. The files created using NVenc (via your tool) will not play on all of my devices. As I mentioned in my initial post, the Xbox Series X/S will not play the NVenc encoded files. It returns an error stating that the video dimensions exceed 3840x2160 and is not supported. I realize this is an issue with Microsoft's software/hardware player. However, waiting for Microsoft to address this issue will take years.

My question now is, if x265 is capable of creating a 3840x2160 file without the "strange" metadata, is there a possibility that your tool can do the same thing?

Thanks again for your time.

@rigaya
Copy link
Owner

rigaya commented Feb 1, 2021

Thank you for the detailed explanation with the details, now I understand better of the issue.

The problem is that NVNEC hardware encoder only allows 32x32 CTU, I've checked for the NVENC SDK for parameters to control CTU size, but could not find any, only CU size was configurable.

At the below link we are able to find more details. It mentions that the lowest CTU size encoded by NVNEC hardware for HEVC is 32x32, and unfortunately currently there seems to be no way to avoid this problem, even on Ampere Gen GPUs.
https://forums.developer.nvidia.com/t/nvenc-hevc-encoding-of-3840x2160-results-in-coded-size-of-3840x2176/60107

At this time, it might be better to use x265, QSVEnc or VCEEnc which doesn't have this kind of limitation.

@tazlord
Copy link
Author

tazlord commented Feb 1, 2021

I understand. Thank you for the update.

@rigaya rigaya closed this as completed Mar 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants