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 26th November 2018, 10:38   #6501  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,450
Quote:
Originally Posted by FranceBB View Post
Still, in an ideal world, compilers would be able to produce optimized assembly code as fast as manually-written intrinsics, so there's no need to manually write them.

Unfortunately, that's still an utopia.
And it will always remain nothing but a dream. A compiler does not have enough information about the restrictions and requirements of the algorithm to perform the same sort of optimization a developer can do when manually writing ASM - especially with advanced SIMD.

PS:
Anyone that runs on a 32-bit system deserves what they get. Upgrade already, stop wasting developers and your own time. A simple change from 32-bit to 64-bit on the same hardware will yield a massive speedup already. And if you're encoding with x265 on hardware thats not even 64-bit compatible, then you should *really* upgrade.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 26th November 2018 at 10:40.
nevcairiel is online now   Reply With Quote
Old 26th November 2018, 18:42   #6502  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,644
Quote:
Originally Posted by nevcairiel View Post
And it will always remain nothing but a dream. A compiler does not have enough information about the restrictions and requirements of the algorithm to perform the same sort of optimization a developer can do when manually writing ASM - especially with advanced SIMD.
Yeah, QFT++. Autovectorization has been a dream for decades, and itís never gotten anywhere near what hand assembly can do. Same with autoparallelization. A good compiler and the right code can maybe get 2-3x faster. Intelís whole Itanium debacle was premised on, and failed because of, very over optimistic assumptions about compilers being able to do this stuff.

Apple switching to Intel was such a boon to the industry because it eliminated the need for media apps to have to implement on both SSEx and AltiVec. Because you couldnít even port between them; often the whole algorithm had to be refactored to get decent performance.

As it is, x265 is probably some of the most advanced and complex SIMD code on the planet, with a lot of complex threading to boot. Itís likely about the worse case for a speed gap between compiler-generated SIMD versus hand-coded SIMD.

Quote:
Anyone that runs on a 32-bit system deserves what they get. Upgrade already, stop wasting developers and your own time. A simple change from 32-bit to 64-bit on the same hardware will yield a massive speedup already. And if you're encoding with x265 on hardware thats not even 64-bit compatible, then you should *really* upgrade.
Are people actually still doing this? I canít imagine how slow x265 must be on pre x64 hardware. I donít think Iíve had a machine NOT running 64-bit since Windows 7 launched, and everything I was running when Win 7 launched was already 64-bit capable.

The joules per pixel on a pre x264 system has to be a couple of orders of magnitude worse than the latest Intel and AMD processors deliver. And upgrade would pay for itself quickly in lowered elecctricity & cooling costs alone!
__________________
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 26th November 2018, 20:24   #6503  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 976
Quote:
Originally Posted by benwaggoner View Post
Are people actually still doing this? I can’t imagine how slow x265 must be on pre x64 hardware. I don’t think I’ve had a machine NOT running 64-bit since Windows 7 launched, and everything I was running when Win 7 launched was already 64-bit capable.
It's been a long, long time since I ever tried, although I do keep a full set of 32-bit build instructions for all the pieces in my FFmpeg/mpv build guide. For posterity, mostly.

My guess would be that you could get decent encode times with x265 on a PIII only by encoding at most 480p under --profile ultrafast at 8bit (since the >8bit ASM has to be explicitly turned off to build for 32-bit). And possibly not even then, as I'm pretty sure we'd still be looking at maybe 5fps. At that point you're dealing with strictly academic 'because I can' types of things, and you'd absolutely get better framerates (at a preciser preset) by just using x264 instead.

Quote:
The joules per pixel on a pre x264 system has to be a couple of orders of magnitude worse than the latest Intel and AMD processors deliver. And upgrade would pay for itself quickly in lowered elecctricity & cooling costs alone!
Exactly. My Coppermine system was only a main system until 2015, and it only held out that long because of not having an income up until then (it is still alive, though, but now serves as a file archive).

Inexpensive mini-PCs have really filled the gap here, and get vastly better performance than an ancient system like that would get. Even with the power draw restraints and lack of AVX 1 or 2, Bay Trail-T (and now Apollo Lake, since I inadvertently fried the other one) could run circles around the Coppermine while being dead silent because the power consumption is so low they don't even need a cooling fan. Plus access to better SIMD - up to SSE4.2, plus the AES stuff - and multithreading. Running 64-bit OSes can be a bit of a task - the Bay Trail-T era would normally only ship with 32-bit versions of Windows on tiny eMMC storage (and since they come with 32-bit UEFI, you can't use 64-bit Windows, although 64-bit Linux distros loaded from flash drives or external USB hard drives are an option), but by now 64-bit Windows installs seem common, along with allowing for putting secondary SSDs into the system.

I've done 4K->4K and 4K->1080p transcodes on the Apollo Lake at about 5fps (ultrafast, 10bit, preserving HDR, crf 18), and at least Apollo Lake has a 10bit HEVC decoder in the GPU. Had I known the exact way to get that enabled in mpv at the time, I wouldn't have even bothered trying to transcode. But it let me get working figures, and I suppose 1080p 10bit HEVC would be less of a burden on the GPU than 4K would, so there's that.

Last edited by qyot27; 26th November 2018 at 20:30.
qyot27 is online now   Reply With Quote
Old 27th November 2018, 17:24   #6504  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 453
Quote:
Originally Posted by Wolfberry View Post
x265 v2.9+8-27d8424c799d
(64-bit GCC 8.2.0 8+10+12bit multilib / ICC 19.0 8/10/12 cli+shared)
Apologies, I'm only seeing a v2.9+9 build on that, and that's built with GCC 8.2. I can't find an ICC build in that Google Drive, or am I blind?
aegisofrime is offline   Reply With Quote
Old 4th December 2018, 15:49   #6505  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 62
I have to glue several shots, which all have different resolution, together.
Ideally I'd like to keep the original resolution.
Is it possible to have variable resolution? (If so, is it UHD compliant/will it play nicely on modern UHD devices?)
K.i.N.G is offline   Reply With Quote
Old 4th December 2018, 15:53   #6506  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,677
Quote:
I have to glue several shots, which all have different resolution, together.
...
Is it possible to have variable resolution?
iirc mkv added support for this a while back, but that has nothing to do with x265
(best ask Mosu to be sure)

Quote:
If so, is it UHD compliant/will it play nicely on modern UHD devices?
No.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 5th December 2018, 15:56   #6507  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 62
Ah, too bad... Thanks for the quick & clear reply!
K.i.N.G is offline   Reply With Quote
Old 9th December 2018, 16:31   #6508  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 685
Quote:
Originally Posted by Selur View Post
iirc mkv added support for this a while back
I tried searching the changelog for resolution, variable and so on, but could not find anything. Do you recall which version was it roughly, or where can I find information about that? Support for variable resolution, or better said, variable display aspect ratio as well is something I tried to solve for years. The problem was that matroska stored such data in a single header entry valid for the whole file; back when designing it, nobody imagined files where there would be need to switch these parameters.

AFAIK the best possible solution was to use separate files and link them using the next/previous segment linking fucntionality.

Last edited by mandarinka; 9th December 2018 at 16:33.
mandarinka is offline   Reply With Quote
Old 9th December 2018, 16:43   #6509  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,677
@mandarinka: Like I wrote 'best ask Mosu to be sure'
I thought there was a way to combine file with multiple resolutions and the problem was to find a player supporting it, but Mosu most definitely can shine some light on it whether I just remember this wrong of if there is a way to create such files.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 12th December 2018, 19:58   #6510  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,644
Quote:
Originally Posted by Selur View Post
@mandarinka: Like I wrote 'best ask Mosu to be sure'
I thought there was a way to combine file with multiple resolutions and the problem was to find a player supporting it, but Mosu most definitely can shine some light on it whether I just remember this wrong of if there is a way to create such files.
The only software player I know of that can handle arbitrary resolution changes while maintaining constant displayed image size and aspect ratio is Windows with a MFT from Expression Encoder installed.

That at least works with variable-sized VC-1; I've never tried it with H.264. If a player is attending to SAR, doing a full-screen playback should Just Work. But it seems players rarely account for the SAR changing each GOP even if they can handle different resolutions.

This does work in most players on living room devices, though, since it's common for SAR to change (e.g. 720x480 to 1280x720 both at 16:9) with stream switching.
__________________
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 12th December 2018, 20:14   #6511  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,644
After a bit of a draught, we have five new checkins for x265! Three for Dolby Vision Profile 5 support, one to make muxing of chunked encoding easier, and one to allow cutree to be used in analysis reuse, finally.

https://bitbucket.org/multicoreware/x265/commits/all
__________________
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 13th December 2018, 06:42   #6512  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 86
x265 2.9+14-3023bd8b05c0 ICL 19.0 x64
__________________
RAC#1-6

Last edited by Wolfberry; 13th December 2018 at 11:30.
Wolfberry is offline   Reply With Quote
Old 13th December 2018, 16:00   #6513  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,680
x265 2.9+14-3023bd8b05c0 (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.2.1)

support for Dolby Vision profile 5 and RPU multiplexing; Cutree offset for analysis reuse
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th December 2018, 00:05   #6514  |  Link
imhh11
Registered User
 
Join Date: Jul 2016
Posts: 65
Thanks for the update.

is DV profile 5 single layer ?
if yes, then does it mean we can now convert our 2 layer DV uhd disc to a single layer file playable via usb into our TV ?
imhh11 is offline   Reply With Quote
Old 14th December 2018, 01:19   #6515  |  Link
utack
Registered User
 
Join Date: Apr 2018
Posts: 17
Netflix dropped a new article.
H264/H265/VP9 comparison using HVMAF with reference encoders and production encoders.
x265 is doing quote ok but can't always beat HM, EVE-VP9 does similarly well
Relative Bitrate savings for low and high quality using three test sets:



https://medium.com/netflix-techblog/...e-d45d0183ca95
utack is offline   Reply With Quote
Old 14th December 2018, 15:01   #6516  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 298
x265 v2.9+15-81373aab81df (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit : GCC 7.4.0 / 64bit : GCC 8.2.1)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 14th December 2018, 15:08   #6517  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,680
^ just a fixed compiler warning
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old Today, 04:15   #6518  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 407
Quote:
Originally Posted by mandarinka View Post
I tried searching the changelog for resolution, variable and so on, but could not find anything. Do you recall which version was it roughly, or where can I find information about that? Support for variable resolution, or better said, variable display aspect ratio as well is something I tried to solve for years. The problem was that matroska stored such data in a single header entry valid for the whole file; back when designing it, nobody imagined files where there would be need to switch these parameters.

AFAIK the best possible solution was to use separate files and link them using the next/previous segment linking fucntionality.
Yup, linked mkvs and ordered chapters (the latter has more widespread support) can handle frame rate changes as well as resolution.

mpv used to use the bitstream DAR instead of the container until I pointed out that I could troll mpv users by encoding a bitstream with rapidly shifting DARs that would work perfectly fine on every other player.
There's really little real-world need to change DAR midstream given the video resolution has to be constant, and container DAR is better than bitstream since that allows it to be trivially fixed if wrong.
kuchikirukia is offline   Reply With Quote
Old Today, 20:24   #6519  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 168
Quote:
Originally Posted by imhh11 View Post
Thanks for the update.

is DV profile 5 single layer ?
if yes, then does it mean we can now convert our 2 layer DV uhd disc to a single layer file playable via usb into our TV ?
i would like to know that too. and if yes, how.
__________________
Core i9-7940X, 64GB DDR4, 1TB SSD, 3TB HDD, 32TB NAS
jlpsvk is offline   Reply With Quote
Old Today, 21:34   #6520  |  Link
seandarcy
Registered User
 
Join Date: Oct 2007
Posts: 19
grain vs crf for a fixed bitrate ?

Do I use -tune grain, or just decrease crf for the same bitrate ?

I've ripped some old film-based blurays which have film grain that I'd like to retain. I understand that -tune grain will retain the grain, at a 50% increase in file size, or equivalently bitrate. So, as I understand it, if a given crf has 2000kbs, adding -tune grain will result in 3000kbs. But what if I decreased the crf until I got 3000kbs without -tune grain ? Will I retain some/all of the original grain ?

Assume I have a specific bitrate budget, say 3000kbs.

Am I better off with -tune grain crf X (say 29), or no grain and crf X - 2 or 3 (say crf 26 ) ? Again I've picked the crf's so that the output has the same bitrate.

x265, 2.9.
My command line :
ffmpeg -i in.mkv -c:a copy -c:v libx265 -preset medium [-tune grain] crf X -pix_fmt yuv420p10le -x265-params colorprim=bt709:colormatrix=bt709:transfer=bt709 out.mkv

I'm sure that some place in this thread this question has been asked and answered, but none that I've found discuss grain vs crf for a fixed bitrate.
seandarcy 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:42.


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