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 26th June 2014, 02:41   #1021  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by Motenai Yoda View Post
if mantissa is 10bit (16bit float) or less then I think will be same/worst than 10bit integer, coz above 511 up to 1023 exponent should be 0, maybe it will help a bit for low levels.
Ew, no. Half-precision was a great hack for its time, but there's plenty of bandwidth to go around now, even for 2160p60. 32-bit is fine (which is what madVR uses).

As impressive as that data flood would be, at 6.4GB/s, that's still only about half of a PCIe 2 x16 link, and PCIe 3 doubles your bandwidth again.

Quote:
Originally Posted by Motenai Yoda View Post
according to my tests Main10 give slightly better results than Main with 8-bit sources.

just a question, with --input-depth 16 how it will be reduced to 10bit? truncated? rounded? dithered?
Sierra-2-4A error diffusion, according to the comment on ditherPlane in filters.cpp. (Comments in x265.h say downshifted, but that isn't true anymore.)
foxyshadis is offline   Reply With Quote
Old 26th June 2014, 04:53   #1022  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
That requires the --dither switch, though?
sneaker_ger is offline   Reply With Quote
Old 26th June 2014, 09:09   #1023  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Yeah, I'm an idiot, I missed that. If you don't use --dither, it just bit-shifts to the internal, which always truncates down (or zero-extends 8-bit).
foxyshadis is offline   Reply With Quote
Old 26th June 2014, 12:12   #1024  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
v1.1+202-e2ed009d296a introduces Psy-RDO for RD levels 2..4; but without an official "all-clear", don't expect it to be completely "fixed" yet.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th June 2014, 14:05   #1025  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Quote:
Note when testing H.265 playback, you should most definitely use 64-bit versions of the player and decoder, as they are up to 50-100% faster, especially on 4K content (at least for anything FFmpeg based, like LAV/MPC-HC/etc.)
sadly most folks here are stuck with 32bit since there's no 64bit version of MadVR
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 26th June 2014, 14:27   #1026  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Isn't madVR a slowdown anyway, due to a rather complex chroma upsampling? Or can it be faster than a "plain" renderer like Hardware Overlay or EVR? It will probably depend on the GPU and its shader speed. I don't expect a passive cooled version (max. 128 bit bus) to be suitable.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th June 2014, 15:01   #1027  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by Selur View Post
sadly most folks here are stuck with 32bit since there's no 64bit version of MadVR
Sad but true.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.
James Freeman is offline   Reply With Quote
Old 26th June 2014, 15:28   #1028  |  Link
xkinn123
Registered User
 
Join Date: Mar 2014
Posts: 27
Has anyone test some samples using chrome offset (for example, --cbqpoffs 2 --crqpoffs 2) with color sample i422?
i can't play it on my mpv, mplayer, ffplay, or even MPC and VLC... (both linux and windows with the latest update)
xkinn123 is offline   Reply With Quote
Old 26th June 2014, 16:09   #1029  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by LigH View Post
Isn't madVR a slowdown anyway, due to a rather complex chroma upsampling? Or can it be faster than a "plain" renderer like Hardware Overlay or EVR? It will probably depend on the GPU and its shader speed. I don't expect a passive cooled version (max. 128 bit bus) to be suitable.
In my experience using plain EVR was faster than madVR for 4K, but YMMV.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 26th June 2014, 17:24   #1030  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by nevcairiel View Post
In my experience using plain EVR was faster than madVR for 4K, but YMMV.
But MadVR is still the easiest way to do Rec. 2020 output. I think the new 2014 Adobe CC apps may be able to do this as well by applying A color profile to the HDMI output, which I hope to play with this weekend.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 26th June 2014, 18:15   #1031  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
Quote:
Originally Posted by foxyshadis View Post
Yeah, I'm an idiot, I missed that. If you don't use --dither, it just bit-shifts to the internal, which always truncates down (or zero-extends 8-bit).
ok but as docs says --dither works for 8bit only, not 10bit

http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 26th June 2014, 19:58   #1032  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,484
Quote:
Originally Posted by Motenai Yoda View Post
ok but as docs says --dither works for 8bit only, not 10bit

http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither
Well simply because dithering is really usefull for 8 bits or less.
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9
Sagittaire is offline   Reply With Quote
Old 26th June 2014, 22:38   #1033  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by Motenai Yoda View Post
ok but as docs says --dither works for 8bit only, not 10bit

http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither
Huh, docs are wrong. With --dither enabled, the code unconditionally dithers any higher depth to the internal depth, no matter what the build is. It upconverts all input to 16bit, then the main dither function is designed to go from 16bit to any lower depth. Must have changed since the docs were written.
foxyshadis is offline   Reply With Quote
Old 26th June 2014, 22:52   #1034  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,484
Quote:
Originally Posted by foxyshadis View Post
Huh, docs are wrong. With --dither enabled, the code unconditionally dithers any higher depth to the internal depth, no matter what the build is. It upconverts all input to 16bit, then the main dither function is designed to go from 16bit to any lower depth. Must have changed since the docs were written.
make upconvert to 16 bits with lower depth input is not Dithering but just complete aleatoire noise. Moreover make Dithering for 16 bits input is really, really, really useless.
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9

Last edited by Sagittaire; 26th June 2014 at 22:54.
Sagittaire is offline   Reply With Quote
Old 26th June 2014, 23:37   #1035  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by Sagittaire View Post
make upconvert to 16 bits with lower depth input is not Dithering but just complete aleatoire noise. Moreover make Dithering for 16 bits input is really, really, really useless.
I mean, the process is:

If --dither and input_depth > internal_depth --> pad input to 16-bit (unless it already is) --> dither down to internal_depth (8 or 10) --> pass to main encoder. Changing all input to 16-bit just makes the dither algorithm simpler. However, this is a function of x265cli, not libx265.

If it's not dithered, then the libx265 core will just immediately truncate or pad to internal_depth, and only ever holds 8- or 10-bit packed planes to save memory (though some functions temporarily expand blocks to 16-bit for convenience). It has no notion of dithering.

Last edited by foxyshadis; 26th June 2014 at 23:41.
foxyshadis is offline   Reply With Quote
Old 28th June 2014, 16:06   #1036  |  Link
phate89
Registered User
 
Join Date: Apr 2009
Posts: 153
I have a question (i'm not an expert but i want to understand better the reasons). If i understood well google with vp9 while working on 10/12 bit wants to switch everything to 16 bit internally and other decoders already do this. Why x265 keeps 2 separate files and the 8 bit one is only 8 bit?
I understand that the advantage of higher internal precision is very small but it will slow down a lot more or the speed is the same? Will x265 join the 2 branches in the future?
phate89 is offline   Reply With Quote
Old 28th June 2014, 16:22   #1037  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
You are mixing up standards and implementations here!

HEVC is a video compression standard. And indeed, the HEVC standard does specify Profiles for 8-Bit, 10-Bit, 12-Bit or even 16-Bit internal precision!

Now, x265 is an HEVC encoder. So it implements HEVC in software. This means they can only support what is defined by the standard. And, as far as I know, they support at least 8-Bit and 10-Bit. Not sure if they support 12-Bit and 16-Bit yet.

Furthermore, "High Bit-Depth" support in x265 is a compile-time option - just like in x264. So it's a decision you need to make at compile-time and that you can not change at runtime!

But that doesn't mean that x265 has two separate branches. In does not! It's actually the exactly same code that you can build either with "High Bit-Depth" enabled or not. That's why you get two separate x265 binaries. But that's all about it.

The reason is that computers usually address memory in units of 2^N bits. So for the 8-Bit build, you can get away with 8-Bit (one byte) per pixel/component. But for 10-Bit or more, you will need to use 16-Bit per pixel/component.

Changing the data types in your code between 8-Bit and 16-Bit is something you can hardly do at runtime, so that's why it's a compile-time option...

(I think in theory it would be possible to support 8-Bit encoding in a "High Bit-Depth" binary. You would just leave the upper eight bits unused. But that would probably be unnecessary slow, compared to a regular 8-Bit build!)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 28th June 2014 at 16:39.
LoRd_MuldeR is offline   Reply With Quote
Old 28th June 2014, 18:02   #1038  |  Link
phate89
Registered User
 
Join Date: Apr 2009
Posts: 153
Quote:
Originally Posted by LoRd_MuldeR View Post

(I think in theory it would be possible to support 8-Bit encoding in a "High Bit-Depth" binary. You would just leave the upper eight bits unused. But that would probably be unnecessary slow, compared to a regular 8-Bit build!)
Maybe i'm not explained myself well but this is what i was talking about. I know that they're not the same. But an "high bit depth" build can do a 8 bit output and it should actually even improve (a little bit) the quality.
It's actually the first thing google will do to bring high bit depth to vp9 (https://www.youtube.com/watch?v=xo_R40C7RTo min 4:50).
But how much slower is an high bit depth encoding with output 8 bit than a regular encoding?
phate89 is offline   Reply With Quote
Old 28th June 2014, 18:19   #1039  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
The "High Bit-Depth" build option is basically about how much memory you allocate per pixel/component. With a "High Bit-Depth" build it's 16-Bit (as required for, e.g., 10-Bit/12-Bit encoding), otherwise it's just 8-Bit.

As said before, in theory, you could do 8-Bit encoding while internally keeping 16-Bit per pixel/component.

But all values would have to be truncated to 8-Bit anyway, i.e. the upper 8-Bit remain unused. This means that the output would be exactly the same as with a "true" 8-Bit build. Only that encoding would probably be running significantly slower...

BTW: You cannot do the "intermediate" calculations at 16-Bit precision and only round/truncate the final result to 8-Bit in order to get a valid 8-Bit stream. You need to enforce the same precision all the way trough! Otherwise encoder and decoder will de-synchronize. For example, since P- and B-Frames store the difference to the reference frames, the encoder must reconstruct those references frames exactly as a decoder would.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 28th June 2014 at 23:30.
LoRd_MuldeR is offline   Reply With Quote
Old 28th June 2014, 21:22   #1040  |  Link
xooyoozoo
Registered User
 
Join Date: Dec 2012
Posts: 197
The VP9 high bit depth part was a brief tidbit in a high-gloss promotional. I'm not sure if I'd use it to determine what is and isn't possible for a software encoder (edit: without deviating from previous codec/decoder standard).

Last edited by xooyoozoo; 28th June 2014 at 21:26.
xooyoozoo 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 17:08.


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