Log in

View Full Version : H.264 features (and why they're not used?)


Chengbin
20th August 2009, 03:59
I just had a read from Wikipedia (I know) of the software encoder feature comparison. It seems like multiple features of H.264 are not supported by any encoder. Why? I know some features are not useful, like flexible macroblock order.

One thing that caught my eye is, x264 does not fully support baseline profile? What is x264 missing?

What is x264 missing for full support of high profile?

BTW, is there any feature that's not supported by x264 worth adding, or are they there to add if you're insanely bored?

Sagekilla
20th August 2009, 06:15
I believe the error resilience features, namely FMO like you mentioned.

I'm not completely sure as to what's included in baseline, but I remember reading that FMO was one of the features required for baseline when you're doing things like video conferencing.

Dark Shikari
20th August 2009, 06:20
Practically everything that is in Baseline or Extended but not in Main is a complete and utter waste of time that nobody has ever used in any real application.

benwaggoner
20th August 2009, 06:26
Practically everything that is in Baseline or Extended but not in Main is a complete and utter waste of time that nobody has ever used in any real application.
Has anything ever used Extendend?

It's been listed but grayed out in QuickTime's H.264 export dialog for more than four years now. I wonder what Apple was thinking about there...

LoRd_MuldeR
20th August 2009, 12:29
One thing that caught my eye is, x264 does not fully support baseline profile? What is x264 missing?

What is x264 missing for full support of high profile?

Chengbin, I think you see it from the wrong direction. It's not like the encoder has to implement all features of a certain profile to "support" that profile. If an encoder wants to create a stream that complies with a certain profile, it must limit itself to using only features that are allowed in the target profile. But the encoder isn't required to use all of the features that this profile would allow in theory. The stream is still fully compliant to the profile, even if some allowed (but useless) features weren't used by the encoder. It's decoders that must implement all features of a profile to fully "support" that profile...

It's been listed but grayed out in QuickTime's H.264 export dialog for more than four years now. I wonder what Apple was thinking about there...

More important: I wonder what was the reason for the Joint Video Team to include that in the standard ???

benwaggoner
20th August 2009, 17:49
More important: I wonder what was the reason for the Joint Video Team to include that in the standard ???
It's got a lot of bitstream-level robustness stuff IIRC, enabling it to reconstruct a reasonably good stream with a whole lot of packet loss.

Of course, system layer forward error correction can address much of the same need, and seems to be the approach most things are taking.

cacepi
21st August 2009, 00:00
BTW, is there any feature that's not supported by x264 worth adding, or are they there to add if you're insanely bored?
Apart from 10-bit and 4:2:2 color, mb-level QP might be neat to have. I have no idea how much it would help compression, but, hey, it couldn't hurt, could it?

Dark Shikari
21st August 2009, 00:09
Apart from 10-bit and 4:2:2 color, mb-level QP might be neat to have.Yeah, it'd be really nice if we had something like that. (http://git.videolan.org/?p=x264.git;a=commit;h=dc4f40ce74c996a1e15021b82ab71ebcb8652d0b) We could even give it a catchy name, too. (http://git.videolan.org/?p=x264.git;a=commit;h=bb66c482242a0747823661b212114c1a2f015fe3) In fact, we could even RD-optimize it. (http://git.videolan.org/?p=x264.git;a=commit;h=7733721e410acb96fdf740ca95d2a394b2a2b713)

cacepi
21st August 2009, 00:31
Yeah, it'd be really nice if we had something like that.
I guess you didn't (http://tech.slashdot.org/article.pl?sid=09/05/07/2352203) get the joke (http://forum.doom9.org/showthread.php?p=1307968&highlight=adaptive+quantization#post1307968), then.

Chengbin
21st August 2009, 01:31
I guess you didn't (http://tech.slashdot.org/article.pl?sid=09/05/07/2352203) get the joke (http://forum.doom9.org/showthread.php?p=1307968&highlight=adaptive+quantization#post1307968), then.

They probably used Apple's Quicktime encoder.

There is no way Theora can beat x264 in PSNR.

Dark Shikari
21st August 2009, 01:37
They probably used Apple's Quicktime encoder.

There is no way Theora can beat x264 in PSNR.Actually, it seems you missed his supposed "joke" as well.

(For reference, Xiph "accidentally" screwed up the PSNR measurement in that test, resulting in x264's measured quality dropping by about 5-6db. They, of course, never retracted the results afterwards, being the honest people they are.)