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 21st October 2018, 14:21   #6461  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,636
Quote:
Originally Posted by benwaggoner View Post
AFAIK it works by reducing signaling overhead without changing actual pixels.
There is a quite clear difference in the frame, it was quite obvious in this flat area (zoomed in though). The filesize difference was about 5% (the optimized version was smaller).

Without the optimization:


Optimization enabled:


In higher detailed area, the optimized encode looked better. I think I need to find a scene with some still background like sky, and see which one looks better in motion. The banding in flat areas can be quite eye-catching once you notice it.
__________________
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 21st October 2018, 19:54   #6462  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Quote:
Originally Posted by Boulder View Post
There is a quite clear difference in the frame, it was quite obvious in this flat area (zoomed in though). The filesize difference was about 5% (the optimized version was smaller).

In higher detailed area, the optimized encode looked better. I think I need to find a scene with some still background like sky, and see which one looks better in motion. The banding in flat areas can be quite eye-catching once you notice it.
Wow, awesome info! Thanks! I will iterate on further.

Was there any measurable perf difference?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 21st October 2018, 20:37   #6463  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,636
Quote:
Originally Posted by benwaggoner View Post
Wow, awesome info! Thanks! I will iterate on further.

Was there any measurable perf difference?
I just ran a longer encode to measure, and the difference is quite high. 4.95 fps for the normal encode and 5.22 fps for the one with optimization enabled. The normal encode is about 8% bigger.

I also checked how the optimization works in normal playback, and my eyes didn't like the result. The flat areas suffered a bit too much, there was a short scene with a nice, slightly noisy but flat coloured background which was lit by some flickering candlelight. The normal encode was slightly better looking there, there was not as much swimming blocks effect as there was with the optimized version.
__________________
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 21st October 2018, 21:35   #6464  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Quote:
Originally Posted by Boulder View Post
I just ran a longer encode to measure, and the difference is quite high. 4.95 fps for the normal encode and 5.22 fps for the one with optimization enabled. The normal encode is about 8% bigger.
An 8% file size reduction for a 5.5% speed increase would be an incredible optimization. An optimization can that give 1% reduction for a 5% speed increase is a big deal.

Quote:
I also checked how the optimization works in normal playback, and my eyes didn't like the result. The flat areas suffered a bit too much, there was a short scene with a nice, slightly noisy but flat coloured background which was lit by some flickering candlelight. The normal encode was slightly better looking there, there was not as much swimming blocks effect as there was with the optimized version.
...but only if that 8% reduction doesn't impact quality, alas.

It would be interesting to see what the difference was in a stream analyzer. Or just looking at the log-level 2 csv files.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd October 2018, 05:07   #6465  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,636
I ran the encodes again to produce the logs, if you want to have a look: https://drive.google.com/open?id=1Ej...nsPbY8qyl6tFMA . The flat part scene I mentioned appears several times, for example frames 0-117 contain that one.
__________________
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 27th October 2018, 13:30   #6466  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,636
This is probably a silly question, but here goes anyway: if I use --hdr-opt, do I need to feed the encoder with 10-bit data or is 16-bit data as good if the source is a standard UHD with HDR? I always process things in 16-bit domain and let the encoder dither down to 10 bits.
__________________
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 27th October 2018, 15:52   #6467  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 753
Is there a release note for v2.9?
iwod is offline   Reply With Quote
Old 27th October 2018, 23:01   #6468  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
I never saw any...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 27th October 2018, 23:44   #6469  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,050
Quote:
Originally Posted by iwod View Post
Is there a release note for v2.9?
https://bitbucket.org/multicoreware/...e-view-default
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 28th October 2018, 02:35   #6470  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Quote:
Originally Posted by Boulder View Post
This is probably a silly question, but here goes anyway: if I use --hdr-opt, do I need to feed the encoder with 10-bit data or is 16-bit data as good if the source is a standard UHD with HDR? I always process things in 16-bit domain and let the encoder dither down to 10 bits.
The actual x265 encoder instance is going to start encoding with 10-bit 4:2:0 pixels one way or another. It gets converted somewhere upstream, perhaps even in the x265 exe. But that’s a filter that runs before the actual codec itself.

If you’re changing bit depth in x265, remember to always use —dither.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th October 2018, 08:02   #6471  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 99
It is kind of weird that the v2.9 release notes is only available in the stable version, but not default or even latest.
__________________
Monochrome Anomaly
Wolfberry is offline   Reply With Quote
Old 28th October 2018, 09:25   #6472  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 51
It seems that even zeranoe ffmpeg stays at x265 2.8 for a long time.

By the way, I'm not a fan of hard-coded dithering. Dithering should be handled as part of creative editing before the encoding process or left to the rendering after the decoding process.
alex1399 is offline   Reply With Quote
Old 29th October 2018, 11:11   #6473  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 688
Quote:
Originally Posted by Boulder View Post
This is probably a silly question, but here goes anyway: if I use --hdr-opt, do I need to feed the encoder with 10-bit data or is 16-bit data as good if the source is a standard UHD with HDR? I always process things in 16-bit domain and let the encoder dither down to 10 bits.
I would let x265.exe do the dithering, 'cause other dithering options like the Floyd Steinberg error diffusion may have a nicer look, but they could increase the bitrate required by x265. The built in dithering filter in x265 is supposed to dither everything down to the target bit depth without introducing banding. Blocks and macro blocks dithered by x265 are more likely to be recognised during the motocompensation by x265 than the ones dithered using a third party dithering method, therefore compression should be better.

In a nutshell, let x265 do the dithering and always pipe to it the highest bit depth you have, unless you like a specific dithering method and you have enough bitrate.
__________________
Broadcast Encoder
Avisynth memes: 1 - 2 - 3
Videotek - Audacity XP
FranceBB is offline   Reply With Quote
Old 29th October 2018, 18:31   #6474  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Quote:
Originally Posted by FranceBB View Post
I would let x265.exe do the dithering, 'cause other dithering options like the Floyd Steinberg error diffusion may have a nicer look, but they could increase the bitrate required by x265. The built in dithering filter in x265 is supposed to dither everything down to the target bit depth without introducing banding. Blocks and macro blocks dithered by x265 are more likely to be recognised during the motocompensation by x265 than the ones dithered using a third party dithering method, therefore compression should be better.

In a nutshell, let x265 do the dithering and always pipe to it the highest bit depth you have, unless you like a specific dithering method and you have enough bitrate.
Note there are two dithering modes in x265. The basic one if you don’t specify anything, and the more advanced one if you use —dither.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 31st October 2018, 00:08   #6475  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Say, does anyone have any data showing potential benefits of using some of the "beyond placebo" settings?

For example
  1. --subme 6 or 7 instead of 5
  2. --me sea instead of star
  3. --bframes 16 instead of 8
  4. --ref 6+ instead of 5
  5. --tskip
  6. --cu-lossless

I've fond some value in very low bitrates or unusual content from all but the higher subme and me, which I've not tried.
--me sea in particular cuts speed enormously.

Tskip and cu-lossless can help with anime, small text, screen captures, and other stuff with sharp detailed edges.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 31st October 2018, 11:29   #6476  |  Link
RainyDog
Registered User
 
Join Date: May 2009
Posts: 174
Quote:
Originally Posted by benwaggoner View Post
Say, does anyone have any data showing potential benefits of using some of the "beyond placebo" settings?

For example
  1. --subme 6 or 7 instead of 5
  2. --me sea instead of star
  3. --bframes 16 instead of 8
  4. --ref 6+ instead of 5
  5. --tskip
  6. --cu-lossless

I've fond some value in very low bitrates or unusual content from all but the higher subme and me, which I've not tried.
--me sea in particular cuts speed enormously.

Tskip and cu-lossless can help with anime, small text, screen captures, and other stuff with sharp detailed edges.
Is --subme tied to RDO in the way that it is in x264?

In x264, --subme 6 upwards have increased levels of RDO. But seems that RDO is its own separate thing in x265 with RD levels 1-6 and rd-refine being a separate switch too.
RainyDog is offline   Reply With Quote
Old 31st October 2018, 17:08   #6477  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Quote:
Originally Posted by RainyDog View Post
Is --subme tied to RDO in the way that it is in x264?

In x264, --subme 6 upwards have increased levels of RDO. But seems that RDO is its own separate thing in x265 with RD levels 1-6 and rd-refine being a separate switch too.
Yeah, subme does have some impact on rate control, but --rd is where the action is at.

From x265.readthedocs.io

Quote:
Amount of subpel refinement to perform. The higher the number the more subpel iterations and steps are performed. Default 2

At –subme values larger than 2, chroma residual cost is included in all subpel refinement steps and chroma residual is included in all motion estimation decisions (selecting the best reference picture in each list, and chosing between merge, uni-directional motion and bi-directional motion). The ‘slow’ preset is the first preset to enable the use of chroma residual.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 31st October 2018, 20:39   #6478  |  Link
TomV
VP Strategy, Beamr
 
Join Date: Jan 2018
Location: Palo Alto, CA
Posts: 49
Quote:
Originally Posted by benwaggoner View Post
Say, does anyone have any data showing potential benefits of using some of the "beyond placebo" settings?

For example
  1. --subme 6 or 7 instead of 5
  2. --me sea instead of star
  3. --bframes 16 instead of 8
  4. --ref 6+ instead of 5
  5. --tskip
  6. --cu-lossless

I've fond some value in very low bitrates or unusual content from all but the higher subme and me, which I've not tried.
--me sea in particular cuts speed enormously.

Tskip and cu-lossless can help with anime, small text, screen captures, and other stuff with sharp detailed edges.
When I was tuning x265's presets, I tried all of these options that go beyond placebo, to see what should be included in placebo. You and anyone else are welcome to try them again, but I found it was easy to massively increase encode times, but impossible to get any meaningful improvement in efficiency.
TomV is offline   Reply With Quote
Old 31st October 2018, 23:28   #6479  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
What idiom would you give a configuration "beyond placebo"? Possibly "insane", like LAME MP3...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 1st November 2018, 02:02   #6480  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 735
Quote:
Originally Posted by LigH View Post
What idiom would you give a configuration "beyond placebo"? Possibly "insane", like LAME MP3...
ultra placebo. Or very placebo since that would match with very slow.
mandarinka 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 05:55.


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