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 > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 30th November 2022, 16:15   #1  |  Link
Easy
Registered User
 
Join Date: Jan 2016
Location: Germany
Posts: 8
Naiv Question: Supercharge x264

This question may be naiv , but still I would like a professional answer to it if possible

Question is: Why not optimize x264 code with x265 code.
So here is the naiv part: x265 is e.g. known for using more and bigger partitions than x264. For example 32x32 and 64x64 , but why not use something like 'group of partitions' in x264 ; for example use four 8x8 to get 32x32.
Using more fake CTU parts in Macroblocks is only an example, may not be useful in the real world but atleast something that can be tested. Also there may be DCT optimizations that could be ported.
Also should it technical be possible to use CABAC and CAVLC simultaneous to reduce decoding spikes.
I know that one can not touch the decoder side of things as it should stay compatible with existing decoders. So not to many 'features' can be ported without changing also how to decode them.

An answer from especially people how looked at the source code would be very helpfull. I don't know c++ or asm, but I know how a function looks and some rough porting theory. So maybe this could be my weekends hobby for the next year or so.

Last edited by Easy; 30th November 2022 at 17:51.
Easy is offline   Reply With Quote
Old 30th November 2022, 16:34   #2  |  Link
mastrboy
Registered User
 
Join Date: Sep 2008
Posts: 358
If the goal of this excercise is to optimize cpu usage/speed up the encode process you can try https://github.com/master-of-zen/Av1an
__________________
(i have a tendency to drunk post)
mastrboy is offline   Reply With Quote
Old 30th November 2022, 17:36   #3  |  Link
Easy
Registered User
 
Join Date: Jan 2016
Location: Germany
Posts: 8
Quote:
Originally Posted by mastrboy View Post
If the goal of this excercise is to optimize cpu usage/speed up the encode process you can try https://github.com/master-of-zen/Av1an
Thank you for sharing , this is one aspect of my thoughts and this repo sounds amazing. Still, I would like to see also quality differentiations (of course the goal is to improve things)
AV1an looks like half the work , but not completing my thoughts.

To clarify further , I want to improve x264 with speed and quality options , initially with improved code from newer codecs like 265
Easy is offline   Reply With Quote
Old 1st December 2022, 01:27   #4  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,371
Quote:
Originally Posted by Easy View Post
This question may be naiv , but still I would like a professional answer to it if possible

Question is: Why not optimize x264 code with x265 code.
So here is the naiv part: x265 is e.g. known for using more and bigger partitions than x264. For example 32x32 and 64x64 , but why not use something like 'group of partitions' in x264 ; for example use four 8x8 to get 32x32.
Using more fake CTU parts in Macroblocks is only an example, may not be useful in the real world but atleast something that can be tested. Also there may be DCT optimizations that could be ported.
Also should it technical be possible to use CABAC and CAVLC simultaneous to reduce decoding spikes.
I know that one can not touch the decoder side of things as it should stay compatible with existing decoders. So not to many 'features' can be ported without changing also how to decode them.

An answer from especially people how looked at the source code would be very helpfull. I don't know c++ or asm, but I know how a function looks and some rough porting theory. So maybe this could be my weekends hobby for the next year or so.
Interesting ideas. I'm not either if your examples would provide practical benefit, but you're thinking about the problem in a good, creative way.

MultiCoreWare licensed all of x264, and x265 started out largely in mixing x264 performance and psychovisual optimization stuff with the HEVC reference encoder. After a few years, they started going into all-new directions not based on either code base. But the deal was they would contribute everything back to x264 so relevant features could be added. Not much actually got backported, though. Probably because x265 development really got into gear as x264 was sliding into a more maintenance mode.

There's lower-hanging fruit in adding features to x264 that I know MCW contributed in x264-compatible ways, like x265's very awesome csv logging. I don't know how easy it would be to find old MCW contributions that never made it into the main branch, but if you can, I bet there's a lot of fun stuff that could be made functional with a couple weeks' work.

Assembly stuff would be a whole lot harder, as it's a lot harder to work with in general. And H.264 itself just doesn't have the same opportunities for really big SIMD functions to speed things up. There are only 4x4 and 8x8 blocks, while HEVC can go from 4x4 to 32x32, including 4x16 and many other power-of-two variations. x265 gets bigger chunks of data to work with at once, and has enormously more mode decisions to make. In a 64x64 block of pixels, x265 has many dozens (hundreds) of different ways it can break down texture units, especially if --amp and --rect are used. For x264, it only needs to figure out whether to use 4x4 or 8x8 for each 16x16 macroblock. And each of those TU's can use one of 33 (IIRC) predictions modes instead of H.264's eight, including whole new mode types like lossless and transform skip.

A big share of x265 assembly optimization is around mode selection, and most of that simply isn't applicable to x264.

I imagine there are some cases that are algorithmically identical to x264 that x265 simply has better optimized implementations of that could be backported. Or x264 subsets of algorithms that could have the x265-only parts of stripped out.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st December 2022, 01:34   #5  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,371
Big picture though, there are fundamental inescapable reasons why x265 is able to use more CPU and more threads for a video of the same resolution than x264 can. WPP threading isn't possible in x264 as H.264 doesn't have WPP. The flipside is that the greater simplicity of x264 means it's already a whole lot faster than x265. Which also means that's x265 is already a lot closer to optimal performance than x265 is even today.

x265's improve scenecut and frame type decision algorithms would be much more likely to have stuff straightforward to backport, as frame types and why to decide one or the other. Stuff like --mctsf and --hist-scenecut also would be quite relevant to x264.

There may well be bigger opportunities to improve quality/compression efficiency of x264 than encoding speed in backporting from x265.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 5th December 2022, 16:29   #6  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Metropolitan City of Milan, Italy
Posts: 2,421
In terms of speed, I would actually love if someone wrote AVX512 assemblies for the 10bit version of x264.
We already have them for the 8bit version, which is really welcomed for distribution encodes (especially given that we do lots of them), but any mezzanine file / TX Master is gonna be 10bit, think about Intra Classes for FULL HD and UHD files. Especially with UHD files, I feel like AVX512 would speed up XAVC encodes a lot in x264 compared to AVX2 only.
FranceBB is offline   Reply With Quote
Reply

Tags
port, source code, x264, x265

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 21:55.


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