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 27th November 2013, 13:36   #201  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th November 2013, 21:37   #202  |  Link
xooyoozoo
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.
xooyoozoo is offline   Reply With Quote
Old 29th November 2013, 06:41   #203  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
Quote:
Originally Posted by xooyoozoo View Post
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.
What is the version of x265 used?
nakTT is offline   Reply With Quote
Old 29th November 2013, 08:12   #204  |  Link
x265_Project
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
  Reply With Quote
Old 29th November 2013, 10:13   #205  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
Quote:
Originally Posted by x265_Project View Post
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
How do I know which is a development tip and which is not? Thanks.
nakTT is offline   Reply With Quote
Old 29th November 2013, 10:30   #206  |  Link
Procrastinating
Registered User
 
Procrastinating's Avatar
 
Join Date: Aug 2013
Posts: 71
Quote:
Originally Posted by xooyoozoo View Post
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.
Granted the x264 video could probably have been better tuned, but that does look like quite a measurable improvement! I have some free time on my hands, so I might try comparing some anime credits or something.

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.
Procrastinating is offline   Reply With Quote
Old 29th November 2013, 16:53   #207  |  Link
x265.cc
Registered User
 
Join Date: Oct 2013
Posts: 41
Quote:
Originally Posted by nakTT View Post
What is the version of x265 used?
"x265 @2ba6c26" ~ x265_0.5+610-2ba6c26c9feb

Quote:
Originally Posted by nakTT View Post
How do I know which is a development tip and which is not? Thanks.
Look at the "stable" tag at https://bitbucket.org/multicoreware/x265/commits/all. As you can see the "stable" versions are normal "development" version which are meant to be stable.

Quote:
Originally Posted by Procrastinating View Post
Another question, is 16bpp functional? Ie, can I input and/or output 10-bit video?
AFAIK it can currently only output 16-bit hevc files (you probably should try it yourself), the current 16bpp version should work but is really incomplete and slow (in comparison to the 8bpp version).

Quote:
Originally Posted by x265_Project View Post
We are getting close to a stable 0.6 version.
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.
x265.cc is offline   Reply With Quote
Old 29th November 2013, 17:01   #208  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by xooyoozoo View Post
Holly Cow, what a difference.
I don't know what the PSNR or SSIM are, but it sure looks almost twice as good.

And its only the beginning.

Last edited by James Freeman; 29th November 2013 at 17:05.
James Freeman is offline   Reply With Quote
Old 29th November 2013, 17:23   #209  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
Quote:
Originally Posted by x265.cc View Post
AFAIK it can currently only output 16-bit hevc files (you probably should try it yourself), the current 16bpp version should work but is really incomplete and slow (in comparison to the 8bpp version).
The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit. The HEVC specification only specifies algorithms up to 14 bits, and the current HEVC profiles only support 8-10 bits. The encoding itself is 10 bits.

You are correct about it being very much slower than the 8bit version, of course
__________________
[I'm human, no debug]
JEEB is offline   Reply With Quote
Old 29th November 2013, 17:27   #210  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Quote:
Originally Posted by xooyoozoo View Post
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.
I would recommend next time when you will do x264 compression at such low bitrates that it is already blocking to disable PsyRD (--psy-rd 0). Because imho PsyRD is only visually useful when you have enough bitrate for it and at low bitrates it can harm quality. I doubt it will change this comparison significantly but should make x264 less blocky.
MasterNobody is offline   Reply With Quote
Old 29th November 2013, 20:27   #211  |  Link
x265.cc
Registered User
 
Join Date: Oct 2013
Posts: 41
Quote:
Originally Posted by JEEB View Post
The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit.
hehe, thanks for clarifying this


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.
x265.cc is offline   Reply With Quote
Old 29th November 2013, 20:54   #212  |  Link
x265_Project
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
  Reply With Quote
Old 29th November 2013, 21:16   #213  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Any GOOD reason why now the PDF is "secured" (i.e., Content Copying, Page Extraction and Commenting now are "not allowed")?
filler56789 is offline   Reply With Quote
Old 29th November 2013, 21:22   #214  |  Link
fumoffu
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
and all other presets are setting it back to 1 except slower, veryslow, placebo
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.
fumoffu is offline   Reply With Quote
Old 29th November 2013, 21:50   #215  |  Link
x265.cc
Registered User
 
Join Date: Oct 2013
Posts: 41
Quote:
Originally Posted by fumoffu View Post
what does cbf stands for again?
coded block flag

Quote:
Originally Posted by fumoffu View Post
--early-skip - what are we skipping?
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.
x265.cc is offline   Reply With Quote
Old 29th November 2013, 22:36   #216  |  Link
fumoffu
Registered User
 
Join Date: May 2013
Posts: 90
Thanks, l was wondering what is the difference between that and --tskip
Hopefully someday everything will be as nicely documented/explained as in X264 Settings - MeWiki
fumoffu is offline   Reply With Quote
Old 29th November 2013, 23:34   #217  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by fumoffu View Post
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
and all other presets are setting it back to 1 except slower, veryslow, placebo
if bpyramid 2 exists and does something to improve quality it's strange that default has it set to 2 but slow to 1
Good eye. It's my mistake (I wrote the patch to revise the defaults and preset values). I fixed this in the documentation but it needs to be fixed in the code. I've sent another patch to our development team to review and commit. Of course, since bpyramid is a logical value, any non-zero value is true, and so this bug is benign.

Tom
  Reply With Quote
Old 30th November 2013, 06:06   #218  |  Link
Procrastinating
Registered User
 
Procrastinating's Avatar
 
Join Date: Aug 2013
Posts: 71
Quote:
Originally Posted by JEEB View Post
The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit. The HEVC specification only specifies algorithms up to 14 bits, and the current HEVC profiles only support 8-10 bits. The encoding itself is 10 bits.

You are correct about it being very much slower than the 8bit version, of course
So 16bpp output is storing 10-bit data in 16-bit variables? I'm guessing there isn't any redundancy/that x264 also does something similar?
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)
Procrastinating is offline   Reply With Quote
Old 30th November 2013, 13:52   #219  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by Procrastinating View Post
So 16bpp output is storing 10-bit data in 16-bit variables? I'm guessing there isn't any redundancy/that x264 also does something similar?
The smallest addressable unit of memory (aka "Byte") is 8-Bit on pretty much any modern computer. So if you store a value in memory, you need to use at least one byte (8-Bit). Even booleans usually take one byte! But if the data is bigger than one byte, you will need to use two bytes (16-Bit) to store the value - even if the value is only 10, 12 or 14 bits in size. The "unused" bits will usually be padded with zero's. For values bigger than 16-Bit you'd use 24-Bit or even 32-Bit. And so on...

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.
LoRd_MuldeR is offline   Reply With Quote
Old 30th November 2013, 22:18   #220  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by LoRd_MuldeR View Post
The smallest addressable unit of memory (aka "Byte") is 8-Bit on pretty much any modern computer. So if you store a value in memory, you need to use at least one byte (8-Bit). Even booleans usually take one byte! But if the data is bigger than one byte, you will need to use two bytes (16-Bit) to store the value - even if the value is only 10, 12 or 14 bits in size. The "unused" bits will usually be padded with zero's. For values bigger than 16-Bit you'd use 24-Bit or even 32-Bit. And so on...

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.
This is a very good explanation. To this I would add that using the word "storing" (as procrastinating did in the original question) might be a bit misleading. Yes, we are storing these 10, 12 or 14 bit samples in 16 bit values, but only during the few milliseconds that we are processing those video samples in a CPU or GPU.

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
  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 20:50.


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