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,446
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,639
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: 975
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 offline   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,676
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: 682
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,676
@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 Today, 19:58   #6510  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,639
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 Today, 20:14   #6511  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,639
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
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:15.


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