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, 12:19   #201  |  Link
fumoffu
Registered User
 
Join Date: May 2013
Posts: 90
Quote:
Originally Posted by fumoffu View Post
Is aq mode/strength supposed to work already?
It crashes the encoder for me after about 300 frames and what is encoded has artifacts.
Correction it does seem to work only with (crazy slow) --rd 2
Is this how it's supposed to be?
fumoffu is offline   Reply With Quote
Old 27th November 2013, 12:36   #202  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,875
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, 20:37   #203  |  Link
xooyoozoo
Registered User
 
Join Date: Dec 2012
Posts: 199
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, 05:41   #204  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 386
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, 07:12   #205  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
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
x265_Project is offline   Reply With Quote
Old 29th November 2013, 09:13   #206  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 386
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, 09:30   #207  |  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 11:29.
Procrastinating is offline   Reply With Quote
Old 29th November 2013, 15:53   #208  |  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 16:01.
x265.cc is offline   Reply With Quote
Old 29th November 2013, 16:01   #209  |  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 16:05.
James Freeman is offline   Reply With Quote
Old 29th November 2013, 16:23   #210  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 514
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, 16:27   #211  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 519
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, 19:27   #212  |  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, 19:54   #213  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
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
x265_Project is offline   Reply With Quote
Old 29th November 2013, 20:16   #214  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 883
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, 20:22   #215  |  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 22:00.
fumoffu is offline   Reply With Quote
Old 29th November 2013, 20:50   #216  |  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 20:56.
x265.cc is offline   Reply With Quote
Old 29th November 2013, 21:36   #217  |  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, 22:34   #218  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
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
x265_Project is offline   Reply With Quote
Old 30th November 2013, 05:06   #219  |  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, 12:52   #220  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,032
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.
__________________
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.



Last edited by LoRd_MuldeR; 30th November 2013 at 23:34.
LoRd_MuldeR 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:05.


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