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 25th June 2019, 14:39   #6881  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,874
Quote:
Originally Posted by poisondeathray View Post
2) on a quick test, it seems to correctly detect and increase the bitrate in the fade area... But there seems to be a slight abrupt transition as it exits out of the fade, almost like "keyframe popping", when compared to without --fades . There is an I frame placed on the --fades encode, where it was a B on the without .

Just one observation, one test, so I'll take do some other tests before before making any preliminary conclusions...
What preset were you using? I'd expect that with weighted B and P prediction, a fade itself shouldn't require an increase in bitrate. And with Open GOP I'd hope the keyframe pop wouldn't be quite so harsh.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 25th June 2019, 15:23   #6882  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,813
Quote:
Originally Posted by benwaggoner View Post
What preset were you using? I'd expect that with weighted B and P prediction, a fade itself shouldn't require an increase in bitrate. And with Open GOP I'd hope the keyframe pop wouldn't be quite so harsh.

Slower , plus a few other changes . 10bit, CRF rate control

As you probably are aware, x264 and x265 have had issues with fades for a long time (probably why this option was introduced) . So I'm guessing the point of --fades was to increase the bitrate and fix the fade region (it's desired) . Without it - the banding and fade looks worse (as expected), With it, the fade looks better, bitrate increased - except for the popping

I haven't had a chance to examine in more detail or run more tests, but it's a pretty clear "pop" because of the quality change. The I frame is lower in quality. The test sequence was Lighthouses of the Pacific at the beginning . You only need to encode about 50 frames or so, it occurs 46-47 .
poisondeathray is offline   Reply With Quote
Old 25th June 2019, 15:59   #6883  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 856
Quote:
Originally Posted by poisondeathray View Post
As you probably are aware, x264 and x265 have had issues with fades for a long time (probably why this option was introduced) . So I'm guessing the point of --fades was to increase the bitrate and fix the fade region (it's desired) . Without it - the banding and fade looks worse (as expected), With it, the fade looks better, bitrate increased - except for the popping.
IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/

Last edited by filler56789; 25th June 2019 at 16:33. Reason: damn typos :-/
filler56789 is offline   Reply With Quote
Old 25th June 2019, 18:14   #6884  |  Link
SeeMoreDigital
Life looks better in UHD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 11,418
Quote:
Originally Posted by filler56789 View Post
IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/
I could have done with something like that a few years ago when I had to generate an encode that began with a black to full colour transition over the first 125 frames (5 seconds).

In order to get rid of the horrendous blocks at the beginning of the encode, I ended up having encode the first 125 frames separately (using I and P frames).
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Old 1st July 2019, 16:49   #6885  |  Link
TomV
VP Strategy, Beamr
 
Join Date: Jan 2018
Location: Palo Alto, CA
Posts: 49
Quote:
Originally Posted by filler56789 View Post
IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/
That is an extremely inefficient strategy for encoding dissolve transitions.
TomV is offline   Reply With Quote
Old 1st July 2019, 22:03   #6886  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,874
Quote:
Originally Posted by filler56789 View Post
IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/
Actually, the VC-1 encoder (and I believe the stock WMV9) would turn a transition into a sequence of P frames. It didn't have weighted prediction for B-frames so that was a lot more efficient.

Since HEVC has b-frame weighted prediction as well, that shouldn't be necessary. But rate control and motion estimation for a cross-dissolve is irreducibly tricky. Ideally the "before" and "after" frames would be defined and then forward/back proprogated via some mbtree extension.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd July 2019, 00:31   #6887  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 856
Quote:
Originally Posted by TomV View Post
That is an extremely inefficient strategy for encoding dissolve transitions.
I know that. But it seems you don't know that it WORKS
filler56789 is offline   Reply With Quote
Old 3rd July 2019, 01:22   #6888  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,874
Quote:
Originally Posted by filler56789 View Post
I know that. But it seems you don't know that it WORKS
Up to a point. Maybe. But a second long cross dissolve would need either a really big VBV or really high QP. And weighted prediction is EXACTLY for this kind of use case.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 5th July 2019, 14:30   #6889  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 322
x265 v3.1+4-4f6dde51a5db (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 9th July 2019, 11:36   #6890  |  Link
birdie
.
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 134
x265 3.1.1 is out.

https://bitbucket.org/multicoreware/...5_3.1.1.tar.gz
birdie is offline   Reply With Quote
Old 9th July 2019, 12:05   #6891  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 107
x265-3.1.1+1-04b37fd-win64-static-multilib

Code:
x265 [info]: HEVC encoder version 3.1.1+1-04b37fdfd2dc
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec  58.53.101)
x265 [info]: (libavformat 58.28.101)
x265 [info]: (libavutil   56.30.100)
x265 [info]: (lsmash       2.16.1)
  • Fix crash with aq-motion when aq-mode is disabled
__________________
Monochrome Anomaly
Wolfberry is offline   Reply With Quote
Old 10th July 2019, 02:34   #6892  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 528
Code:
From 9612a000cb26748e62833dcd9e47d890af0e3dec Mon Sep 17 00:00:00 2001
From: Xinyue Lu <i@7086.in>
Date: Tue, 9 Jul 2019 21:30:15 -0400
Subject: [PATCH] icc: fix compiling and linking issue under ICC

---
 source/common/x86/asm-primitives.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/common/x86/asm-primitives.cpp b/source/common/x86/asm-primitives.cpp
index 3948c4b97..abd3665f8 100644
--- a/source/common/x86/asm-primitives.cpp
+++ b/source/common/x86/asm-primitives.cpp
@@ -5429,7 +5429,7 @@ void setupAssemblyPrimitives(EncoderPrimitives &p, int cpuMask) // Main
 } // namespace X265_NS
 
 extern "C" {
-#ifdef __INTEL_COMPILER
+#if defined(__INTEL_COMPILER) && EXPORT_C_API
 
 /* Agner's patch to Intel's CPU dispatcher from pages 131-132 of
  * http://agner.org/optimize/optimizing_cpp.pdf (2011-01-30)
@@ -5440,7 +5440,7 @@ int __intel_cpu_indicator = 0;
 // CPU dispatcher function
 void PFX(intel_cpu_indicator_init)(void)
 {
-    uint32_t cpu = x265::cpu_detect(false);
+    uint32_t cpu = X265_NS::cpu_detect(false);
 
     if (cpu & X265_CPU_AVX)
         __intel_cpu_indicator = 0x20000;
@@ -5467,7 +5467,7 @@ void PFX(intel_cpu_indicator_init)(void)
  * that backs up all the registers. */
 void __intel_cpu_indicator_init(void)
 {
-    x265_safe_intel_cpu_indicator_init();
+    PFX(intel_cpu_indicator_init)();
 }
 
 #else // ifdef __INTEL_COMPILER
-- 
2.19.1.windows.1
Fixes #487 and #488. For those who'd like to use ICC. Anyone is free to submit this patch to the official with any amount of modification.
MeteorRain is offline   Reply With Quote
Old 10th July 2019, 07:25   #6893  |  Link
chenm001
Registered User
 
Join Date: Mar 2002
Posts: 16
Quote:
Originally Posted by MeteorRain View Post
Code:
From 9612a000cb26748e62833dcd9e47d890af0e3dec Mon Sep 17 00:00:00 2001
From: Xinyue Lu <i@7086.in>
Date: Tue, 9 Jul 2019 21:30:15 -0400
Subject: [PATCH] icc: fix compiling and linking issue under ICC
Fixes #487 and #488. For those who'd like to use ICC. Anyone is free to submit this patch to the official with any amount of modification.
Thank you point out this bug, I have been forward message to project manager.
chenm001 is offline   Reply With Quote
Old 11th July 2019, 13:51   #6894  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,079
What happened to x265 from 2.9 to 3.x? The bitrate dropped (and the QP increased) and the visual output quality has suffered at the same crf with the same command line. I read the release notes here: https://x265.readthedocs.io/en/defau...easenotes.html but they don't shed a ton of light. I know they made the old veryslow = new slower and effectively made a new preset between placebo and the old veryslow, but I've been using placebo so that doesn't explain it.

My typical 1080p command line switches for 8 bit 4:2:0 input.
Code:
--crf 16.0 -p placebo --no-sao --aq-strength 1.15 --vbv-maxrate 25000 --vbv-bufsize 25000 --level 5.0 --keyint 120 --open-gop -D 10 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1
Stereodude is online now   Reply With Quote
Old 11th July 2019, 15:05   #6895  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,843
Preset "placebo" as your "typical" 1080p parameter ... seriously?! I hope you use solar power to operate your PC.

The meaning of the placebo preset didn't change in the last years. So it must be a change in the general default behaviour.

I can hardly imagine anyone actually seeing an obvious loss of quality in a CRF 16 result played at normal speed. I hope you don't compare single frames with a magnifier to produce this claim. Are you able to provide clips to compare?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 11th July 2019, 15:15   #6896  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 107
The default AQ mode has been changed to auto-variance (aq-mode 2) in version 3.0.

Try setting --aq-mode 1 (the old default) in your command line.
__________________
Monochrome Anomaly
Wolfberry is offline   Reply With Quote
Old 11th July 2019, 15:26   #6897  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,079
Quote:
Originally Posted by LigH View Post
I can hardly imagine anyone actually seeing an obvious loss of quality in a CRF 16 result played at normal speed. I hope you don't compare single frames with a magnifier to produce this claim. Are you able to provide clips to compare?
It's quite easy to see in motion without magnification. Watch how fine grain dances and changes over time compared to the source (or doesn't dance and change like it should). With 2.9 the presets faster than placebo did not give satisfactory results even with significantly more bitrate.
Quote:
Originally Posted by Wolfberry View Post
The default AQ mode has been changed to auto-variance (aq-mode 2) in version 3.0.

Try setting --aq-mode 1 (the old default) in your command line.
Okay, thanks I will try this.
Stereodude is online now   Reply With Quote
Old 11th July 2019, 17:59   #6898  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 322
x265 v3.1+7-147fb92c5ed5 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 11th July 2019, 18:43   #6899  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,079
Why hasn't direct AVIsynth input been added to the windows builds of x265 like x264 has? I'm rather sick of having to pipe video into it.
Stereodude is online now   Reply With Quote
Old 11th July 2019, 20:23   #6900  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 147
Quote:
Originally Posted by Wolfberry View Post
Quote:
Originally Posted by Barough View Post
x265 v3.1+7-147fb92c5ed5 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)
which one is latest ?
Natty 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 06:05.


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