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 30th September 2019, 18:35   #7061  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 328
Quote:
Originally Posted by qtwigg View Post
I have been having this issue; I give my x265 a movie and the x265 chooses how much it wants to encode. I give it a 45 minute show, it does 30 minutes. I give it a 1:40 hour movie, it decides not to do the last 10 minutes. I say it decides because it is not erroring. It literally finishes, mux into a container and says, Done! Why does it do this? Never had this problem before and the last 6 months maybe been having this issue randomly, off and on. Any ideas?
That is usually an indication that there is corruption in your original file.
RanmaCanada is offline   Reply With Quote
Old 30th September 2019, 18:59   #7062  |  Link
qtwigg
Registered User
 
Join Date: Mar 2015
Posts: 8
Quote:
Originally Posted by RanmaCanada View Post
That is usually an indication that there is corruption in your original file.
That is what one would think, however the file plays fine (till the end) and without closing the GUI or re-applying my settings or anything, I just press start within the same original GUI that I used before that only encoded some of the file, and it always works second time.
I open the program, add my video, add my settings and AVS, press start.
It does not encode the whole video
I just delete the files
And press start again in the same window
It encodes the whole video
Weird huh? Like I said it is random, not often.
qtwigg is offline   Reply With Quote
Old 30th September 2019, 19:25   #7063  |  Link
redbtn
Registered User
 
redbtn's Avatar
 
Join Date: Jan 2019
Location: Russia
Posts: 105
Quote:
Originally Posted by qtwigg View Post
That is what one would think, however the file plays fine (till the end) and without closing the GUI or re-applying my settings or anything, I just press start within the same original GUI that I used before that only encoded some of the file, and it always works second time.

I open the program, add my video, add my settings and AVS, press start.

It does not encode the whole video

I just delete the files

And press start again in the same window

It encodes the whole video

Weird huh? Like I said it is random, not often.
You have to ask about it the author of your GUI. This problem is not related to x265.
redbtn is offline   Reply With Quote
Old 30th September 2019, 19:46   #7064  |  Link
pistacho
Registered User
 
Join Date: Feb 2010
Location: Spain
Posts: 549
Quote:
Originally Posted by Boulder View Post
I couldn't replicate that difference between the two versions on my 3700X. I used the VS 2019 AVX2 builds from http://www.msystem.waw.pl/x265/

With 3.1+7, encoded 2000 frames in 461.37s (4.33 fps), 3467.58 kb/s, Avg QP:20.97
With 3.1+8, encoded 2000 frames in 459.33s (4.35 fps), 3467.58 kb/s, Avg QP:20.97
In my system (Intel 9700k) the difference persist with these builds:

Code:
y4m  [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 unknown frame count
raw  [info]: output file: T:\TEST\encode.265
x265 [info]: HEVC encoder version 3.1+7-147fb92c5ed5
x265 [info]: build info [Windows][MSVC 1921][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 3 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 240 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I:     11, Avg QP:16.20  kb/s: 6958.02
x265 [info]: frame P:    275, Avg QP:20.60  kb/s: 3482.34
x265 [info]: frame B:    714, Avg QP:25.57  kb/s: 356.63
x265 [info]: Weighted P-Frames: Y:10.9% UV:6.5%
x265 [info]: consecutive B-frames: 22.4% 4.5% 4.5% 38.1% 30.4%

encoded 1000 frames in 17.26s (57.95 fps), 1288.81 kb/s, Avg QP:24.10
Code:
y4m  [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 unknown frame count
raw  [info]: output file: T:\TEST\encode.265
x265 [info]: HEVC encoder version 3.1+8-21db162c8622
x265 [info]: build info [Windows][MSVC 1921][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 3 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 240 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I:     11, Avg QP:16.20  kb/s: 6958.02
x265 [info]: frame P:    275, Avg QP:20.60  kb/s: 3482.34
x265 [info]: frame B:    714, Avg QP:25.57  kb/s: 356.63
x265 [info]: Weighted P-Frames: Y:10.9% UV:6.5%
x265 [info]: consecutive B-frames: 22.4% 4.5% 4.5% 38.1% 30.4%

encoded 1000 frames in 18.76s (53.31 fps), 1288.81 kb/s, Avg QP:24.10
pistacho is offline   Reply With Quote
Old 1st October 2019, 15:17   #7065  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by pistacho View Post
Diff patch send to mailing list.
It arrived safely
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 3rd October 2019, 12:06   #7066  |  Link
ShortKatz
Registered User
 
Join Date: Aug 2018
Location: Germany
Posts: 118
Quote:
Originally Posted by pistacho View Post
Diff patch send to mailing list.
Did you als sign the Contributor License Agreement? See
https://bitbucket.org/multicoreware/...iki/Contribute
They rejected all my patches until I sended them back the signed Contributor License Agreement. It is also important to format it correctly. One of my former patches couldn't be applied, because the formatting was wrong. And don't be surprised if it takes some time. For my patches it normally takes several weeks until they get applied.
ShortKatz is offline   Reply With Quote
Old 3rd October 2019, 14:20   #7067  |  Link
pistacho
Registered User
 
Join Date: Feb 2010
Location: Spain
Posts: 549
My patch is a bug fix (slowdown of 10% for no reason in a stable branch). I don't care if they don't apply my patch as is. I guess someone will correct it somehow...
pistacho is offline   Reply With Quote
Old 3rd October 2019, 17:13   #7068  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Looks like
https://bitbucket.org/multicoreware/...e3ca9a1b6e1d39
and
https://bitbucket.org/multicoreware/...f10c31238d6bf1
commit are meant to fix the "slowdown even is not used AQ mode 4."

Cu Selur
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 4th October 2019, 14:29   #7069  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
x265.exe 3.2+5-354901970679

--- Fix: AQ mode 4 commit (21db162) introduces slowdown even when AQ mode 4 is not used;

--- Adaptive Frame duplication
This patch does the following:
1. Replaces 2-3 near-identical frames with one frame and sets pic_struct based on frame doubling / tripling;
2. Add option "--frame-dup" and "--dup-threshold' to enable frame duplication and to set threshold for frame similarity (optional);


http://www.mediafire.com/file/ado1h8...70679.rar/file
filler56789 is offline   Reply With Quote
Old 4th October 2019, 18:26   #7070  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by filler56789 View Post
x265.exe 3.2+5-354901970679--- Adaptive Frame duplication
This patch does the following:
1. Replaces 2-3 near-identical frames with one frame and sets pic_struct based on frame doubling / tripling;
2. Add option "--frame-dup" and "--dup-threshold' to enable frame duplication and to set threshold for frame similarity (optional);[/I]
I see the default value of dup-threshold is 70. It would be helpful to know if higher numbers require more or less similarity, and ballpark how much similarity is requires for 70. I hope it is sub-psychovisual at least.

I could see this helping efficiency and encoding speed for stuff like a title card displayed for a couple of seconds.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th October 2019, 19:08   #7071  |  Link
fauxreaper
Registered User
 
Join Date: Oct 2014
Posts: 23
--frame-dup makes output duration smaller than input. Is it a decoder problem of not duplicating/triplicating frame duration when needed? Or is it a muxing problem when using matroska as a container?

Last edited by fauxreaper; 5th October 2019 at 02:52.
fauxreaper is offline   Reply With Quote
Old 4th October 2019, 19:34   #7072  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
I wonder if that mode is really that beneficial. If it detects dupes, it could just code them as all-skip P or B frames with minimal bitstream overhead. Sure, that single frame is being saved, but in the grand scheme of things for a small scene of a static shot that seems insignficant. Nevermind that repeat flags are likely to trip up decoders and/or muxers, as you basically generate a VFR bitstream.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 4th October 2019, 20:07   #7073  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by nevcairiel View Post
I wonder if that mode is really that beneficial. If it detects dupes, it could just code them as all-skip P or B frames with minimal bitstream overhead. Sure, that single frame is being saved, but in the grand scheme of things for a small scene of a static shot that seems insignficant. Nevermind that repeat flags are likely to trip up decoders and/or muxers, as you basically generate a VFR bitstream.
All-skip frame is way more expensive than changing a pic_struct value.
The reason for doing such a weird VFR is that the same mechanism used for 3:2 pulldown and 24->60p conversion is used here.
vpupkind is offline   Reply With Quote
Old 4th October 2019, 20:26   #7074  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by benwaggoner View Post
I see the default value of dup-threshold is 70. It would be helpful to know if higher numbers require more or less similarity, and ballpark how much similarity is requires for 70. I hope it is sub-psychovisual at least.

I could see this helping efficiency and encoding speed for stuff like a title card displayed for a couple of seconds.
The threshold is PSNR value between consecutive pictures
vpupkind is offline   Reply With Quote
Old 4th October 2019, 22:25   #7075  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by vpupkind View Post
All-skip frame is way more expensive than changing a pic_struct value.
Sure, in relative terms. But in absolute terms, in a sea of actually coded and changing frames, how much of a difference are we talking here? 0.01%? Likely not even that.

Quote:
Originally Posted by vpupkind View Post
The reason for doing such a weird VFR is that the same mechanism used for 3:2 pulldown and 24->60p conversion is used here.
A mechanism thats already rarely used in HEVC, and likely not well supported, or intentionally ignored, because original 24p content is just better then stuttery 30p.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 5th October 2019, 03:51   #7076  |  Link
WhatZit
Registered User
 
Join Date: Aug 2016
Posts: 60
Quote:
Originally Posted by benwaggoner View Post
I could see this helping efficiency and encoding speed for stuff like a title card displayed for a couple of seconds.
I could see this being as big a pain-in-the-arse as traditional VFR. Luckily, it is disabled by default.

Still, one of Multicoreware's corporate clients probably asked for it (anime OTT?), so there it is.
WhatZit is offline   Reply With Quote
Old 5th October 2019, 15:54   #7077  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x265 3.2+5-354901970679
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 5th October 2019, 17:02   #7078  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
Quote:
Originally Posted by WhatZit View Post
I could see this being as big a pain-in-the-arse as traditional VFR. Luckily, it is disabled by default.

Still, one of Multicoreware's corporate clients probably asked for it (anime OTT?), so there it is.
Actually it's not really a good idea for anime. The duplicate removal filters like this can mishandle a very common scenario where the whole picture doesn't move at all, but there is just mouth movement in a tiny part. It can be just few pixels, but killing that and replacing with wrong duplicate is a terrible sort of artifact.
mandarinka is offline   Reply With Quote
Old 6th October 2019, 15:33   #7079  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by mandarinka View Post
Actually it's not really a good idea for anime. The duplicate removal filters like this can mishandle a very common scenario where the whole picture doesn't move at all, but there is just mouth movement in a tiny part. It can be just few pixels, but killing that and replacing with wrong duplicate is a terrible sort of artifact.
I am unsure whether these two frames will have a PSNR of 70dB -- you will still have a significant absolute distance between a couple of co-located pixels, which should bring it below the threshold. Would be very interested in test results -- don't have a decent anime source.
vpupkind is offline   Reply With Quote
Old 6th October 2019, 23:52   #7080  |  Link
Magik Mark
Registered User
 
Join Date: Dec 2014
Posts: 666
Hey Guys,

Are there any new switches that would speed up multi pass encoding?
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR
Magik Mark 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 23:08.


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