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,438
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: 64
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: 8
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: 64
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: 28
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: 28
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
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 01:54.


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