Handbrake H.265 GPU encoding and deinterlace to 50fps

[Slogra]

So i tried Handbrake H.265 (AMD VCE) which is incredibly fast.
However the final filesize is very big.
H.265 (AMD VCE) CQ 20 is almost twice as big as x.265 CRF20.

It is possible to improve the filesize? Or is GPU h.265 just much less space efficient than software x.265?

Another question i have about Handbrake is how to deinterlace to 50fps unique frames. Is BOB the way to go, or is that poor quality? Do i need a custom setting for good quality?

[RanmaCanada]

AMD's HEVC encoding is rather poor (https://rigaya.github.io/vq_results/). For deinterlacing most people do avisynth or vapoursynth as the deinterlacing in handbrake is rather simple. Typically you'd want something like bob and weave, pending on which frame is where in the interlacing. It's odd though as most 50fps content these days would be progressive, unless you're doing SD content, which would be better served to be left alone, or use H264 if you really do to compress it down.

But in general GPU is less space efficient than software as they can only use fixed functions (simple reason).

[benwaggoner]

AMD's HEVC encoding is rather poor (https://rigaya.github.io/vq_results/). For deinterlacing most people do avisynth or vapoursynth as the deinterlacing in handbrake is rather simple. Typically you'd want something like bob and weave, pending on which frame is where in the interlacing. It's odd though as most 50fps content these days would be progressive, unless you're doing SD content, which would be better served to be left alone, or use H264 if you really do to compress it down.

But in general GPU is less space efficient than software as they can only use fixed functions (simple reason).
I'd say that 50i production remained common a bit longer than 60i, as PAL regions already had more pixels and adopted HD a little later.

With the big exception of 24p sources, which became 30i with inverse telecine (two out of five frames interlaced), while PAL just got sped up 4% to 25p.

For content from the last 20 years that's all interlaced frames, it seems more likely to be from PAL regions or Japan.

[Slogra]

Thanks!

GPU encoding is not the way to go for me then. The output is not much smaller than the source mpeg2.
I normally use Ripbot264, but i liked the idea of GPU encoding in Handbrake.

The source is an old fairly noisy DVD. And i did some encoding tests with a few filters and codecs in Ripbot264:

- x.264 Mdegrain2 285MB (Slow and heavy CPU usage)
- x.264 KNLMeansCL mono noise 2. 299MB (Quality is not good enough)
- x.264 KNLMeansCL adaptive mono noise 2. 325MB (Quality is similar to normal clmeans)
- x.264 FFT3DGPU bt=0, sigma=1. 288MB. (Needs manual script editing. 50fps. Slow however low CPU and low GPU usage(!?). There seems to be a bottleneck). Quality is slightly better than KNLMeansCL.
- x.264 KNLMeansCL h1 319MB
- x.264 without filter. 160fps. 332MB. I expected it to be faster. I think the bottleneck is not the encoder, but the deinterlacing (edit: added later to the list)
- x.265 crf20 veryfast 10bits Mdegrain2. 50fps. 220MB (edit: added later to the list)
- x.265 crf20 veryfast. 140fps. 255MB.
- x.265 crf20 default 120fps. 297MB (!)
- x.265 veryfast 10bits 120fps 255MB


I would choose x.265 crf20 veryfast 8 bits without any filter. Encoding is fast, filesize ok and quality is good.
HOWEVER on my laptop MPC-HC with hardware decoding (LAV filter with DXVA2) it did not play correctly at all, which i never saw before in any h.265 video!
x.265 10 bits plays without issues, so i had to go for that, even though encoding is a bit slower.

[Emulgator]

Sample & script uploaded to wetransfer.com or any other filehoster would help.

[Slogra]

You mean for the playback issue on my laptop?

The issue happens with DXVA2, both native and copyback. The video does play correctly using Intel quickSync and Nvidia Quvid. So i can use of those two instead. Or just use CPU decoding instead.

I guess it will be very hard to reproduce on any other hardware.
The laptop is about 10 years old. And the latest videocard drive is from 2019.

[RanmaCanada]

Since it's SD content, as it's coming from a dvd, you would be better to use H264 honestly. HEVC isn't that great in regards to handling SD content, specially stuff that is interlaced, at least in my experience with my anime dvd's from the 80's. I just remux them now as I have a metric boatload of space.

[benwaggoner]

Since it's SD content, as it's coming from a dvd, you would be better to use H264 honestly. HEVC isn't that great in regards to handling SD content, specially stuff that is interlaced, at least in my experience with my anime dvd's from the 80's. I just remux them now as I have a metric boatload of space.
HEVC is generally fine for SD progressive content, and can deliver somewhat lower bitrates than H.264. It definitely isn't as good for interlaced, which was added pretty late in development and only supports field/frame. H.264 MBAFF is a lot more advanced and efficient, particularly for anime content.

[Slogra]

I'm deinterlacing to 50 full frames per seconds before encoding, so interlace support of the format plays no role.

AVC will be really quite big if no filters are used. And the avisynth filters i tried are either too slow or bad quality.

So i opted for HEVC... because it has fairly nice filtering built-in, encoding is fast and filesize is ok.
I'm using the original resolution (720x576), so the output quality is really quite near the original source (which is indeed an old dvd).

[benwaggoner]

I'm deinterlacing to 50 full frames per seconds before encoding, so interlace support of the format plays no role.

AVC will be really quite big if no filters are used. And the avisynth filters i tried are either too slow or bad quality.

So i opted for HEVC... because it has fairly nice filtering built-in, encoding is fast and filesize is ok.
I'm using the original resolution (720x576), so the output quality is really quite near the original source (which is indeed an old dvd).
Yeah, HEVC makes sense in that scenario. The biggest driver of quality is going to be in how good your deinterlacing filters are. I've not had to do anime deinterlacing much in the last few years, but it was always a challenge with old SD content.

[Slogra]

The source dvd is liveaction, not anime. So it is simply steady 25i.

I haven't even tried unfiltered AVC but it will be bigger than my biggest filtered test which was 325MB. So it will probably close to 400MB.
That is much bigger compared to 255MB of the unfiltered HEVC.

[benwaggoner]

The source dvd is liveaction, not anime. So it is simply steady 25i.

I haven't even tried unfiltered AVC but it will be bigger than my biggest filtered test which was 325MB. So it will probably close to 400MB.
That is much bigger compared to 255MB of the unfiltered HEVC.
If it is from DVD, a QP-aware deblocking decoder can be quite helpful.

[Slogra]

Can you explain how to do that?

btw i encoded the video to AVC without filter, and it is 332MB, which is not too bad. I really expected it to be much bigger compared to AVC with "KNLMeansCL adaptive" filter which is 325MB.

[benwaggoner]

Can you explain how to do that?

btw i encoded the video to AVC without filter, and it is 332MB, which is not too bad. I really expected it to be much bigger compared to AVC with "KNLMeansCL adaptive" filter which is 325MB.
What specifically are you trying to filter out.
The deblocking MPEG-2 encoder I use these says is Elemental's, but that's commercial. Back in the day MeGui has a decent enough one I used to good effect with blocky sources. There's a MPEG2 Deblocking checkbox on the filter pane of the AVISynth Script Creator. I imagine better things have emerged since then.

Wow, getting back to the original mission of Doom9 there!