x264: is another breakthrough expected?

[ArtDen]

Quality of video coded by h.264 codec is much better then video coded by mpeg4 codecs. Standart h.264 was breakthrough in video compression some years ago.
As I know x264 supports many of the h.264 features but not all of them. Do x264 developers plan to include one or more of h264 features which greatly increase video quality (in comparison with current x264)? Is it possible there will be another breakthrough for x264 users?

--
Sorry for my english :)

[Manao]

The major features of the standard that are lacking in x264 are :
- proper interlacing handling : PAFF/MBAFF. It improves things only when encoding interlaced stuff, i.e mostly sports.
- explicit weighting prediction support : it will improve things only in fades, which don't happen that often ( except in trailers :p )
- FGM, aka film grain support, which allows to keep the noise/grain/whatever without using insane bitrates.

Of the three, imho, only the last one is important for DVD ripp, though you can already emulate it by adding noise with ffdshow / mplayer.

[iwod]

If i remember correctly there are a few areas where X264 can still improve on in terms of its implementation compare to other encoder like Ateme.

I think it should provide slight improvement. But i dont think it can be called a breakthrough.

Personally i would like to see a breakthrough in the decoder department. Something that is open source and compare well with CoreAVC.

[PuzZLeR]

Personally i would like to see a breakthrough in the decoder department. Something that is open source and compare well with CoreAVC.

I would only want to see a good decoder emerge if it's some sort of standard - that is, a decoding rhythm that would be very similar on many platforms to avoid a variance of playback results.

And we can't expect that from x264. They are only responsible for encoding (unless they improve upon stuff like VideoLAN).

Otherwise, although good decoding apps are very nice, I would personally like to see video play great without any "gimmicks" or enhancements, even at the cost of a slightly higher bitrate for that. This is the best way you can be sure that you have a guaranteed minimum level of quality should you play this video in another environment that may have a completely different set of decoders.

A good decoder should be a bonus, not a necessity (where it's badly needed as with Xvid and DivX).

Anyway, it's only opinion. But I would rather have a healthy head of hair than trading it in for a better looking wig.

[akupenguin]

I would only want to see a good decoder emerge if it's some sort of standard
You mean, besides the H.264 standard?

that is, a decoding rhythm that would be very similar on many platforms to avoid a variance of playback results.
What's a decoding rhythm?
And the only major codecs that *aren't* identical on lots of platforms are the commercial win32-only codecs (or I suppose Apple's mac-only codecs).

And we can't expect that from x264. They are only responsible for encoding (unless they improve upon stuff like VideoLAN).
That's just semantics. I'm also responsible for parts of libavcodec's H.264 decoder.

Otherwise, although good decoding apps are very nice, I would personally like to see video play great without any "gimmicks" or enhancements, even at the cost of a slightly higher bitrate for that.
Who said anything about gimmicks? The measure of goodness in a decoder is speed and compatibility, nothing else.

A good decoder should be a bonus, not a necessity (where it's badly needed as with Xvid and DivX).
You'd rather have an encoder without a good decoder? What use are videos you can't play?

[plane]

The major features of the standard that are lacking in x264 are :
- proper interlacing handling : PAFF/MBAFF. It improves things only when encoding interlaced stuff, i.e mostly sports.
- explicit weighting prediction support : it will improve things only in fades, which don't happen that often ( except in trailers :p )
- FGM, aka film grain support, which allows to keep the noise/grain/whatever without using insane bitrates.

Of the three, imho, only the last one is important for DVD ripp, though you can already emulate it by adding noise with ffdshow / mplayer.

http://forum.doom9.org/showpost.php?p=824743&postcount=84

According to Sharktooth in his old post, there are still some interesting parts which X264 lack of.

[giandrea]

The major features of the standard that are lacking in x264 are :
- proper interlacing handling : PAFF/MBAFF. It improves things only when encoding interlaced stuff, i.e mostly sports.
- explicit weighting prediction support : it will improve things only in fades, which don't happen that often ( except in trailers :p )
- FGM, aka film grain support, which allows to keep the noise/grain/whatever without using insane bitrates.

Of the three, imho, only the last one is important for DVD ripp, though you can already emulate it by adding noise with ffdshow / mplayer.

In my opinion the most needed is number two. Am I the only one noticing big banding problems especially with noisy source. When I ripped Reservoir Dogs at CRF 18, in some scenes the banding was embarrassing, and I used both no-fast-pskip and no-dct-decimate. Don't know...

[PuzZLeR]

You mean, besides the H.264 standard?


What's a decoding rhythm?
And the only major codecs that *aren't* identical on lots of platforms are the commercial win32-only codecs (or I suppose Apple's mac-only codecs).


That's just semantics. I'm also responsible for parts of libavcodec's H.264 decoder.


Who said anything about gimmicks? The measure of goodness in a decoder is speed and compatibility, nothing else.


You'd rather have an encoder without a good decoder? What use are videos you can't play?

Hey akupenguin. First of all thank you for x264, a wonderful breakthrough, even as status quo.

I was making comments based on my experience with DivX and Xvid. Both were wonderful in their day, even now, but I noticed that they relied heavily on post processing and deblocking, etc. to have any decent quality at the lower bitrates.

This I feel was somewhat of a mask, because the "real" video without those "masks" seemed very blocky and unwatchable.

This is all fine and dandy if it's part of the ability to playback the video, but I found a huge discrepancy among many devices and players with it.

Yes, we all need a decoder with good speed and wide compatibility, but I don't want my video to rely on what decoder is available wherever it plays for a certain level of quality.

To give an example, I find alot of my DivX and Xvid videos looked horrible on my stand-alones, because the chipsets included have a different decoding "rhythm" (which was only my way of saying its method of playback). The point is that they looked so GOOD on my PC, but I was disapointed in the results elsewhere. This is what I mean by a "standard" of some sort - a minimum level "worst case scenario" type of quality.

This is what I get from VideoLAN. I disable "post processing" to determine how bad the video can be at its worst - it's my benchmark. This way I'm certain that any deblocking, smoothing, filtering in playback will be a bonus.

And even now with H.264, I never delete the source until I'm certain its worst possible situation is acceptable. I would need much higher bitrates for DivX/Xvid or have to rely on decoder "gimmicks" for this.

And yes, I do consider smoothing, deblocking, etc that is done in playback somewhat gimmicky and non-standard when it's not done on all decoders the same way. This is especially true when dealing with hardware ROM chips that can't be adjusted to your liking.

Yes, a good decoder that makes average video look awesome is a wonderful thing, whether x264 or anybody else brings it to us, but that does not guarantee that it will look this good with another decoder elsewhere.

I hope I was a little bit more clear this time. It was just opinion and I begrudge no one else's. Thanks for reading. And keep up the great work with x264. I absolutely adore it.

[*.mp4 guy]

In my opinion the most needed is number two. Am I the only one noticing big banding problems especially with noisy source. When I ripped Reservoir Dogs at CRF 18, in some scenes the banding was embarrassing, and I used both no-fast-pskip and no-dct-decimate. Don't know...
You aren't the only one noticing banding problems, but most people don't really care about banding, it seems. X264 also has a problem with flickering blocks in static areas (may have been fixed, I'm a bit behind, but probably hasn't been). Hopefully some of the issues that have persisted for a long time will be addressed when all of the functionality the devs are interested in has been implemented.

[Manao]

giandrea : Weighted prediction shouldn't help on noisy source. It's really made to handle fades and possibly flickering on old movies. Noise remains noise, ie something not predictable.

[akupenguin]

@PuzZLeR
In that case you should like H.264, since the deblocking is part of the standard. There is no "worst possible scenario", there is only one scenario: all H.264 decoders are required to output exactly the same pixels.

[BetaBoy]

akupenguin gets quote of the week...

There is no "worst possible scenario", there is only one scenario: all H.264 decoders are required to output exactly the same pixels.

[giandrea]

giandrea : Weighted prediction shouldn't help on noisy source. It's really made to handle fades and possibly flickering on old movies. Noise remains noise, ie something not predictable.

You are right, I've read "it will improve things only in fades" , as "it will improve things only in shades" :p don't know why... :eek: Anyway the banding problem is there and is very noticeable. Would it be possible to tweak the settings to alleviate the problem?

[fofwp]

You aren't the only one noticing banding problems, but most people don't really care about banding, it seems. X264 also has a problem with flickering blocks in static areas (may have been fixed, I'm a bit behind, but probably hasn't been). Hopefully some of the issues that have persisted for a long time will be addressed when all of the functionality the devs are interested in has been implemented.

I have noticed both of these problems (banding and flickering blocks on static images) and they are the main problems of x264 in my opinion.

Once these problems can be solved I am confident it will be the best open-source encoder out there.

[Mangix]

Once these problems can be solved I am confident it will be the best open-source encoder out there.it's the only Open Source encoder out there...

[*.mp4 guy]

So Xvid, Lavc, and Theora (amoung many others) don't count becuase...?

[burfadel]

So Xvid, Lavc, and Theora (amoung many others) don't count becuase...?

They're different inferior formats!

[Manao]

.mp4 guy : they are talking of h264.

burfadel : beware of absolute on this forum. Search a little, you'll see that "x264 > xvid" becomes a complicated matter when doing high bitrates.

Mangix : no, it's not the only open source encoder. Lavc is having one, there's one or two forks of x264 out there. There's the JM ( open source - not GPL, slow as hell, unusable, but still ). And I'm sure the sticky contains other open source encoder I can't remember just now.

[virus]

Once upon a time, there used to be the myth of a new way of doing trellis (and eventually more than just trellis) by taking into account the dependencies among subsequent frames, as a mean to break the limits both in output quality and slow encoding times - it basically would require a framework for solving multi-million-variables linear optimization problems while encoding.

The less young among you might also recall the name: LookAhead(TM).

Sadly, details about its implementation within x264 seem to have been lost in the fog, but if you ask the old farts over at #x264 in a night of full moon, you'll still see their eyes shine while whispering that young researchers were claiming up to 1 dB PSNR of improvement for it, and how they think the CIA was involved in suppressing the evidence that LookAhead(TM) ever existed, in fear that the technological breakthrough could have favored terrorists or something like that.

But remember: don't tell about it, or your friends will never see you again...

* walks away in the night, disappearing in the fog *

[PuzZLeR]

@akupenguin:

Yes, I very much notice that deblocking in H.264 is much more a part of the encoder process, than the decoding process later (in comparison to DivX/Xvid).

In other words, I feel it much more "standard" with AVC, and as a result I notice much less of a playback variance among several decoders. :-)

@BetaBoy:
It may seem a bit funny, but seriously, there tends to be quite a difference in how DivX/Xvid pixels can look among different decoders. (At least from my eyes.)

I guess I'm just in the belief that a decoder shouldn't have to do most of what the encoder is supposed to have done beforehand (such as deblocking). From an argumentative point of view, this can contribute to better compatibility and speed when designing a decoder.

[akupenguin]

<stealth ninja CIA mode> LookAhead(TM) never existed. </stealth ninja CIA mode>
More seriously, it's still theory. I never implemented enough of it to know whether it would really work, nor to determine how full of vapor the researchers were.

[burfadel]

.mp4 guy : they are talking of h264.

burfadel : beware of absolute on this forum. Search a little, you'll see that "x264 > xvid" becomes a complicated matter when doing high bitrates.

Mangix : no, it's not the only open source encoder. Lavc is having one, there's one or two forks of x264 out there. There's the JM ( open source - not GPL, slow as hell, unusable, but still ). And I'm sure the sticky contains other open source encoder I can't remember just now.

High bitrates is all what the new generation of 'DVD' players is about (whether it ends up being HD or blu-ray). So you're saying they should implement xvid like many current players can play instead of using h.264?!:confused:

[garumphul]

I think the work on x264 so far is nothing short of amazing, and the developers should be thanked and praised at every opportunity. I'd love to be able to contribute to development myself, but the all highly-optimized maths involved is totally beyond me. Sorry :)

It would be interesting to know if the devs have any kind of roadmap for the future. Obviously it's open source, so anybody can do what they like, but I wonder if there are any priorities for the next big iteration. For example, what would be the target criteria for a Beta release?

Personally, I think the most promising "next big step" will be offloading some operations to a GPU. I don't know how much work is already ongoing in that direction, but I'm pretty sure *somebody* will be looking at it. Unfortunately, that gets us into problems with requiring specific graphics cards and drivers and all that kind of thing, and I would imagine a huge leap in complexity of the code.

Tweaking for higher bitrates will come eventually, but I can see how there are other more important things to be tackled first. I'm always hugely impressed at how x264 performs at low bitrates, but I don't think I'm the only one who has been vaguely disappointed that the same wow-factor is missing at the high end. It would be a shame for x264 to be overlooked by 'the community' simply because it has relatively (and I stress *relatively*) poor HiDef quality.

It'll all come through, though, I'm sure. As long as everybody here keeps testing and suggesting and not hassling... they'll get it as close perfect as it can be.

[smok3]

It would be a shame for x264 to be overlooked by 'the community' simply because it has relatively (and I stress *relatively*) poor HiDef quality.
and where did you get that from?

[burfadel]

and where did you get that from?

Oh and before when I was comparing h.264 with xvid I was comparing the standard, not the encoder! There is no doubt that the h.264 is superior to Xvid, its just implementing the codec...

[akupenguin]

For example, what would be the target criteria for a Beta release?
x264 isn't pre-alpha, it isn't alpha, it isn't beta, and it isn't 1.0. it's version 648. I don't do releases or "big iterations". I just do features.

Oh and before when I was comparing h.264 with xvid I was comparing the standard, not the encoder!
Then say "h.264" and "mpeg4 asp". xvid is an implementation, not a standard.

[check]

and where did you get that from?
from a large thread already ongoing, and I certainly don't want any of it to spread into here :)

On LookAhead. Is this some in joke, or was there an actual product called this related to video encoding? I've looked, but a cursory google search has showed up nothing related (just a lot of unrelated stuff). Could someone provide me with a link or hit me with a joke stick? ;)

[akupenguin]

You won't find LookAhead in a google search because the original paper didn't give it a name. "LookAhead(TM)" is what we of #x264dev call it.
And if it ever is implemented in x264, the option name will be something else again, because LookAhead is only the optimization algorithm (like RDO), not the application of that algorithm to a specific part of a codec. (I would have said the same of trellis, but xvid and lavc already used the unqualified word "trellis" to mean "trellis RD quantization".)

Brad Schumitsch, Heiko Schwarz, and Thomas Wiegand. Optimization of Transform Coefficient Selection and Motion Vector Estimation Considering Inter-Picture Dependencies in Hybrid Video Coding. (http://www.stanford.edu/~bschumit/Schumitsch_SPIE_05.pdf) SPIE, Image and Video Communication and Procession, 2005.

[virus]

x264 isn't pre-alpha, it isn't alpha, it isn't beta, and it isn't 1.0. it's version 648. I don't do releases or "big iterations". I just do features.

If I knew something about the core library, I'd have volunteered for maintaining a stable branch (or more branches) long time ago. I've been using branches a lot in SVN - they're so easy to handle - and I'm also learning server-side repo maintenaince for it, but unfortunately I know absolutely nothing about the guts of libx264 so I'm kinda busted.

The current numbering scheme is ok for me, but the problem is that without proper release cycles, x264 often gets less and wrong consideration from distro makers - though that also applies to those bundling x264 with Win32 software.

Less because they usually update packages for releases, and are afraid of trying unreleased code which might break or even fail to build (this often happens: the fact that this might not happen to x264 is not relevant, because a team who manages thousands of packages just cannot keep track of pro, cons and stability of every single package - they just leave this work to the developers via the alpha/beta/rc/stable status of their releases). The net result is that x264 gets updated less frequently than other packages.

Wrong because, when prompted to "please update x264 which is 100+ revisions old", they just pick HEAD without a clue. Maybe you just committed the big change which broke a few things along the way, and that build will perhaps be distributed in its half-broken state till next update - which might be months away, perhaps in the next iteration of the distro.
This is because x264 isn't signalling these basic infos to everybody out there in a way that Average Joe can keep track of.

API compatibility would be also another very good reason to do branched development, but not one I'm currently very much bothered with.

The real problem with x264 is that it's fun for the programmer who just freely adds features, but quite a lot less for those who distribute the code out there. Not to mention that old saying "just pick the latest revision, it's DA BEST" which will just hurt the unexperienced user who just wanted the version which didn't crash on him and didn't output funny green blocks, even if 0.3% slower or 13 KB larger.

Unlike most of the software out there, x264 does nothing to protect its users from this mess, and that's definitely something that should be improved.

[ArtDen]

...I don't do releases or "big iterations". I just do features.

Which feature will be next?

[burfadel]

Which feature will be next?

Well we got MMX, MMXEXT, SSE, SSE2 and SSSE3, but SSE3 is missed! maybe some SSE3 code where it can be useful?... or more SSSE3 code?...

I realise its much easier to ask for it! but I can imagine there would be no comparison for a fully optimised build! If only there were more people that are able to contribute, through knowledge and time...! and those that are contributing are doing a great job! Before someone tells me off, no I don't have any programming knowledge, if I did I'd help!

[akupenguin]

Nope, SSE3 is lame. SSE3 should have been the one named "supplemental", and SSSE3 should have got it's own number.

[burfadel]

Nope, SSE3 is lame. SSE3 should have been the one named "supplemental", and SSSE3 should have got it's own number.

Ah ok! Maybe we should call SSSE3 Super SSE3 instead of Supplemental! Intel probably could have included all the instructions from SSE4 with the Core 2's, but holding off the extra instructions would just for marketing!

I'm not saying thats the case, but it certainly wouldn't surprise me! :)

[R3Z]

akupenguin - what are the chances of getting something like the divx "film grain" effect for post processing added to x264 (namely an option during encoding and an option during decoding via libavcodec's) ?

Not sure if exisiting code like that of addgrain could be used or not. Cheers for your time :)

[LoRd_MuldeR]

akupenguin - what are the chances of getting something like the divx "film grain" effect for post processing added to x264 (namely an option during encoding and an option during decoding via libavcodec's) ?

Not sure if exisiting code like that of addgrain could be used or not. Cheers for your time :)

There is a feature called "FGM" (aka Filmgrain Support) in the H.264 standard, but it's not implemented in x264 yet. So it definitely should possible, but it's obviously not done yet. It will be the decision of the developers to do it or not...

[MetalPhreak]

@R3Z
It's already there. ffdshow has a option for "Noise", will require some tweaking to get a look that you like.

[R3Z]

@R3Z
It's already there. ffdshow has a option for "Noise", will require some tweaking to get a look that you like.

Yeah i am definately aware of ffdshow and its noise parameters, but thats not really the question.

[burfadel]

Yeah i am definately aware of ffdshow and its noise parameters, but thats not really the question.

Do you mean a signal from the encoded file to the decoder to automatically apply a certain amount of noise? I can't imagine you mean noise hard-coded, as that would mean less efficient encoding.

[LoRd_MuldeR]

Do you mean a signal from the encoded file to the decoder to automatically apply a certain amount of noise? I can't imagine you mean noise hard-coded, as that would mean less efficient encoding.

Well, as far as I understand H.264 has a 'special' feature to keep film grain without having it hard-coded in the stream. At least not in the classical way. I guess it works more like adding some 'extra' information to the video, so the decoder knows how much grain is to be added after decoding. Nevertheless this feature is NOT implemented in x264. So using MPlayer's or ffdshow's noise filter should do the same. It only needs to be configured by hand...

[akupenguin]

Yes, but divx doesn't have FGM either. ffdshow's noise filter is like divx's, which was the question.

[PuzZLeR]

AFAIK, even though it's very much a standard feature, none of the well-known implementations of H.264/AVC support FGM...yet (if any). As well, DivX never supported it either without it being a part of decoding (as akupenguin pointed out).

Yes, you can make ffdshow do it nicely, but I think it would be a breakthrough for this feature to be included in the x264 encoding process beforehand.

IMHO, theoretically speaking, the effectiveness of a good encoder is in-directly proportional to the amount of post processing features necessary in any of its decoders.