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. |
27th November 2013, 13:36 | #201 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
No, development of "incomplete" RD modes and AQ in conjunction is progressing... I did not have crashes in earlier tests, but encoding artefacts; AQ use{s|d} to rely on complete RD analysis data.
|
28th November 2013, 21:37 | #202 | Link |
Registered User
Join Date: Dec 2012
Posts: 197
|
Tested a simple 16s clip cut from a documentary BluRay and x264 2377 and x265 @2ba6c26. Used placebo presets and matched x264's 2pass bitrate to x265's default CRF (28) with aq-mode 1. Bitstreams and side-by-side comparison.
I know that things are still incomplete, but at the very least, AQ seems to be doing its thing and there's no longer that fuzzy 'reference' look I remember from the HM. |
29th November 2013, 06:41 | #203 | Link | |
Registered User
Join Date: Dec 2008
Posts: 415
|
Quote:
|
|
29th November 2013, 08:12 | #204 | Link |
Guest
Posts: n/a
|
We are getting close to a stable 0.6 version. If you are running builds from the development tip you will notice that we just updated the performance preset settings, providing better results and a better distribution of values (along the speed vs. efficiency curve). We'll publish a new Evaluator's Guide with the new values shortly.
Tom |
29th November 2013, 10:13 | #205 | Link | |
Registered User
Join Date: Dec 2008
Posts: 415
|
Quote:
|
|
29th November 2013, 10:30 | #206 | Link | |
Registered User
Join Date: Aug 2013
Posts: 71
|
Quote:
Another question, is 16bpp functional? Ie, can I input and/or output 10-bit video? Last edited by Procrastinating; 29th November 2013 at 12:29. |
|
29th November 2013, 16:53 | #207 | Link | ||
Registered User
Join Date: Oct 2013
Posts: 41
|
"x265 @2ba6c26" ~ x265_0.5+610-2ba6c26c9feb
Quote:
Quote:
Can you tell me if there is any special usage case for the stable version?
__________________
encoder.pw buildbot is NOT affiliated with, endorsed, or sponsored by the x265 development team, MultiCoreWare Inc, Xiph.Org Foundation nor VideoLAN organization. Last edited by x265.cc; 29th November 2013 at 17:01. |
||
29th November 2013, 17:23 | #209 | Link | |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Quote:
You are correct about it being very much slower than the 8bit version, of course
__________________
[I'm human, no debug]
|
|
29th November 2013, 17:27 | #210 | Link | |
Registered User
Join Date: Jul 2007
Posts: 552
|
Quote:
|
|
29th November 2013, 20:27 | #211 | Link | |
Registered User
Join Date: Oct 2013
Posts: 41
|
Quote:
Probably i should had to check the "input-depth" parameter first
__________________
encoder.pw buildbot is NOT affiliated with, endorsed, or sponsored by the x265 development team, MultiCoreWare Inc, Xiph.Org Foundation nor VideoLAN organization. |
|
29th November 2013, 20:54 | #212 | Link |
Guest
Posts: n/a
|
We've updated x265's performance presets, providing better performance and compression efficiency (quality at any given bitrate) for most presets. We've also worked to provide a good range of values along the speed vs. efficiency curve.
I've posted a new x265 Evaluator's Guide. As always, constructive feedback is welcomed. Tom |
29th November 2013, 21:22 | #214 | Link |
Registered User
Join Date: May 2013
Posts: 90
|
I have been looking in the preset changes in the code before you posted updated guide and noticed possible mistake.
by default bpyramid is being set to 2 while the only documented values are 0 and 1 Code:
param->bpyramid = 2 if bpyramid 2 exists and does something to improve quality it's strange that default has it set to 2 but slow to 1 btw. default keyframeMin = 0 seems a bit low is there some other mechanism that prevents too frequent I frames in fast changing images? is there a switch to change this like --min-keyint ? Also if anyone knowledgeable is bored and could explain what some of those options do I would be very happy: --max-merge - what are we merging? I'm guessing partitions but I would love to know more how and when this works. --early-skip - what are we skipping? --fast-cbf - what does cbf stands for again? Last edited by fumoffu; 29th November 2013 at 23:00. |
29th November 2013, 21:50 | #215 | Link |
Registered User
Join Date: Oct 2013
Posts: 41
|
coded block flag
is Early skip detection for HEVC http://phenix.it-sudparis.eu/jct/doc_end_user/documents/7_Geneva/wg11/JCTVC-G543-v3.zip could be useful for you
__________________
encoder.pw buildbot is NOT affiliated with, endorsed, or sponsored by the x265 development team, MultiCoreWare Inc, Xiph.Org Foundation nor VideoLAN organization. Last edited by x265.cc; 29th November 2013 at 21:56. |
29th November 2013, 23:34 | #217 | Link | |
Guest
Posts: n/a
|
Quote:
Tom |
|
30th November 2013, 06:06 | #218 | Link | |
Registered User
Join Date: Aug 2013
Posts: 71
|
Quote:
Leading on from that, obviously it's much slower, but is it more space-efficient than 8bpp? Or rather, is there any reason to test/compare 16bpp/10-bit to 8bpp at this stage? I plan on comparing some anime credits, so I want to make sure I am making fair comparisons to default/fan-tuned encodes(8-bit vs 8-bit, or 10-bit vs 10-bit, or all vs all). Just looking through different ones at the moment to find problem-cases(difficult to compress but not because of noise) |
|
30th November 2013, 13:52 | #219 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
Surely, one could "pack", for example, 4 values à 10-Bit into 5 consecutive bytes, in order to eliminate that overhead. But then these values won't be addressable directly anymore. You would need to use some bit-operation magic to store/read your values, which usually is too complex and too slow. So, most of the time, you simply accept the overhead of storing a 10-Bit (12-Bit, 14-Bit) value in a 16-Bit variable.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 1st December 2013 at 00:34. |
|
30th November 2013, 22:18 | #220 | Link | |
Guest
Posts: n/a
|
Quote:
All modern video encoding standards use some form of lossless data compression (entropy encoding) which converts symbols into the final bitstream. HEVC uses context adaptive binary arithmetic coding (CABAC) to losslessly compress syntax elements to encoded bits. AVC uses CABAC or CAVLC. So, when the video is stored on a hard drive or other storage medium, we don't end up with all of those extra zeros padding the ends of our samples. But when we are encoding or decoding video, we need to process uncompressed video samples with standard CPUs or GPUs, and for this we need to move and perform operations on the uncompressed data in standard-sized units (data words). Computer processors can process data in 8 bit words, 16 bit words, 32 bit words, and for some 64 bits or larger. We can also process multiple words of data with a single instruction (this is called Single Instruction, Multiple Data, or SIMD), allowing us to pack eight 8-bit data words into a single 64 bit register, performing operations on all 8 of these data words with one instruction. When we are processing 10 bit video, we have to use 16 bit words to move and operate on these 10 bit values, and so we can only process half as many data words per clock cycle. This is why we see a big performance penalty the moment we start trying to process video that has more than 8 bits/sample. Once we switch over to using 16 bit words for every video sample, we will only move and operate on half as much data per clock cycle. So, again... when stored in a video file, thanks to entropy encoding (CABAC, CAVLC, etc.), 10 bit/sample video is not twice the size of 8 bit/sample video. But when we are encoding, decoding or performing any intermediate processing (scaling, color space conversion, frame rate conversion, etc.) on 10 bit/sample video, we will see a big drop in performance on standard off-the-shelf CPU and GPU hardware (versus 8 bit/sample video). Of course, if you are designing an Application Specific Integrated Circuit (a hardware encoder/decoder/video processor), you can design it to operate on data of any width necessary, and so you aren't faced with the same limitation. I hope this helps. Tom |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|