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 > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th July 2018, 07:38   #81  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,603
No clue why mine is slower. Plain GCC 7.3.0 build. What's different in jonatans', new dev revision or higher CPU optimization while compiling C sources?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 8th July 2018, 00:34   #82  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 74
Quote:
- Dual-licensing scheme: LGPL and commercial license
Is the first L in LGPL intentional?
__________________
saldl: a command-line downloader optimized for speed and early preview.
MoSal is offline   Reply With Quote
Old 8th July 2018, 04:35   #83  |  Link
Zebulon84
Registered User
 
Join Date: Apr 2015
Posts: 10
LGPL = Lesser General Public License.
Lesser because it allows the work to be linked to work with other type of license. Here it allows it to be used as a library (.dll) in any software. If it was GPL, it could only be used within GPL software.
Zebulon84 is online now   Reply With Quote
Old 8th July 2018, 15:11   #84  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 74
Quote:
Originally Posted by Zebulon84 View Post
LGPL = Lesser General Public License.
Lesser because it allows the work to be linked to work with other type of license. Here it allows it to be used as a library (.dll) in any software. If it was GPL, it could only be used within GPL software.
I know. That's why I'm asking. Dual licensing is usually GPL/commercial. Or GPL/LGPL.

LGPL/commercial still makes sense if it's about the commercial licensee making source modifications and not contributing back. But, if this is about other limitations in the LGPL, then one would be better served with another license like the MPLv2.
__________________
saldl: a command-line downloader optimized for speed and early preview.
MoSal is offline   Reply With Quote
Old 9th July 2018, 21:59   #85  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 31
Quote:
Originally Posted by MoSal View Post
Is the first L in LGPL intentional?
Yes.

Quote:
Originally Posted by LigH View Post
No clue why mine is slower. Plain GCC 7.3.0 build. What's different in jonatans', new dev revision or higher CPU optimization while compiling C sources?
I don't know really. Mine is built from xvc version 2, master branch, commit 283009f using the Visual Studio compiler.

I also get much slower encoding times with your build. Will try to look further into what causes the difference.

Quote:
Originally Posted by colinhunt View Post
xvcenc.exe -input-file moto.yuv -input-width 1920 -input-height 1080 -input-bitdepth 8 -framerate 24 -verbose 1 -threads 20 -speed-mode 2 -qp 30 -explicit-encoder-settings "aqp_strength 16" -output-file output.xvc

v1 binary: 183 minutes, no multi-threading.
v2 binary (LigH's): 94 minutes. 20 threads, CPU usage peaked at 47%.
v2 binary (Jonatan's): 51,3 minutes. 20 threads, RAM usage 5.9GB, CPU usage peaked at 56%.

v2 binary (Jonatan's): 51 minutes. 10 threads, CPU usage peaked at 55%.

v2 binary (Jonatan's): 51 minutes. 40 threads, RAM usage 8.5GB, CPU usage peaked at 59%.
v2 binary (Jonatan's): 51 minutes. 8 threads, RAM usage 2.1GB.
Thanks for the extensive testing colinhunt. The reason why you do not see higher speed-up might be related to that the sequence you are encoding is roughly equally long as the segment length you are using. If you would be using a sequence that was 4 times as long or if you would set -max-keypic-distance to something like 160 you might get a higher speed-up factor (but that would of course also affect the compressed result).
__________________
Jonatan Samuelsson
Co-founder and CEO at Divideon

www.divideon.com | xvc.io
jonatans is offline   Reply With Quote
Old 11th July 2018, 23:09   #86  |  Link
colinhunt
Registered User
 
Join Date: Dec 2002
Posts: 998
Quote:
Originally Posted by jonatans View Post
The reason why you do not see higher speed-up might be related to that the sequence you are encoding is roughly equally long as the segment length you are using.
The source file, which I've shared earlier in this thread, is 468 frames long. What's the default segment length? That's what I'm (probably?) using.
colinhunt is offline   Reply With Quote
Old 12th July 2018, 11:35   #87  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 31
Quote:
Originally Posted by colinhunt View Post
The source file, which I've shared earlier in this thread, is 468 frames long. What's the default segment length? That's what I'm (probably?) using.
Default segment length is 640. To get high level of parallelism with a 468 frames long sequence you might try for example -max-keypic-distance 160 or even -max-keypic-distance 128.
__________________
Jonatan Samuelsson
Co-founder and CEO at Divideon

www.divideon.com | xvc.io
jonatans is offline   Reply With Quote
Old 30th August 2018, 10:21   #88  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 31
Some more speedups and printout of PSNR has been added to the master branch of https://github.com/divideon/xvc (use -tune 1 if you want to perform analysis based on PSNR and -tune 0 for best visual quality).

It would be interesting to hear more reports on the usage of threading in xvc in different configurations and on different platforms to see if there are settings that can be adjusted for improved performance.

Other comments and suggestions are of course also welcome.
__________________
Jonatan Samuelsson
Co-founder and CEO at Divideon

www.divideon.com | xvc.io
jonatans is offline   Reply With Quote
Old 30th August 2018, 10:56   #89  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,603
New upload: xvc v2.0 2018-08-30 #1cbe133 (MSYS2, MinGW32 + GCC 7.3.0 / MinGW64 + GCC 8.2.0)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 30th August 2018, 19:59   #90  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 840
I made only 1 test encode, so i dont know if it's a general behaviour or not, but the resulting video is identical to the one made with the older build from may, but it took nearly twice the time to finish. After the first keyframe is finished, it waits several minutes seemingly doing nothing (using 25% cpu on a 4 core haswell i5) until it starts to encode the inter-frames. Maybe i remember incorrectly, but i dont think the older build did that long wait. After that it seems to work ok, using 96-98% cpu at times. I set the number of threads to 4.
Tommy Carrot is offline   Reply With Quote
Old 30th August 2018, 20:03   #91  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,603
Does the 32 bit (GCC 7.3.0) build delay the same way as the 64 bit (GCC 8.2.0) build?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 30th August 2018, 20:45   #92  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 840
Yes, the 32 bit build is doing the same. I had a 10 minute "idle time" between the first keyframe and the first inter-frame encoded. The whole encoding is taking 23 minutes. The old build did it in 11 minutes with identical output.
Tommy Carrot is offline   Reply With Quote
Old 30th August 2018, 22:13   #93  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 31
I have uploaded 64-bit binaries built with Visual Studio. Available here: https://drive.google.com/open?id=1K0...EB_vDrj5XrajkA
__________________
Jonatan Samuelsson
Co-founder and CEO at Divideon

www.divideon.com | xvc.io
jonatans is offline   Reply With Quote
Old 31st August 2018, 12:09   #94  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 840
Your visual studio build doesn't do that long delay, it finished the same encode in 10 minutes.

edit: just to clarify, it still waits 2-3 minutes before it finishes the first inter-frame, it just seems to be generally faster.

Last edited by Tommy Carrot; 31st August 2018 at 12:22.
Tommy Carrot is offline   Reply With Quote
Old 31st August 2018, 12:45   #95  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,603
Then we may need someone with experience in GNU profiling tools to discover the reason...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 31st August 2018, 16:36   #96  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,594
Quote:
Originally Posted by Tommy Carrot View Post
Your visual studio build doesn't do that long delay, it finished the same encode in 10 minutes.

edit: just to clarify, it still waits 2-3 minutes before it finishes the first inter-frame, it just seems to be generally faster.
I'm guessing there is some kind of long lookahead taking place, so a bunch of frames are getting encoded and refined in RAM before the first inter frame in decode order gets written. This happens in all codecs to some degree. For example, a GOP like

IbBbPbBbP

Actually needs to get written to the file as:
IPBbbPBbb

The second frame can't be written until the fifth frame is finalized.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Instant Video

My Compression Book

Amazon Instant Video is hiring! PM me if you're interested.
benwaggoner is offline   Reply With Quote
Old 25th September 2018, 10:11   #97  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,603
New upload: (MSYS2, MinGW32 + GCC 7.3.0 / MinGW64 + GCC 8.2.0)

xvc v2.0 2018-09-23 #d3e8b46

New commit d3e8b46 in master: Allow parsing one picture nal after segment header
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Reply

Tags
codec, compression, video codec, video encoding, xvc

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 15:34.


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