When will x264 mature?

[anne_so78]

On Videolan's x264 page is this warning:
"BIG FAT WARNING: x264 is still in early development stage"

Is that warning outdated or is x264 still in an early development stage? If it is, when can we expect to see "mature" x264 builds?

[futurex]

i think x264 will be developed for a very long time, so i guess it is still in early development stage. but it's certainly not unstable if that's what you mean.

[anne_so78]

Hmmm, what exactly is that warning for? What are we supposed to be cautious about?

[Adub]

Not really. Almost all of the new builds coming out from sharktooth and others are incredibly stable. I wouldn't lose any sleep over the warning.

[Caroliano]

Sometimes there are buggy builds, normaly becose an typo in the pach for example. But these are quickly solved. I consider x264 as the best public avaliable codec in the world right now! Even with few blocking problems and features to implement. It is certainly usable w/o too much problems.

[slavickas]

if you really paranoid about that message etc just use few revisions older builds

[Revgen]

When it grows up.

[unmei]

i guess it will take about as long for that warning to vanish as it took XviD to reach "1.0" :)

[Oline 61]

x264 is pretty mature IMHO. The builds are usually quite stable, it supports the majority of MPEG4 AVC features, and has no trouble creating standard compliant streams.

[berrinam]

x264 is pretty mature IMHO. The builds are usually quite stable, it supports the majority of MPEG4 AVC features, and has no trouble creating standard compliant streams.
That's exactly why it isn't mature: it is mostly quite reliable, but not enough to guarantee it and get a whole lot of complaints if it stuffs up.

[zambelli]

x264 is pretty mature IMHO. The builds are usually quite stable, it supports the majority of MPEG4 AVC features, and has no trouble creating standard compliant streams.
I would expect a codec would have to support all AVC feature before it's considered mature.

For starters... Interlaced support. You can't really be considered a serious contender without that.

[Manao]

I would expect a codec would have to support all AVC feature before it's considered matureI disagree. Who would need a codec that supports FMO ? ASO ? You say interlacing is lacking, but the purpose of x264 is to encode videos that will be played back on a PC, hence on a progressive display. In that context, interlacing support doesn't lack, since keeping the video interlaced before encoding would be a mistake.

[zambelli]

In that context, interlacing support doesn't lack, since keeping the video interlaced before encoding would be a mistake.
Who says x264 targets PC playback only? Interlaced encoding is a crucial part of any modern encoder. Would you accept HC or TMPGEnc as good MPEG-2 encoders if they didn't support interlaced encoding?

[Manao]

XviD doesn't support properly interlacing ( only DCT field/frame, no field motion compensation ), yet it is considered a good mpeg4 encoder.

Anyway, the warning was there since the beginning, and I guess won't be removed while people are working on it. So I guess it's actually a good sign, since it means the project still lives ( XviD kinda died of a slow death since 1.0... )

[akupenguin]

Who says x264 targets PC playback only? Interlaced encoding is a crucial part of any modern encoder.
I say x264 targets PC playback. Or digital TV, since they're finally catching up to the fidelity that has long been possible on PCs.
Interlacing is a crucial workaround for the physical constraints of 50 year old analogue TVs, and can only interfere with anything modern.

To the original topic: I have explicitly avoided assigning version numbers, because I don't want to make the judgement call that this patch is important and that one is stable and so on.
Furthermore, I'll predict that no codec will ever implement all combinations of features allowed by the h264 standard, unless you're writing it specifically to be complex rather than useful. (And no, the reference encoder doesn't support everything either).

[futurex]

I say x264 targets PC playback.
Interlacing is a crucial workaround for the physical constraints of 50 year old analogue TVs, and can only interfere with anything modern.

damn straight. death to interlacing

[Redmist]

damn straight. death to interlacing
Yes, as long as it's not replaced completely by slower progressive frame rates like 30fps (or PAL25). Watching sport for example at 30fps seriously blows compared to 60i even though they use the same bandwidth.

[Manao]

Watching sport for example at 30fps seriously blows compared to 60iTrueeven though they use the same bandwidth.Not correct. We're digital & compressed nowadays. And 60i is quite more complicated to encode than 30p, especially when motion is important ( hence when 60fps are really needed ). In the end, for sports and such, i'd say that : bitrate(60i) ~ ( 2 * bitrate(60p) + bitrate(30p) ) / 3 ( that is, bitrate needed for 60i is closer to the bitrate needed for 60p than for 30p, when there's lots of motion ).

And the big drawback is that, when the video is interlaced, it has been harmed in such a way that you won't, ever, be able to make progressive again ( that is, without artifacts ). While, if it's progressive, you can interlace it.

[Redmist]

Yeah, you're correct there. My main point is that even 60 interlaced fields per second is better than 30 progressive frames for a lot of material. Obviously, the ideal is 60 progressive frames. Hopefully all sports broadcasts in the future will be at least 1280x720x60p.

[bond]

i think whats important to answer this question are two things:
1) is the codec compliant to the standard?
2) is the performance (quality/speed) useable?

yes to both points imho

[zambelli]

damn straight. death to interlacing
I couldn't agree more, but the reality is that TV continues to be interlaced (480i, 576i and 1080i) and DV is still interlaced. The advantage of encoding interlaced and then deinterlacing after decoding is that you can take advantage of better deinterlacers as technology improves. If you deinterlace prior to encoding - you're stuck with whatever result you get from your deinterlacer.

[berrinam]

you're stuck with whatever result you get from your deinterlacer.which may be superior because it needn't be done in realtime.

If you want to wait for superior tools to come, you might as well save in lossless so that you can always do everything again. Just as that costs more in disk space, so does encoding interlaced.

[zambelli]

which may be superior because it needn't be done in realtime.
If you want to wait for superior tools to come, you might as well save in lossless so that you can always do everything again. Just as that costs more in disk space, so does encoding interlaced.
It all depends on the encoding context and target. For most common applications, deinterlacing and encoding as progressive is fine. However, if you're tryng to achieve quality transparency, preserving the interlaced nature of the source is crucial. Deinterlacing to the same framerate will destroy both spatial and temporal information, so it's not a good solution for any professional application. Your options are then either to encode as interlaced, or to bob deinterlace to a double framerate. Either way - it's going to come at greater cost.

[Audionut]

Tv's as in crt's continue to be interlaced. But any new display device afaik is progressive.

<Insert berrinam's post here.>

However, if you're tryng to achieve quality transparency

Use lossless encoding.:D

[zambelli]

Use lossless encoding.:D
Don't plan to be authoring any HD-DVD/BluRay discs using H.264, are you?

[Audionut]

Ok.

Name 1 display device that will show hi-def interlaced content in all it's interlaced glory.

Now name 1 hi-def display device that will bob deinterlace to a double framerate.

[foxyshadis]

It really doesn't take that much more to encode the full 60p. Maybe 20-30% more in my old tests, or a slight reduction in quality if you're maxed already. Of course decoding is harder, but once you add the need for a kernel deinterlacer you have a net win and less artifacts. (Bobbing isn't deinterlacing, it's just halving the resolution.)

[Wilbert]

(Bobbing isn't deinterlacing, it's just halving the resolution.)
1) I guess that depends on how you define deinterlacing. If you define it as getting rid of any combing, then bobbing is deinterlacing.

2) What do you mean by "it halves the resolution"? Is any detail being thrown away?

[foxyshadis]

Each 60i field is upsized into 60p, right? And almost every playback filter out there does it with either point sampling (halving the effective resolution and inducing jitter) or bilinear, only ffdshow gives you a choice. Well, the latter isn't so ugly, it's what avisynth Bob() gives. But they all induce jitter/shimmering when there's little movement, even eedi2, because they're only working off each half-resolution field. (Combining a good bob in motion and using both fields in static areas is best. It's how securedeint and tdeint work.)

[GodofaGap]

Bobbing does not half the resolution, each field is half resolution to begin with. How the missing lines are interpolated (motion adaptive, resized, or whatever) is just a matter of choice. You can only speak of halving the resolution if resolution is thrown away. It's normally not the case with bobbing.

[zambelli]

Bobbing does not half the resolution, each field is half resolution to begin with. How the missing lines are interpolated (motion adaptive, resized, or whatever) is just a matter of choice. You can only speak of halving the resolution if resolution is thrown away. It's normally not the case with bobbing.
I agree. You should theoretically be able to restore the original interlaced sequence from a bobbed progressive video because every other line should be the same as in the original video (the rest are interpolated).

[Chainmax]

I disagree. Who would need a codec that supports FMO ? ASO ? You say interlacing is lacking, but the purpose of x264 is to encode videos that will be played back on a PC, hence on a progressive display. In that context, interlacing support doesn't lack, since keeping the video interlaced before encoding would be a mistake.

No it isn't. Keeping the video interlaced conserves motion fluidity, and you can always use ffdshow do (bob)deinterlace the video on playback.

[Oline 61]

No it isn't. Keeping the video interlaced conserves motion fluidity, adn you can always use ffdshow do (bob)deinterlace the video on playback.
If you are going to deinterlace on playback, you would be better off deinterlacing before encoding.

[futurex]

too much cpu load deinterlacing AVC real-time

[popper]

I say x264 targets PC playback. Or digital TV, since they're finally catching up to the fidelity that has long been possible on PCs.
Interlacing is a crucial workaround for the physical constraints of 50 year old analogue TVs, and can only interfere with anything modern.

To the original topic: I have explicitly avoided assigning version numbers, because I don't want to make the judgement call that this patch is important and that one is stable and so on.
Furthermore, I'll predict that no codec will ever implement all combinations of features allowed by the h264 standard, unless you're writing it specifically to be complex rather than useful. (And no, the reference encoder doesn't support everything either).

regarding being 'useful' and your point that its primary target is the x86/PPC PC, would the fact that many people are expecting to play back SD/HD content on their 'HD ready' labeled widescreens now, or in the near future, with the BBC World cup from their DVB connected PC's to HD TV sets.

do you think that these HD ready TVs and the commercial broadcasters such as the UK BBC that do interlaced SD/HD broadcasting only and not the progessive display (and indeed does any commercial progresive content exist today or in the near future?) will effect the x264 developers thoughts collectively on the HD interlaced content de/encoders creation for the near future?.

correct me please if im wrong, but doesnt many open source decoders use the x264 base code for their main foundation ?
and hence cant currently play back the BBC HD content as its useing MBAFF never mind get to 25fps ?. is that collectively a problem, with so many people (perhaps 1000s+) wanting a usable open sw decoder to see the world cup in its UK free to air forms of DVB T/S/C, and indeed it may become the standard in the uk and EU , so perhaps people will want to also encode to that HD standard too?

im just asking you understand, and thank you for your work so far and that includes the many other great developers working to give us the WC in HD etc.

[Manao]

correct me please if im wrong, but doesnt many open source decoders use the x264 base code for their main foundation ?x264 is only an encoder. The main open source decoder, lavc, though partly written by x264 devs, doesn't share any of its source code.

[popper]

Tv's as in crt's continue to be interlaced. But any new display device afaik is progressive.

<Insert berrinam's post here.>



Use lossless encoding.:D

but dont all the so called HD ready TV's only come in upto 1080i
and not 1080P today and for the short/mid term future only?, iv not seen anyone talking about 1080P for any BBC HD trials for instance?, or for the EU for that matter.

[Morte66]

but dont all the so called HD ready TV's only come in upto 1080i
and not 1080P today and for the short/mid term future only?, iv not seen anyone talking about 1080P for any BBC HD trials for instance?, or for the EU for that matter.

AFAICT, we are unlikely to see any TV delivered as 1080p in meaningful quantity/timeframe, in either Europe or America. HDDVD and Blu-Ray seem to be the main potential sources of 1080p over the next few years.

Me, I just watch discs on my PC (1920*1200 monitor). I don't have a TV set or any means of TV reception. So I'm interested in 1080p.

[zambelli]

I think what's likely to change the whole attitude towards interlaced support are HD-DVD and BD discs. People will eventually want to author high def DVDs. DV cams are still 480i, and many consumer HD cams are 1080i. If it's interlaced, it's preferable to keep it interlaced when authoring high quality discs.

[popper]

x264 is only an encoder. The main open source decoder, lavc, though partly written by x264 devs, doesn't share any of its source code.

thank you manao, it gets a little confusing when the thread
talks about x264 and both decoding and encoding.

i begin to understand that if anything, its the other way around after just now reading the ' mbaff decoding in libavcodec is here' thread started yesturday
http://forum.doom9.org/showthread.php?t=111620

its interesting that Bond said this in his announcment there
"pengvado has written a patch for adding mbaff decoding to libavcodec, thanks a lot

http://students.washington.edu/loren...4_mbaff.0.diff

seeing the bbc using mbaff in their hdtv channel it might be that we will see mbaff interlacing more often in the future?

enjoy"

so he too, thinks it may become the standard.

i cant find the link right now( to many things on the go), but it appears 1440x1080 is in use now and someone on the digitalspy thread mentioned the bbc and itv/C4/five probably
were moving over to the full size as soon as they get the latest kit, perhap Nick [D]vB can remember and fill that bit in?.

[Chainmax]

If you are going to deinterlace on playback, you would be better off deinterlacing before encoding.

I don't agree with you because:

...
The advantage of encoding interlaced and then deinterlacing after decoding is that you can take advantage of better deinterlacers as technology improves. If you deinterlace prior to encoding - you're stuck with whatever result you get from your deinterlacer.

and

...
if you're tryng to achieve quality transparency, preserving the interlaced nature of the source is crucial. Deinterlacing to the same framerate will destroy both spatial and temporal information
...

[Oline 61]

What advances do you expect from future deinterlacers? The output of TomsMoComp or Tdeint is often perfect on my computer. The size and playback complexity savings are worth it for me. Also, the playback deinterlacing is done in realtime, and thus cannot do a more advanced analysis in less-than-realtime like you can with an avisynth pre-encode deinterlacer. The output from a good avisynth deinterlacer will be more transparent than that of an interlaced encode that is deinterlaced on playback.