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 18th February 2020, 19:59   #7401  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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   #7402  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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   #7403  |  Link
Greenhorn
Registered User
 
Join Date: Apr 2018
Posts: 61
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   #7404  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
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   #7405  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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   #7406  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
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   #7407  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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   #7408  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
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
Old 19th February 2020, 16:26   #7409  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by HolyWu View Post
Actually git is not the culprit to blame, but MulticoreWare. It's MulticoreWare's weird strategy to prefix the hash with "g" in its cmake file.
filler56789 is offline   Reply With Quote
Old 19th February 2020, 16:55   #7410  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by benwaggoner View Post
Is it sticking IDRs in the middle of shots?
Yes, that's what it does. It looks like motion and camera movement confuses it a lot. It also doesn't respect the min-keyint setting, which I have at 5 but places I-frames right next to each other.
__________________
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 19th February 2020, 19:53   #7411  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by Boulder View Post
Yes, that's what it does. It looks like motion and camera movement confuses it a lot. It also doesn't respect the min-keyint setting, which I have at 5 but places I-frames right next to each other.

Sounds like time for a bug report to MCW. Min-keyint NEEDS to be respected. Putting in a non-IDR I-frame is okay more often.

Have you tried raising the threshold value?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th February 2020, 20:40   #7412  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by benwaggoner View Post
Sounds like time for a bug report to MCW. Min-keyint NEEDS to be respected. Putting in a non-IDR I-frame is okay more often.

Have you tried raising the threshold value?
Actually I don't know which type of I-frames they are as the source filter (ffms2 in Vapoursynth) only reports I, P or B. x265 itself also reports only I-frames as well so no help from there.

I could try and file a report tomorrow and also play with the threshold value. I only made one test with the default values to see what happens.
__________________
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 19th February 2020, 21:18   #7413  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by Boulder View Post
Actually I don't know which type of I-frames they are as the source filter (ffms2 in Vapoursynth) only reports I, P or B. x265 itself also reports only I-frames as well so no help from there.

I could try and file a report tomorrow and also play with the threshold value. I only made one test with the default values to see what happens.
Have a look at the x265 logs
vpupkind is offline   Reply With Quote
Old 20th February 2020, 10:32   #7414  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Well, ffmpeg uses the "g" prefix too.

Any idea why make became so verbose?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 20th February 2020, 15:42   #7415  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by LigH View Post
Well, ffmpeg uses the "g" prefix too.
Blame cehoyos

Quote:
Any idea why make became so verbose?
Just gave a try to the latest git-download from MCW's x265 and saw the problem doesn't happen to me

Maybe you'd better ask directly to the maintainers of MSYS2, or perhaps to the MABS people...

the [##%] Building etc message format is "induced" (so to speak) by CMake, ¿maybe they have changed something in their latest release?
I'm using version 3.15.2, FWIW.

My MSYS2 environment is "old" as well, its release date is
*checks notes*
2016/Oct/25

And I stopped executing the command "pacman -Syuu" ages ago for a good reason.
filler56789 is offline   Reply With Quote
Old 20th February 2020, 16:04   #7416  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
The cmake messages were all I was used to see. Now I see additional make messages; I guess there are two most possible reasons: a) the current make version is so verbose by default now; b) something in the MSYS2 environment changed, and I am not sure if MABS may have caused that.

Now it looks like this to me:

__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 20th February 2020, 22:18   #7417  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Just so you know that Git and Mercurial are not similar at all. They have HUGE differences and I'd rather think they are completely, totally, different kinds of DVCS. Git has a completely different design, different flexibility, different concepts, etc. than HG. If you apply your knowledge from one tool onto the other you'll likely get lost.

One of the biggest difference is anything you do to the HG repository has side effects. For example, creating a branch and making some commits in HG will permanently leave records, such as affecting commit revision numbers, and leaving a permanent branch that, while hidden, cannot be deleted. In Git, branches and commits can be deleted or changed as you wish. Syncing others' work no longer creates diversity between repositories. Conflicts can be resolved in a nicer way.

The Git command line, however, was pretty hard to use. It's inconsistent in many ways. I always recommend people to stick to a great GUI and only use command lines for occasional batch process. Depending on your role it could be very difficult to work on Git CLI. For example, my mod has 4 branches, all of them being rebased frequently, so `git pull` won't work on any of them, and you have to stick to the low level way of `git fetch` and then rebase what you have onto the branches, or use `git checkout` or `git reset` (dangerous) to update current branch reference. If you are a downstream modder (who takes my patches and integrates into your own mod) you'll likely be transplanting commits across projects and branches. Things get complicated very quick.

I'm kinda surprised to read that many replies talking about Git. Hopefully you'd get used to its concept soon.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median

Last edited by MeteorRain; 20th February 2020 at 22:21.
MeteorRain is offline   Reply With Quote
Old 21st February 2020, 08:31   #7418  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
I noticed that MABS has a quite elaborate helper routine handling Git. So I shall preferably trust its update results. Thank you for your remark, MeteorRain.

And thanks for this workaround parameter, HolyWu.
__________________

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

Last edited by LigH; 21st February 2020 at 08:48.
LigH is offline   Reply With Quote
Old 21st February 2020, 17:41   #7419  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by Boulder View Post
Yes, that's what it does. It looks like motion and camera movement confuses it a lot. It also doesn't respect the min-keyint setting, which I have at 5 but places I-frames right next to each other.

Have you tried higher threshold values? The algorithm does not look at motion, only on colors and texture. They differ a lot when you have a strong scene cut, but low thresholds can result in it false positives.
vpupkind is offline   Reply With Quote
Old 21st February 2020, 18:37   #7420  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v3.3+2-gbe2d82093 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
Code:
https://bitbucket.org/multicoreware/x265_git/commits/branch/master
Barough 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 00:51.


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