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 12th February 2020, 12:59   #7401  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,003
Well, it suddenly worked once (when I let it clone x264 before x265). Maybe just something on my PC was out of sync.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th February 2020, 09:11   #7402  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 991
x265.exe 3.3_RC1+2-e386d3a8a713

(64-bits, multilib, GCC 9.2, Win32-threads)

Code:
regression: fix analysis-save/load commands
http://www.mediafire.com/file/qnc7l7...8a713.rar/file
filler56789 is offline   Reply With Quote
Old 15th February 2020, 13:16   #7403  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 393
Quote:
Originally Posted by filler56789 View Post
x265.exe 3.3_RC1+2-e386d3a8a713

(64-bits, multilib, GCC 9.2, Win32-threads)

Code:
regression: fix analysis-save/load commands
http://www.mediafire.com/file/qnc7l7...8a713.rar/file
Any interesting changes from version 3.2?
nakTT is offline   Reply With Quote
Old 16th February 2020, 05:58   #7404  |  Link
Greenhorn
Registered User
 
Join Date: Apr 2018
Posts: 10
Quote:
Originally Posted by nakTT View Post
Any interesting changes from version 3.2?
Against the last 3.2x nightly builds, or against 3.2 release?

Against the former, just what's mentioned. Against the latter: --hist-scenecut to enable a different method of selecting scenecuts, --scenecut-aware-qp to apply an offset to the qp of keyframes and the frames immediately after them, and a more or less total overhaul of how the analysis-save/load feature works. Probably more that I'm not remembering.
Greenhorn is offline   Reply With Quote
Old 17th February 2020, 04:37   #7405  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 393
Quote:
Originally Posted by Greenhorn View Post
Against the last 3.2x nightly builds, or against 3.2 release?

Against the former, just what's mentioned. Against the latter: --hist-scenecut to enable a different method of selecting scenecuts, --scenecut-aware-qp to apply an offset to the qp of keyframes and the frames immediately after them, and a more or less total overhaul of how the analysis-save/load feature works. Probably more that I'm not remembering.
Thanks for the reply. My question was against 3.2 release, sorry for not being specific. BTW, was there any changes related to improved compression? Thank you in advance.

Last edited by nakTT; 17th February 2020 at 04:52.
nakTT is offline   Reply With Quote
Old 17th February 2020, 22:19   #7406  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,071
Quote:
Originally Posted by nakTT View Post
Thanks for the reply. My question was against 3.2 release, sorry for not being specific. BTW, was there any changes related to improved compression? Thank you in advance.
Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.

Sent from my SM-T837V using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 18th February 2020, 15:55   #7407  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 991
x265.exe 3.3+3-c2769ac5fa9d

Release notes: https://bitbucket.org/multicoreware/...leasenotes.rst

download: http://www.mediafire.com/file/op10k0...c5fa9d.7z/file
filler56789 is offline   Reply With Quote
Old 18th February 2020, 16:09   #7408  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 393
Quote:
Originally Posted by benwaggoner View Post
Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.

Sent from my SM-T837V using Tapatalk
Thanks for the reply. Glad to know they are still improving the compression efficiency even after years of develoment.

Quote:
Originally Posted by filler56789 View Post
Thanks, will give it a try.
nakTT is offline   Reply With Quote
Old 18th February 2020, 16:51   #7409  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,669
Quote:
Originally Posted by benwaggoner View Post
Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.
Have you made any tests concerning the new functionalities? They once again appeared without any use cases etc.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 18th February 2020, 17:22   #7410  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 697
https://www.mediafire.com/file/uth0n...32737d.7z/file

Code:
x265 [info]: HEVC encoder version 3.3+1-f94b0d32737d
x265 [info]: build info [Windows][Clang 9.0.0][64 bit] 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.38.101)
x265 [info]: (libavcodec  58.70.100)
x265 [info]: (libavutil   56.41.100)
HolyWu is offline   Reply With Quote
Old 18th February 2020, 18:13   #7411  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,071
Quote:
Originally Posted by Boulder View Post
Have you made any tests concerning the new functionalities? They once again appeared without any use cases etc.
Not myself yet. I'm currently at the HPA tech retreat. I should have some physical and CPU time to run some tests next week.

I didn't mention the Adaptive frame duplication feature. This promises some significant efficiency savings and also faster random access for content where there are identical frames. Credits, screen activity, and anime/cel animation seem particularly likely to get improvements.

I wish there was an optional flag that can allow --keyint to limit total encoded frames, so --keyint 240 would mean 240 unique coded frames. Thus, with 24 fps where the animation is at 8 fps (so three duplicate frames in a row), --keyint 240 would yield a GOP covering 30 seconds instead of 10. Not great for adaptive streaming, but could save space for a file without impacting random access.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 18th February 2020, 18:15   #7412  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,071
Quote:
Originally Posted by nakTT View Post
Thanks for the reply. Glad to know they are still improving the compression efficiency even after years of develoment.
Encoders are never done; we're still seeing improvements to MPEG-2 encoding after all these years. Particularly as long as Moore's Law keeps happening, we'll always find ways to take advantage of more MIPS/pixel.

With a codec as complex as HEVC, I would expect we'll be seeing material year-on-year encoder improvements for at least another five years.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 18th February 2020, 19:59   #7413  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,669
Quote:
Originally Posted by benwaggoner View Post
Not myself yet. I'm currently at the HPA tech retreat. I should have some physical and CPU time to run some tests next week.
I just did a very quick test myself, encoded my Hot Fuzz testclip with --hist-scenecut and it looks like the default settings are way off. 1220 frames of which 251 were I-frames .. The normal encode would have 12 I-frames (max keyint 480), which looks about the correct amount of true scene changes there.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 18th February 2020, 21:17   #7414  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,003
How do I retrieve version 3.3+3 via git? I only get version 3.3+1 via git pull origin master (in MSYS2) and the TortoiseGit Revision Graph (in Windows) tells me this is the HEAD.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 18th February 2020, 23:14   #7415  |  Link
Greenhorn
Registered User
 
Join Date: Apr 2018
Posts: 10
Quote:
Originally Posted by LigH View Post
How do I retrieve version 3.3+3 via git? I only get version 3.3+1 via git pull origin master (in MSYS2) and the TortoiseGit Revision Graph (in Windows) tells me this is the HEAD.
All 3 branches appear to be at version 3.3+1 with different commit numbers; the two patches after 3.3+1 consisted solely of merging the Master branch with the Stable and Release_3.3 branches.

(IDK anything about any VCS, so I have no idea if this is as expected or not-- but my point being, the latest files at the moment will be tagged 3.3+1.)
Greenhorn is offline   Reply With Quote
Old 19th February 2020, 02:15   #7416  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,071
Quote:
Originally Posted by Boulder View Post
I just did a very quick test myself, encoded my Hot Fuzz testclip with --hist-scenecut and it looks like the default settings are way off. 1220 frames of which 251 were I-frames .. The normal encode would have 12 I-frames (max keyint 480), which looks about the correct amount of true scene changes there.
Have you looked at where the cuts are relative to the IDR frames? Is it sticking IDRs in the middle of shots?

Sent from my SM-T837V using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th February 2020, 08:08   #7417  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,003
Let's assume those are the tiny differences between Git and Mercurial, regarding the counting of version numbers and patch increments. Hard to compare "the same build" then ...
_

PS:

In previous versions I was used to reading only CMake output on the console while x265 is built. Now, suddenly, make clutters the output by reporting verbosely that it is e.g. entering and leaving directories. May that be a new default behaviour of make, of the shell, or of the media-autobuild suite having set an environment variable in a way that it changes the output also in interactive shell mode?


x265 3.3+1-g396395b2b
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 19th February 2020 at 10:55.
LigH is offline   Reply With Quote
Old 19th February 2020, 13:29   #7418  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 991
LigH's latest build of x265.exe says:

version = 3.3+1-g396395b2b

whereas the latest build of x265.exe by http://msystem.waw.pl/x265/ says:

version = 3.3+1-g554c887ac

But according to the page https://bitbucket.org/multicoreware/x265/commits/ ,
those commit numbers don't exist.





filler56789 is offline   Reply With Quote
Old 19th February 2020, 14:24   #7419  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,003
You are looking in the Mercurial repository, while I got the sources via Git instead (the hash has a g prefix). Try: https://bitbucket.org/multicoreware/x265_git/commits/ (note the x265_git)

Apparently, merges don't increase the patch count for Git; they did in Mercurial, though.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 19th February 2020 at 14:29.
LigH is offline   Reply With Quote
Old 19th February 2020, 14:58   #7420  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 991
Yeah, git is a total mess.

Mercurial apparently is less messy.

x264, for example, doesn't add the prefix "g" to the commit number.

Code:
x264 0.159.2991 1771b55
filler56789 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:18.


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