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 19th November 2016, 19:51   #4401  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 190
just about CPU... i7-3930K (6-core with HT) is about 15% slower in encoding with x265 2.1+47 to HEVC 10bit 3840x1600 than i5-6600 (4-cores, no HT).
jlpsvk is offline   Reply With Quote
Old 20th November 2016, 01:55   #4402  |  Link
davidsama
Registered User
 
Join Date: Sep 2006
Posts: 38
2.1+55-67e980e is out now. Try that and see if it is any faster for you.
davidsama is offline   Reply With Quote
Old 20th November 2016, 07:19   #4403  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Quote:
Originally Posted by JohnLai View Post
Wait...Pascal only 220fps for 1080p hevc encoding? Sound like CPU decoding bottleneck. Did you use hardware accelerated decoding? It is located at Basic-->Decoder-->nvencc (Native).

*Did you know one can use high quality resizer through --vpp-resize option? (assuming if you resize the video) Need to extract NPP stuff to nvencc location for cubic_bspline, cubic_catmull, cubic_b05c03, super, lanczos, bilinear, spline36 usage.

*Nvenc only make use of single reference frame for hevc encoding. It doesn't matter how many ref you specified.

*There is slight quality issue with CQP mode. It is hard to explain, so... nah, most people won't notice it anyway. Lazy to explain.
Hmm sounds indeed a little slow for Pascal HEVC depending on the bitrate and fps he talks about the 220 fps standing for

GM204 1080p PAL 25 FPS target 4 MBits

encoded 51445 frames, 137.58 fps, 3973.15 kbps, 974.65 MB
encode time 0:06:13 / CPU Usage: 5.48%

frame type IDR 206
frame type I 206, avgQP 24.41, total size 15.43 MB
frame type P 51239, avgQP 26.87, total size 959.22 MB
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 20th November 2016 at 07:36.
CruNcher is offline   Reply With Quote
Old 20th November 2016, 10:54   #4404  |  Link
Jawed
Registered User
 
Join Date: Jan 2008
Location: London
Posts: 156
Can we keep other encoders off this thread?
Jawed is offline   Reply With Quote
Old 20th November 2016, 17:04   #4405  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 326
x265 v2.1+55-67e980e22c43 (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)
Barough is offline   Reply With Quote
Old 21st November 2016, 05:02   #4406  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 48
Quote:
Originally Posted by jlpsvk View Post
just about CPU... i7-3930K (6-core with HT) is about 15% slower in encoding with x265 2.1+47 to HEVC 10bit 3840x1600 than i5-6600 (4-cores, no HT).
This is a very interesting comparison. The i7-3930K has 12 threads overall while the i5-6600 has only 4 threads. (Full spec comparison at http://ark.intel.com/compare/88188,63697.) Despite this, the fact that the i5-6600 achieves 15% over i7-3930K is rather impressive! The reason is because of improved single-thread performance because of AVX2 code in x265, by better pre-fetching to reduce latency, and better memory bandwidth response in the 6th gen cpu.

My bet is that with the Skylake generation (6th gen), the # HW threads where memory limits x265's performance will be much more than the # HW threads where memory limits in the Sandybridge generation (3rd gen) as x265 really benefits from all the improvements in memory bandwidth that Skylake has to offer.

Last edited by pradeeprama; 21st November 2016 at 05:04. Reason: additional information.
pradeeprama is offline   Reply With Quote
Old 21st November 2016, 19:08   #4407  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 190
Hehe... will do the comparison with i7-6700K as soon as it will come from warranty claim..
jlpsvk is offline   Reply With Quote
Old 22nd November 2016, 16:06   #4408  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 883
x265 v. 2.1+59 is out.

http://forum.videohelp.com/threads/3...83#post2467483
filler56789 is offline   Reply With Quote
Old 22nd November 2016, 16:39   #4409  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
HEVC Advance announces new policy - software HEVC implementations are royalty free

Some progress on the HEVC patent licensing! This means that applications like VLC and Handbrake, as well as web browsers and mobile apps with HEVC software implementations are royalty free with respect to HEVC Advance.
HEVC Advance Software Policy

HEVC Advance Presentation Explaining Software Policy
x265_Project is offline   Reply With Quote
Old 22nd November 2016, 16:59   #4410  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,404
VLC and HandBrake also make use of HEVC hardware decoders/encoders.
sneaker_ger is offline   Reply With Quote
Old 22nd November 2016, 17:08   #4411  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 270
But if I understand it correctly, they will seek licensing from (all kinds of) devices with HEVC onboard, as well as things like 'HEVC support built in operating systems'.

The text 'will not seek licensing on software products _after_ the initial safe of the device' means that if you want to buy a device with some kind of HEVC support (encoding or decoding) out of the box, licensing will need to be paid by the manufacturer / supplier of the device.. If HEVC is implemented in software or hardware doesn't matter there.

So Mac OS, Windows, Android, iOS with built in HEVC support (hardware or software) still needs a license by the device manufacturer.. right?

edit:
Just to make clear, it's great news of course! Not trying to be negative here :P.
Does this also mean that making official binaries is on the table or are there other techniques / patens / library-parts that may not be redistributed in binary form?

Last edited by dipje; 22nd November 2016 at 17:33.
dipje is offline   Reply With Quote
Old 22nd November 2016, 17:11   #4412  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by sneaker_ger View Post
VLC and HandBrake also make use of HEVC hardware decoders/encoders.
That's OK. They can only make use of a hardware encoder/decoder that has already been enabled (with the necessary driver) on the device. In that situation, the device manufacturer was already liable to pay the HEVC Advance royalty when they sold or later enabled the hardware encoder/decoder. Software that looks for hardware HEVC encoders/decoders, and uses them when they are present, isn't subject to a separate royalty.
x265_Project is offline   Reply With Quote
Old 22nd November 2016, 17:15   #4413  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,756
Quote:
Originally Posted by sneaker_ger View Post
VLC and HandBrake also make use of HEVC hardware decoders/encoders.
The hardware maker would pay the licenses for that, then. Or so I would assume. They make the decoder afterall, software just accesses it.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 22nd November 2016, 17:16   #4414  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by dipje View Post
But if I understand it correctly, they will seek licensing from (all kinds of) devices with HEVC onboard, as well as things like 'HEVC support built in operating systems'.

The text 'will not seek licensing on software products _after_ the initial safe of the device' means that if you want to buy a device with some kind of HEVC support (encoding or decoding) out of the box, licensing will need to be paid by the manufacturer / supplier of the device.. If HEVC is implemented in software or hardware doesn't matter there.

So Mac OS, Windows, Android, iOS with built in HEVC support (hardware or software) still needs a license by the device manufacturer.. right?
Correct.

The point here is that HEVC Advance is looking for one royalty per device. Prior to this new policy, every software application that included an HEVC software implementation would have been liable for a separate "device royalty". This new policy allows software developers to add HEVC software encoder and decoder libraries to their apps, and distribute them without being liable to HEVC Advance for patent royalties. The caveats you see in the policy are designed to not allow device OEMs (HP, Dell, Apple, Samsung, etc.) to use the policy to avoid paying that one royalty on a device that they sell as being HEVC capable.
x265_Project is offline   Reply With Quote
Old 22nd November 2016, 18:46   #4415  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,562
Quote:
Originally Posted by filler56789 View Post
I did some tests and ran a clip through --limit-tu 0 to 4. To me it seems that the higher the value, the smaller blocks are used. Does this actually mean that I'm sacrificing bitrate but achieving better detail retention and faster encoding speed? I haven't done any frame by frame comparisons yet.
__________________
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 22nd November 2016, 21:50   #4416  |  Link
dev84
Registered User
 
Join Date: Mar 2009
Posts: 51
Hi

This is what i get:



Here are the logs of input and output file and log from MeGui

http://www.filedropper.com/x265logs

And here is the encoded video

http://www.filedropper.com/c0005-muxed


Any idea why is this happening?
dev84 is offline   Reply With Quote
Old 22nd November 2016, 22:03   #4417  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,404
Plays fine here both using VLC and MPC-HC. Try latest versions of both and try software decoding.

If it still errors try ffplay. If that has error too report to ffmpeg bug tracker.
sneaker_ger is offline   Reply With Quote
Old 22nd November 2016, 22:39   #4418  |  Link
dev84
Registered User
 
Join Date: Mar 2009
Posts: 51
hmmm
have no idea i use VLC 2.2.4
i did system restore on the weekend something must be wrong with cfg, but im lost as to what

but this helps me a lot checking the video on other pc

thx
dev84 is offline   Reply With Quote
Old 22nd November 2016, 23:47   #4419  |  Link
WhatZit
Registered User
 
Join Date: Aug 2016
Posts: 59
Quote:
Originally Posted by x265_Project View Post
This new policy allows software developers to add HEVC software encoder and decoder libraries to their apps, and distribute them without being liable to HEVC Advance for patent royalties.
Currently, any AVC vs HEVC comparisons are the subject of specialised forums such as this one, which have limited visibility.

Taking the lead-time for commercial editing/encoding software development into account, this change means that we will FINALLY start seeing a plethora of "x264 vs x265" articles appearing in the mainstream.

This can only be a very good thing for the fostering of HEVC demand.
WhatZit is offline   Reply With Quote
Old 23rd November 2016, 00:35   #4420  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,756
This is just HEVC Advanced though, how is the MPEG-LA's stance on this?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel 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 04:12.


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