MSU x264 improvement published published, precisely, function, research, original

andy

As I have already told, VideoGroup is making research in area of video compression. Last autumn we have started to analyze x264 sources. Now we have first results!

The first modification is start parameters of codec. We replaced quot;start_qpquot; predefined parameter with function of target bitrate. It allows codec to predict first frame size more precisely. The improvement is significant at low bitrates with relatively short sequences. In our tests we outperform original version of codec (sources 02.12.06) up to 2 Db.

Main impact is provided on small sequences (on the begin of video)Improvement is bigger on low bitrates:More detailed information (including modified sources, binaries and examples) can be found here:
video/x264...vement_en.html

Enjoy!

@DmitriyV2

Codec's web pages:

x264 web page
Another x264 web page x264 web page lt;-- main website is x264.html

x264.nl is an unofficial site for win32 builds.

Please use from--x264.nl (don't use pisses me off)

Why did you choose (a*bitrate^b+c) as your model? QP is inherently a log scale, so (a*log(bitrate)+b) seems more applicable.
Also, that ignores resolution, so (a*log(bitrate)+b*log(pixels)+c).

Could you include a 2pass encode on the per-frame psnr graph? That being the target that ABR would achieve if it had perfect knowledge of all frames' complexity.

Any build with updated source?

I only do low bitrates   

Good work!!!

Many people already have quot;experiencequot; with OPSNR values. Even the different revisions of x264  may have different OPSNR ( approx. +/- 0.3  maybe more)  and SSIM. But it has nothing to do with quality.  Firstly check visually then check SSIM and OPSNR values.  
We've already seen that before MANY times. The biggest value of PSNR and smooth as hell video.
Cheers.

P.S. Psnr increase -gt;  SSIM decrease and viseverse. As a result the quality is approx. the same.
If PSNR and SSIM increase that's another deal.

Very good work, DmitriyV2. Do you plan to continue that test, but with newest x264 source, this time, from March 9?


Originally Posted by SirberAny build with updated source?
I only do low bitrates   
Good work!!!

Sure! See quot;Downloadquot; section on page!
MSU Patched:
video/x264...u_improved.zip
Original:
video/x264/x264.zip

Thanks!


Originally Posted by Kostarum Rex PersiaVery good work, DmitriyV2. Do you plan to continue that test, but with newest x264 source, this time, from March 9?

Sure! This project is not so big, but we plan to continue.


Originally Posted by bob0rx264 web page lt;-- main website is x264.html

Ok! We will fix this.
Please use from--x264.nl (don't use pisses me off)

Ok! Only for you!


Originally Posted by akupenguinWhy did you choose (a*bitrate^b+c) as your model? QP is inherently a log scale, so (a*log(bitrate)+b) seems more applicable.
Also, that ignores resolution, so (a*log(bitrate)+b*log(pixels)+c).

Could you include a 2pass encode on the per-frame psnr graph? That being the target that ABR would achieve if it had perfect knowledge of all frames' complexity.

Really we test a big amount of variants and select varian, that provide the biggest performance gain for several videos.

Now we work on more complex x264 measurement, but we allready spend a lot of time for some technical problems with codec state saving. Code is good, but some hack's (like goto) bother clear returning to previous state. Looks like with solving of this problem there will be easy to make more complex experiments with x264 and provide better results in 1- and even 2-pass modes (variety of decisions in H.264 is pretty big).

If this works for abr, can results be reasonably extended to crf, or are they too different? Very interesting results, I will try patching the latest version and see what happens.

crf never had the problem that this patch tries to address. cbr worked too, since vbv limited the 1st frames sizes.

I just manually patched rev.465 with the MSU source and did a short test at 450kbps (2500frames). It's not a big PSNR difference (if any) compared to the clean SVN build, but maybe I'm not encoding with the best options for MSU.


Originally Posted by hpnI just manually patched rev.465 with the MSU source and did a short test at 450kbps (2500frames)

Not short enough. The patch only matters on the first few frames.

So basically, you invented a single-line patch that is based on a not-very-well-thought-of model and which tries to optimize one parameter known to have very little effect on anything?

I don't want to criticize your work, but, if you don't mind, I'd like to express my criticizm on the hype you created. Even if you do it right (taking resolution into account is a no-brainer), this hardly deserves a single email with a patch, in my very humble opinion.

I'm sorry if my words sound harsh...

[edit] Since your graph shows improved quality for almost all frames, it's pretty obvious that this can only be achieved with one clip having a higher bitrate. What are the bitrates of the two clips?

sysKin, I also think its a lot of hype for this modification alone, but they said that they will try to improve more complex x264 functions from which the 2pass mode and long encodes will benefit as well so its OK with me...
Its nice to see more people getting involved in x264...


Originally Posted by sasambut they said that they will try to improve more complex x264 functions from which the 2pass mode and long encodes will benefit as well so its OK with me...

So hype that instead. Don't claim quot;up to 2 dB improvement!quot; for something that only affects a few frames using certain option sets known to be suboptimal (i.e. abr).

With a movie encode for example.  The first few frames are usually black.
So am I correct in thinking that this patch would do nothing for a real encode?

However, if the experience learned here, could be used to improve an entire movie encode, that would be something to boast about.


Originally Posted by sysKinI don't want to criticize your work, but, if you don't mind, I'd like to express my criticizm on the hype you created.

Who can help with removing quot;gotoquot; from x264 code and prepare codec state accurate saving?

This work already take up serious time and we have serious problem with code.


Originally Posted by akupenguinNot short enough. The patch only matters on the first few frames.

Sure. We explaine on page - this is change in initial codec state.

We assume that not so good results of x264 in comparison with other codecs on standard sequences like flower, tennis and so on was due to this point what we find.
This is our first result of x264 improvement. It's code already optimized pretty good, so not so easy to find place, where it can be seriously improved.

Most future improvement of x264 will be in range 0.05-0.15 dB - and this will be result of a weeks of research. But only if big amount of such small improvement will be summarized - final result better than other codecs can be reached.

In this research now we collide with problems with accurate codec status (state) saving (for future returning to this state). Such feature will allow essential increasing of research efficiency.

Who also work with x264 code improvement here now?