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 2nd April 2018, 19:05   #5981  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x265 2.7+22-946f82dbf4e8

dynamic-refine tunings

Can anyone report advantages of this feature?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd April 2018, 22:51   #5982  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
I've been wondering what's the difference between your binaries, Barough's and LigH's?

Also, i read in the x265 online manual (x265.readthedocs.io) that AQ-Mode 3 is good for low bitrate 10bit encodes... But what is considered low bitrates for Full-HD and 4K?

I backup my bluray movie collection @ Full-HD between 4000 and 8000kbs (depends mostly on the amount of grain, some movies can go higher but those are the exception. Animations tend to go lower)...
Is that considered low bitrates?
K.i.N.G is offline   Reply With Quote
Old 2nd April 2018, 22:59   #5983  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by K.i.N.G View Post
I've been wondering what's the difference between your binaries, Barough's and LigH's?
No clue how exactly Barough builds them ... but probably negligible.

I use the media-autobuild_suite as MSYS2 base environment, but still run separate build scripts in MinGW32 and MinGW64. No additional optimizations, just semi-automatic preparation for building the archive to be uploaded.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd April 2018, 23:03   #5984  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
Quote:
Originally Posted by LigH View Post
No clue how exactly Barough builds them ... but probably negligible.

I use the media-autobuild_suite as MSYS2 base environment, but still run separate build scripts in MinGW32 and MinGW64. No additional optimizations, just semi-automatic preparation for building the archive to be uploaded.
Default MABS compiles here

Sent from my SM-G965F via Tapatalk
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else.
Barough is offline   Reply With Quote
Old 2nd April 2018, 23:22   #5985  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Ok, thank you both for the answers!

Although I know absolutetly nothing about compiling so that doesn't tell me much...
K.i.N.G is offline   Reply With Quote
Old 2nd April 2018, 23:26   #5986  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Means: We use the same tools to build them, and very similar ways to do that. You may not notice any differences (e.g. in speed) when comparing both while encoding the same material with the same parameters.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd April 2018, 23:40   #5987  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Allright, thank you
K.i.N.G is offline   Reply With Quote
Old 3rd April 2018, 10:48   #5988  |  Link
RieGo
Registered User
 
Join Date: Nov 2009
Posts: 59
Quote:
Originally Posted by LigH View Post
x265 2.7+22-946f82dbf4e8

dynamic-refine tunings

Can anyone report advantages of this feature?
was wondering the same.
i did some test encodes with default parameters and "--dynamic-refine --refine-intra 4" @1000kbit/s Two Pass
i couldn't really tell a difference...
how are you supposed to see a difference when changing one parameter? that's almost impossible in my eyes - without picking single frames, which doesn't make much sense anyways.
decoding at ultra low bitrate?

so in theory this setting should be an improvement, right?
RieGo is offline   Reply With Quote
Old 3rd April 2018, 14:59   #5989  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Well, I did not expect obvious differences for random material and convenient bitrates; someone with more insight might know academic cases where an improvement can be expected. My guess would be: questionable cost-benefit ratio.

But surprise me who can!
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 3rd April 2018, 17:05   #5990  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
Join Date: Aug 2007
Posts: 79
had some thoughts about the aq-motion option I wanted to share. on the previous pages I referred to a scene where this option creates serious and very noticeable artifacts. here is the source clip and encodings to compare. focus on the two guys walking back to the truck after the first scene cut:
https://mega.nz/#F!DMYT2ICb!4aufAuilmDJAn-Bj-Gzcpg

commandline that was used with --aq-motion / --no-aq-motion resp.:

Code:
--preset slow --crf 23 --profile main10 --no-sao
this is the description of the feature from the x265 documentation

Quote:
--aq-motion, --no-aq-motion
Adjust the AQ offsets based on the relative motion of each block with respect to the motion of the frame. The more the relative motion of the block, the more quantization is used. Default disabled. Experimental Feature
this is apparently also applied when the frame doesn't move at all. so even when the scene is still, moving parts will use more quantization. I'd assume the original intention of this option is to only use more quantization in moving scenes where the block in question doesn't follow the global motion direction.

with a faster moving scene more quantization should be less noticeable on blocks with alternate direction. so to make this option more viable I'd suggest to scale the option with the speed of the global motion. with this still scenes shouldn't be affected at all and slow scenes less which avoids ugly results like demonstrated with the sample.

Last edited by Sp00kyFox; 3rd April 2018 at 23:48.
Sp00kyFox is offline   Reply With Quote
Old 4th April 2018, 04:55   #5991  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by Sp00kyFox View Post
this is apparently also applied when the frame doesn't move at all. so even when the scene is still, moving parts will use more quantization. I'd assume the original intention of this option is to only use more quantization in moving scenes where the block in question doesn't follow the global motion direction.

with a faster moving scene more quantization should be less noticeable on blocks with alternate direction. so to make this option more viable I'd suggest to scale the option with the speed of the global motion. with this still scenes shouldn't be affected at all and slow scenes less which avoids ugly results like demonstrated with the sample.
By the time the encoder would have even a rough idea of the global motion of the frame, more than half the blocks would already be quantized and done. x265 doesn't do any global motion estimation in the lookahead phase, it just decides if a scenecut is warranted, and everything else happens in a huge combined phase that outputs blocks as it gobbles them up.

Maybe a check for the inverse of emergency VBV could be enabled: Once the frame is over, go back and say "hey, that frame was pretty easy after all and didn't need to be so overcompressed." Or since global motion is known by the end, look back and see the oops before flushing the frame. Performance would take a pretty big hit every time it happened, especially if it affects future frames that are already mid-encode, but you need quality modes too. --aq-motion has promise in increasing overall quality, managing it just seems difficult.
foxyshadis is offline   Reply With Quote
Old 4th April 2018, 14:21   #5992  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
Join Date: Aug 2007
Posts: 79
thanks foxyshadis for your explanations, I'm not that familiar with the inner workings of the encoder. well, there goes my idea. maybe there are some other approaches to improve aq-motion. I think it definitely has potential and behaves well in many cases.
Sp00kyFox is offline   Reply With Quote
Old 4th April 2018, 15:01   #5993  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x265 v2.7+25 introduces the CLI option single-sei (to write all SEI messages in one single NAL, which may cause compatibility issues with reference decoders); but its documentation is missing in the full help, so I'll wait for the next patch.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 4th April 2018, 18:27   #5994  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by foxyshadis View Post
By the time the encoder would have even a rough idea of the global motion of the frame, more than half the blocks would already be quantized and done. x265 doesn't do any global motion estimation in the lookahead phase, it just decides if a scenecut is warranted, and everything else happens in a huge combined phase that outputs blocks as it gobbles them up.

Maybe a check for the inverse of emergency VBV could be enabled: Once the frame is over, go back and say "hey, that frame was pretty easy after all and didn't need to be so overcompressed." Or since global motion is known by the end, look back and see the oops before flushing the frame. Performance would take a pretty big hit every time it happened, especially if it affects future frames that are already mid-encode, but you need quality modes too. --aq-motion has promise in increasing overall quality, managing it just seems difficult.
Good analysis. That said, doing a coarse estimate of global motion in a downrezzed frame during lookahead is a perfectly reasonable strategy. Also the 1st pass global motion is known in later passes, so the above could work with 2-pass or even refine analysis. Global motion should be pretty consistent across frame sizes, so data from a lower Rez can be reused it doing an adaptation set.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 6th April 2018, 15:23   #5995  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753


307 patches with AVX-512 (and other improved assembly) code uploaded to the developer mailing list. That will take a little while to review.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 6th April 2018, 19:34   #5996  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by LigH View Post


307 patches with AVX-512 (and other improved assembly) code uploaded to the developer mailing list. That will take a little while to review.
Sounds like a good candidate for x265-3.0 to me.
pingfr is offline   Reply With Quote
Old 9th April 2018, 10:11   #5997  |  Link
Kavitha
Registered User
 
Join Date: Aug 2016
Posts: 4
Quote:
Originally Posted by LigH View Post
x265 2.7+22-946f82dbf4e8

dynamic-refine tunings

Can anyone report advantages of this feature?


x265 has static levels of refinement(--refine inter <level>/refine intra <level>) which can be used with --analysis-reuse-level 10.
Efficiency in terms of quality increases as the levels of refinement increases. This quality increase results from additional computation thereby increasing the overall encoding time.
For a better quality-speed trade-off, dynamic refinement was introduced where the encoder dynamically switches between different inter refine levels.
This basically exploits the fact that not all CUs are required to be encoded with same level for better performance/quality.
Considering the complexity of video content and the analysis information from first pass, the encoder can intelligently decide the optimal level of refinement for each CU.
Intra frames are usually encoded with best quality as they are used as references by the consecutive frames. Hence error introduced in intra frames due to reusing analysis data can propagate to frames that use these intra frames as reference.
To minimize the chances of error propagation, refine-intra 4 (level with best quality) restricts reusing analysis data for intra frames and forces the encoder to perform full intra analysis in the second pass.
This is why x265 documentation suggests to use dynamic refinement along with refine-intra 4 and this setting is expected to give improved quality than other refine intra levels for some videos.
Kavitha is offline   Reply With Quote
Old 10th April 2018, 07:56   #5998  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
@Kavitha; so I believe quality enthusiasts who are willing to spend a sensible amount of time will probably use this as default...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 10th April 2018, 11:19   #5999  |  Link
RieGo
Registered User
 
Join Date: Nov 2009
Posts: 59
yeah, i think i will use this as default, combined with slow preset.
afaik there are some settings that haven't really been adopted to presets. are there any plans to revise presets?
btw. can't wait for that avx 512 - ready to overheat my cpu
RieGo is offline   Reply With Quote
Old 10th April 2018, 13:17   #6000  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by RieGo View Post
afaik there are some settings that haven't really been adopted to presets. are there any plans to revise presets?
I'm no developer, but ... probably; presets have been revised in x264 several times as well. And in addition, there are also tunings to be revised and added. But first: Satisfy needs of paying customers. Second: e.g. complete spec coverage as much as sensible; etc. etc. The developers will surely face no boredom.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 19:58.


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