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. |
26th June 2014, 02:41 | #1021 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
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. 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.) |
|
26th June 2014, 12:12 | #1024 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
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.
|
26th June 2014, 14:05 | #1025 | Link | |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
Quote:
|
|
26th June 2014, 14:27 | #1026 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
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.
|
26th June 2014, 15:28 | #1028 | Link |
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) |
26th June 2014, 16:09 | #1029 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
|
26th June 2014, 17:24 | #1030 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
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.
|
26th June 2014, 18:15 | #1031 | Link | |
Registered User
Join Date: Jan 2010
Posts: 709
|
Quote:
http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither
__________________
powered by Google Translator |
|
26th June 2014, 22:38 | #1033 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
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.
|
26th June 2014, 22:52 | #1034 | Link | |
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,484
|
Quote:
__________________
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. |
|
26th June 2014, 23:37 | #1035 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
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. |
|
28th June 2014, 16:06 | #1036 | Link |
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? |
28th June 2014, 16:22 | #1037 | Link |
Software Developer
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. |
28th June 2014, 18:02 | #1038 | Link | |
Registered User
Join Date: Apr 2009
Posts: 153
|
Quote:
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? |
|
28th June 2014, 18:19 | #1039 | Link |
Software Developer
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. |
28th June 2014, 21:22 | #1040 | Link |
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|