x264 development

[Rodger]

Woa guys!

STOP IT! That´s not part of this threat!
Please return to the topic and stop personal stuff....It just won´t work out well.

[Chengbin]

Going back on topic.

Is x264 at a point where there can be no more quality improvement (except the grain feature) and only speed improvements can be done?

[Guest]

Is x264 at a point where there can be no more quality improvement (except the grain feature) and only speed improvements can be done? Of course not. Where did you get such a silly idea? Do you even know how encoders work?

[burfadel]

VAQ could be changed, depending on how the VAQ 2.0 patch is going (if its still being modified)...?

[Chengbin]

Of course not. Where did you get such a silly idea? Do you even know how encoders work?

Not exactly unforunately. I've just touched x264 lately.

I just thought that the last 200ish revisions are all either speed improvements and/or bug fixes and Dark Shikari said that he's idea bottlenecked.

Is there a link that explains how the encoder works, and hopefully help me understand more about x264 and the improvements that can be made.

[Guest]

There are lots of resources which you can easily find with Google.

Here are some areas to consider when thinking about possible evolution of x264:

motion estimation
frame type selection
macroblock coding type selection
quantization
adaptive MBAFF support
pulldown flags
VBV compliance

I am sure there are many more.

[burfadel]

A few weeks back Dark Shikari said they were working on a massive rework of CABAC (I think it was) which should give a 'large' increase in performance... wonder how thats coming along?

[Dark Shikari]

A few weeks back Dark Shikari said they were working on a massive rework of CABAC (I think it was) which should give a 'large' increase in performance... wonder how thats coming along?You mean this (http://git.videolan.org/?p=x264.git;a=commit;h=84a1ca6ce70fe7bad4922ddc5a72c2e9cd73703b)?

[burfadel]

Oops! no :) I checked back through my post and I was referring to this:

http://akuvian.org/src/x264/satd.diff

http://akuvian.org/src/x264/sea.diff

Where you wrote:
The first is the first part of an evil plan to make an obnoxiously fast SATD function. Current estimations say that we might be able to beat the current one by over 60% on Conroe Core 2. Once all the parts of the evil plan come together, they may result in the largest speed gain in a single patch in at least a year.

The second one is a prototype of an attempt to make exhaustive a little bit faster.

[Dark Shikari]

Oops! no :) I checked back through my post and I was referring to this:

http://akuvian.org/src/x264/satd.diff

http://akuvian.org/src/x264/sea.diff

Where you wrote:Talk to holger, he is the one currently in charge of the evil plan. Blame him for it taking bloody ages.

[Sagittaire]

Going back on topic.

Is x264 at a point where there can be no more quality improvement (except the grain feature) and only speed improvements can be done?

Well It will be certainely difficult to have big improvement for PSNR but HVS improvement are virtualy infinite.

[Esurnir]

Well It will be certainely difficult to have big improvement for PSNR but HVS improvement are virtualy infinite.

Talking about this (http://en.wikipedia.org/wiki/Human_Visual_System_Model) ?

[Sharktooth]

yep. HVS optimizations on digital video are ways to optimize the picture so the human eye can perceive a better picture "quality".

[Esurnir]

yep. HVS optimizations on digital video are ways to optimize the picture so the human eye can perceive a better picture "quality".

Or "It look better to me, screw the stupid metric"?

[IgorC]

I think LAME is an excellent example of long time development. It's 10 years old and there are still improvements of quality and performance.
Even old technology MPEG-2 encoder (HCenc) obtained very important HVS improvement (VAQ) in the past year.

[LoRd_MuldeR]

I think LAME is an excellent example of long time development. It's 10 years old and there are still improvements of quality and performance.

Well, if you look at the LAME history (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html) then you'll see "features and bug fixes which affect quality" and "features and bug fixes which affect speed" are pretty rare for the past two years...

[IgorC]

Settings for LAME encoders:
3.98.2 -V5 (vbr new by default)
3.97 -V5 --vbr-new
3.96 -V5 --vbr-new
3.90.3 -V5 (vbr new wasn't still recommended)

One flac album (13 files)

Results:
3.98.2 - 47.47x
3.97 - 41.3x
3.96 - 35.0x
3.90.3 - 18.3x

The quality was also imrpoved enough if you visit HA forum.

[IgorC]

Well, if you look at the LAME history (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html) then you'll see "features and bug fixes which affect quality" and "features and bug fixes which affect speed" are pretty rare for the past two years...
:rolleyes:
It's full of quality and speed omptimizations.

[Dark Shikari]

Settings for LAME encoders:
3.98.2 -V5 (vbr new by default)
3.97 -V5 --vbr-new
3.96 -V5 --vbr-new
3.90.3 -V5 (vbr new wasn't still recommended)

One flac album (13 files)

Results:
3.98.2 - 47.47x
3.97 - 41.3x
3.96 - 35.0x
3.90.3 - 18.3x

The quality was also imrpoved enough if you visit HA forum.This assumes that -V5 is always the same quality no matter what happens to the underlying code, which is rather similar to the same assumption with CRF (bad idea).

[LoRd_MuldeR]

:rolleyes:
It's full of quality and speed omptimizations.

I said "for the past two years". Well, I should have said "this year and the previous one". If you look at it carefully, only two bugs that possibly effect quality were fixed in entire 2008 ;)

The last significant changes for quality/speed were made back in Dec 2007, more than a year ago...

[IgorC]

It's different for audio encoding. Yes, it's not ideal, but for practical purpose it's more than suitable. People who used 3.96 -V5 jumped into 3.97 -V5. Maybe there some little difference 1-2 kbps but it doesn't matter for them. It actually happens on HA forum.
Maybe it will be more correct to compare 3.98 -V5.7 and 3.97 -V5 but it doesn't actually affect a lot results (+/- 1%) for speed.

[IgorC]

I said "for the past two years". And if you look at it carefully, only two bugs that may effect quality were fixed in 2008 ;)

The last significant changes for quality/speed were made back in Dec 2007, more than a year ago...
It's not improvement for you +15% speed that happens 1-2 years ago since 3.98beta?
Well, develoment of LAME is different from x264. There are no revisions but alpha/beta versions. Right now there is no "public" alpha/beta. But it will be here anytime. I don't know actually plans of LAME devs.

[LoRd_MuldeR]

It's not improvement for you +15% speed that happens 1-2 years ago since 3.98beta?
Well, develoment of LAME is different from x264. There are no revisions but alpha/beta versions. Right now there is no "public" alpha/beta. But it will be here anytime. I don't know actually plans of LAME devs.

The last change in LAME that effects speed was back in 2007. No such change in 2008 and none in 2009 so far, according to the Changelog (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html). That's what I said...

(The changelog also lists changes that have not been released yet, but again none of them is marked as "features and bug fixes which affect quality" or "features and bug fixes which affect speed")

[IgorC]

Read another changelog. A more detailed one.
http://sourceforge.net/mailarchive/forum.php?forum_name=lame-cvs
And I already said LAME IS NOT X264. There is no daily revisions. Last speed/quality changes was in 2007 (1.5 years ago) since then there were work around bugs and final version. There will be new version 3.99 alpha/beta with speed/quality optimizations.

[Sagittaire]

Well I think that audio and video are nor comparable. 3D video matrix is by far more complexe to compress. HVS is by far more complexe than human psychoaudio system.

[Esurnir]

Well I think that audio and video are nor comparable. 3D video matrix is by far more complexe to compress. HVS is by far more complexe than human psychoaudio system.

And it's not like Lame is arround since about twice as long as x264, with a spec that didn't changed a coma since 1991. While High profile is there since 2005.

[Chengbin]

x264 is at r1097 now, but when you type "x264 --version", it says r1092.

EDIT: I think it was a misprint. It says r1092, but it says built on Feb 1 2009

[kemuri-_9]

x264 is at r1097 now, but when you type "x264 --version", it says r1092.

seems to be an error on x264.nl, as all the dl links for x264 since and including r1092 are all the same revision.

[LoRd_MuldeR]

x264 is at r1097 now, but when you type "x264 --version", it says r1092.

My r1096 build tells its version properly:

C:\TEMP\x264\x264>x264.exe --version
x264 0.65.1096M 4c171c3
built on Jan 30 2009, gcc: 4.3.2

Check your build environment. The version is defined in "config.h" and updated when "./configure" is executed ;)

[burfadel]

Yep x264.nl has the wrong version information:
x264 0.66.1092 60f4cd8

built on Feb 1 2009, gcc: 3.4.6


The website states 1097.

Checking through the mirrors at the old revisions, 1097 and 1096 are the same (by comparing file size, as you would expect, 1097 doesn't affect Windows), likewise 1092 through 1095 are the same due to the revisions not affecting Windows.

Looks like its just a version numbering issue, and that it doesn't? affect the build.

[Dark Shikari]

Yep x264.nl has the wrong version:

x264 0.66.1092 60f4cd8

built on Feb 1 2009, gcc: 3.4.6


The website states 1097 however.The Wrong Version (http://meta.wikimedia.org/wiki/The_Wrong_Version)?

[burfadel]

Lol, well it looks like it is the correct build on the website, just the wrong internal numbering :)

[Gabriel_Bouvigne]

Well I think that audio and video are nor comparable. 3D video matrix is by far more complex to compress.
There is way more data to process in video, but I don't think that 3D video matrix would be more complex to compress than multichannel audio.

HVS is by far more complex than human psychoaudio system.
May I disagree? To me psychovisuals are not more complex than psychoacoustics. It's just that psychoacoustics have been widely used in lossy compression for significantly more time than psychovisuals, mainly because during the last 15 years brute force was providing enough compression benefits to not bother going the psychovisual way.

(Aren't we a bit off-topic there?)

[Raptus]

(Aren't we a bit off-topic there?)
Yes, but I find the discussion rather interesting :)

May I disagree? To me psychovisuals are not more complex than psychoacoustics.
If you are talking about the complexity or the refinement of currently implemented mechanisms to exploit psy-vis or psy-acoustic effects in lossy compression I tend to agree. But i wouldn't dare to say that the human visual system is less complex then the auditory.

Also, in the reproduction of video there are more unknown variables then with audio, which I think will add some difficulty during the further development of psy-vis schemes.

[techouse]

My build shows it correctly:
x264 --version
x264 0.66.1097M e404f35
built by techouse on Feb 2 2009, gcc: 4.3.2

[Chengbin]

Here is an idea for x264.

Can you make x264 use the GPU to decode the frames? If you're using a Bluray source, or using very fast settings, the amount of CPU decoding the frames can be significant.

[Blue_MiSfit]

x264 has nothing to do with decoding.

If you want to use your GPU for decoding, there are plenty of ways to do that - either via your software BluRay player, or through Media Player Classic HC's DXVA decoders. If you want to accelerate decoding source frames during encoding, neuron2's CUDA enabled applications are for you. Check out his website, there's a small fee involved.

~MiSfit

[burfadel]

Not to mention CUDA is Nvidia only... probably not going to be around forever since you now have OpenCL and the upcoming? Directx equivalent, both of which are compatible across all recent cards and not just a specific brand

[Esurnir]

Here is an idea for x264.

Can you make x264 use the GPU to decode the frames? If you're using a Bluray source, or using very fast settings, the amount of CPU decoding the frames can be significant.

x264 don't do any decoding at all, it's just linked to avisynth which handle the decoding or use .y4m or yuv data piped in that in the end are raw pictures, the avisynth library usage handle the .avi and .avs sources and convert them to yv12

[DiKey]

Is the "--interlaced" option working? I dont think so... Is any way to use it?
I tried to use it with top field first, with bottom fields first original file... But my Sony PS3 plays it like progressive video.
(sorry for my bad English)

[Dark Shikari]

Is the "--interlaced" option working? I dont think so... Is any way to use it?
I tried to use it with top field first, with bottom fields first original file... But my Sony PS3 plays it like progressive video.
(sorry for my bad English)You need to use the NAL-HRD patch and specify --tff explicitly.

--interlaced is a coding option, not a signaling option.

[DiKey]

Thank you. Is anywhere only NAL-HRD patched version of coder? (As i see: many patches = many bugs; one patch = more stability).

[LoRd_MuldeR]

Thank you. Is anywhere only NAL-HRD patched version of coder? (As i see: many patches = many bugs; one patch = more stability).

I'd go with that one:
http://forum.doom9.org/showpost.php?p=1255240&postcount=1701

[jult]

Is there really nobody maintaining a wiki-page with all the commands that can be used with x264.exe ? If there is one, I can't find the link for it.

Please, the world is in desperate need of a commandline reference for x264, and one that states WHICH version is compatible with it too. It's honestly getting waaaay too confusing with all the versions and patches that are out there these days.

Thanks in advance.

[DarkZell666]

Is there really nobody maintaining a wiki-page with all the commands that can be used with x264.exe ? If there is one, I can't find the link for it.

Please, the world is in desperate need of a commandline reference for x264, and one that states WHICH version is compatible with it too. It's honestly getting waaaay too confusing with all the versions and patches that are out there these days.

Thanks in advance.

What do you need that isn't in the x264.exe --long-help output ?

[video_magic]

Better than Longhelp, is a page that gives more detailed and clear explanations, and advice for someone who is new, or just trying to learn and make informed choices on which options to use and adjustment of the settings.

I have found this page helpful:
http://mewiki.project357.com/wiki/X264_Settings

[DarkZell666]

Better than Longhelp, is a page that gives more detailed and clear explanations, and advice for someone who is new, or just trying to learn and make informed choices on which options to use and adjustment of the settings.

I have found this page helpful:
http://mewiki.project357.com/wiki/X264_Settings

True, the default help isn't very enlightening for a beginner.
However, a command-line reference and a user-friendly wiki isn't exactly the same thing ... :p (hence my question ;)).

[jult]

Well, I also found that mewiki page before, but it doesn't have all settings included, and the settings aren't in any clear logical order.

What annoys me a little is the fact that its writers assume we will read it all, even when we're looking for just that one parameter. Nobody I know has the time to read the entire longhelp before he/she starts using it. Just not a very realistic assumption (or request, even). Also, searching inside a cmd.exe window isn't exactly easy.

It now seems there is a 'somewhat supported' XP x64 version of x264.exe, but when I tried using it, it seems to not work with .avs files the same way, or maybe that's caused by Avisynth not being x64. It gets so tiring when its documentation is not structured or organised in a logical way.

[burfadel]

Why not someone set up a definitive page, then just add the line at the end of the help in x264 'refer to (web address) for etc ...

[nm]

Well, I also found that mewiki page before, but it doesn't have all settings included, and the settings aren't in any clear logical order.
The order in mewiki is the same as in x264 --longhelp. It also looks pretty logical to me and the section titles help users locate options that they are interested in. Are there some specific improvements or ideas that you have on your mind?

What annoys me a little is the fact that its writers assume we will read it all, even when we're looking for just that one parameter. Nobody I know has the time to read the entire longhelp before he/she starts using it. Just not a very realistic assumption (or request, even). Also, searching inside a cmd.exe window isn't exactly easy.
The writers assume that people who use the command-line interface have a decent set of tools to view and search such listings: grep and less for instance. If you don't have them, just direct the output to a file and open it in some text editor.

It now seems there is a 'somewhat supported' XP x64 version of x264.exe, but when I tried using it, it seems to not work with .avs files the same way, or maybe that's caused by Avisynth not being x64. It gets so tiring when its documentation is not structured or organised in a logical way.
I don't think any amount of documentation on the command-line parameters would help with this issue. What you need is general understanding on how x86-64 and a mixed 32/64-bit environment works. As you thought, the problem is that 64-bit x264 can't communicate directly with 32-bit AviSynth. So, get a 64-bit AviSynth build (http://members.optusnet.com.au/squid_80/) or use Avs2YUV to pipe from a 32-bit AviSynth process to x264 (this may be difficult if you aren't familiar with command-line interfaces and shell scripts).