Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th January 2022, 19:09   #8421  |  Link
higher
Registered User
 
Join Date: Apr 2017
Location: Hungary
Posts: 6
Hello Gents!

I discovered that my x265 encodes (1080p, 2160p) lately are not gpu H/W accelerated in mpc-hc and are decoded on the cpu. My older encodes are playing with gpu H/W acceleration. Is there a flag that I have messed with or what could be the culprit? I'm using a gui called hybrid and mkvmerge.

Thanks!

Last edited by higher; 19th January 2022 at 19:15.
higher is offline   Reply With Quote
Old 19th January 2022, 19:32   #8422  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by higher View Post
Hello Gents!

I discovered that my x265 encodes (1080p, 2160p) lately are not gpu H/W accelerated in mpc-hc and are decoded on the cpu. My older encodes are playing with gpu H/W acceleration. Is there a flag that I have messed with or what could be the culprit? I'm using a gui called hybrid and mkvmerge.

Thanks!
without the full command line, it's hard to guess
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 19th January 2022, 20:30   #8423  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Or post a MediaInfo output of both cases so it's to see what the basic difference is.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 19th January 2022, 21:07   #8424  |  Link
higher
Registered User
 
Join Date: Apr 2017
Location: Hungary
Posts: 6
Thanks to both of you for the help. I was using the slow preset and some extra command line options. Upon comparing the encoding settings of a new and an older file via MediaInfo I saw no difference. I reset hybrid and now the encode is H/W accelerated in mpc-hc. Don't know what went wrong.
higher is offline   Reply With Quote
Old 20th January 2022, 18:36   #8425  |  Link
Kill3rWolf
Registered User
 
Join Date: Aug 2021
Posts: 27
Does gamma increase at a certain point bother you while watching a movie/tv-series? Can you identify with your open eyes without any tools while watching? Do you every time check you have achieved correct gamma after encoding a video with any tools/soft?

I'm talking'bout gamma increase due to encoding error, wrong parameters/values. How can I prevent this problem? I mean a specific settings/value/command line.

http://xahlee.info/img/what_is_gamma_correction.html

Last edited by Kill3rWolf; 20th January 2022 at 18:39.
Kill3rWolf is offline   Reply With Quote
Old 23rd January 2022, 17:10   #8426  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by Boulder View Post
This is because it cannot get the amount of frames from the piped stream.
It is possible but requires a patch to the y4m input handler code.

Code:
y4m  [info]: 2560x1064 fps 24000/1001 i420p10 frames 0 - 70330 of 70331
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain is offline   Reply With Quote
Old 24th January 2022, 03:05   #8427  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Kill3rWolf View Post
https://ibb.co/2NRL0P9

@Ben Waggoner, Should I use aq-mode=4 only for 4k HDR content? What about 1080p SDR content? aq-mode=4, Is it still unstable? Can be used for almost all content?

https://iopscience.iop.org/article/1.../1/012029/meta
Yeah, --aq-mode 4 can be used with all color spaces. The only one that is really color space specific is --aq-mode 3, which is --aq-mode 2 with a bias for lower QPs near black, to address SDR's insufficient code values in low luma.

The right aq mode can depend on content and other parameters, but I generally find --aq-mode 4 to be the best default these days. In particular, it generally handles high grain/noise better than the default of --aq-mode 2.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th January 2022, 03:10   #8428  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by excellentswordfight View Post
It sets what values the encoder excepts for the incomming signal, values above/below are clipped. I.e. if you set this incorrectly you will mess upp the luma values of your encode.

It's very unlikely that you need to specify this manually unless you have good reason for it.
And there is a downside to clamping with content that has excursions below nominal black, like analog sources.

Even if black averages out at Y'=64 or =16, noise can result in some pixels having values somewhat lower and others somewhat higher. Clamping to nominal black will leave around half the pixels at nominal black and the others somewhat higher. That results in black areas actually averaging brighter than nominal black, and can leave a "boiling oil" appearance. And the resulting sharp edges are harder to encode, increasing artifacts and/or wasting bits.

I don't know that I've ever set those values in a real encode. Setting a maximum value would be less fraught because SDR has slight code differences be much less visible near white.

If I had to set a minimum value for some reason, I'd want to set it at maybe 75% of nominal black to allow for some random noise without clamping. So maybe 48 for 10-bit and 12 for 8-bit? It would be both context and content dependent.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th January 2022, 03:12   #8429  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by higher View Post
Hello Gents!

I discovered that my x265 encodes (1080p, 2160p) lately are not gpu H/W accelerated in mpc-hc and are decoded on the cpu. My older encodes are playing with gpu H/W acceleration. Is there a flag that I have messed with or what could be the culprit? I'm using a gui called hybrid and mkvmerge.
Perhaps you're using 10-bit with 8-bit only capable hardware, or exceeding the hardware decoders' maximum Profile @ Level support?

First step is to compare before/after in MediaInfo. I'd guess Profile or Level are higher in the newer encodes.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th January 2022, 03:15   #8430  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Kill3rWolf View Post
Does gamma increase at a certain point bother you while watching a movie/tv-series? Can you identify with your open eyes without any tools while watching? Do you every time check you have achieved correct gamma after encoding a video with any tools/soft?

I'm talking'bout gamma increase due to encoding error, wrong parameters/values. How can I prevent this problem? I mean a specific settings/value/command line.
http://xahlee.info/img/what_is_gamma_correction.html
Accidentally changing gamma in encoding isn't that common. A lot more common source of different apparent brightness is a full/limited range mismatch. For example, encoding limited range 16-235 as full range 0-255. That'll yield a file where the darkest pixel is 16 points above actual black, and the brightest 20 below actual white. It also reduces saturation.

Lots of variants of that problem happen all too often, like when a device decodes 16-235 and assumes it is 0-255 RGB. Or when reencoding presuming the wrong source color space.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 30th January 2022, 22:01   #8431  |  Link
higher
Registered User
 
Join Date: Apr 2017
Location: Hungary
Posts: 6
I have been trying to encode the Taxi Driver UHD Blu-Ray. I have some issues and I think it has to do with the heavy grain. There are cyan patches during the intro sequence in the smoke and also throughout the movie. Please see the linked screenshot which is tonemapped to SDR by madVR. The original doesn't have it and frankly I have seen it before with some encodes. This particular encode is around 40Mbit/s and I used the slow preset. I was trying different aq-modes and strength, tune grain but all have this issue. Is there anything else I could experiment with?

Taxi Driver
higher is offline   Reply With Quote
Old 30th January 2022, 22:21   #8432  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
You could try lowering chroma QP offsets (--cbqpoffs, --crqpoffs. try around -2 to -4), but this is really a x265 weakness with heavy grain.
It has no problem retaining the luma noise but chroma noise is just a mess.
__________________
LG C2 OLED | GitHub Projects
quietvoid is offline   Reply With Quote
Old 31st January 2022, 00:09   #8433  |  Link
higher
Registered User
 
Join Date: Apr 2017
Location: Hungary
Posts: 6
Thank you for the suggestion. Unfortunately it made no difference. It's what it is then?
higher is offline   Reply With Quote
Old 31st January 2022, 05:59   #8434  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 328
Quote:
Originally Posted by higher View Post
Thank you for the suggestion. Unfortunately it made no difference. It's what it is then?
Sadly yes. I've stated it before and I'll state it again, x265 just can't handle grain as well as x264 can. It has gotten better, but it still can't handle it properly. Maybe AV1 or VVC will be able to match x264 in regards to grain handling once they become mature.
RanmaCanada is offline   Reply With Quote
Old 31st January 2022, 06:24   #8435  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by RanmaCanada View Post
Sadly yes. I've stated it before and I'll state it again, x265 just can't handle grain as well as x264 can. It has gotten better, but it still can't handle it properly. Maybe AV1 or VVC will be able to match x264 in regards to grain handling once they become mature.
As far as I've understood, they will happily suck all the details as well.

To the OP: did you use --hdr10-opt? It will do some internal changes in encoding.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 31st January 2022, 21:30   #8436  |  Link
higher
Registered User
 
Join Date: Apr 2017
Location: Hungary
Posts: 6
Of course I did. Upon further inspection it looks slightly better with --tune-grain but not so much.
What are they using for the disc encodes that outperforms x265 in these situations?

Last edited by higher; 31st January 2022 at 21:36.
higher is offline   Reply With Quote
Old 31st January 2022, 21:57   #8437  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by higher View Post
What are they using for the disc encodes that outperforms x265 in these situations?
Ateme or MainConcept or Beamr
__________________
ffx264 || ffhevc || ffxvid || microenc

Last edited by microchip8; 31st January 2022 at 22:00.
microchip8 is offline   Reply With Quote
Old 31st January 2022, 22:37   #8438  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Posts: 343
Quote:
Originally Posted by RanmaCanada View Post
Sadly yes. I've stated it before and I'll state it again, x265 just can't handle grain as well as x264 can. It has gotten better, but it still can't handle it properly. Maybe AV1 or VVC will be able to match x264 in regards to grain handling once they become mature.
You are mixing standards with standard implementations.
rwill is offline   Reply With Quote
Old 31st January 2022, 22:38   #8439  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Posts: 343
Quote:
Originally Posted by microchip8 View Post
Ateme or MainConcept or Beamr
Or In-House encoders which are actually tuned for such high rates.
rwill is offline   Reply With Quote
Old 1st February 2022, 13:29   #8440  |  Link
markiemarcus
Registered User
 
Join Date: May 2018
Posts: 49
Quote:
Originally Posted by higher View Post
Thank you for the suggestion. Unfortunately it made no difference. It's what it is then?
I've also seen this before. In my experience some AQ modes exacerbate the problem and are more prone to it than others. This actually came up on an animated source in a shot not dissimilar to this.

Edit: It's been a while, but IIRC AQ mode 4 worked well on flat gradients with lots of grain. Have you tried this mode or just 1-3?

Last edited by markiemarcus; 1st February 2022 at 13:49.
markiemarcus is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.