H.264 status and definition

[ToiletDuck]

I was reading through some of the threads to find out more about this codec however most of the discussions were either A: by a group of people that already knew what they were talking about, or B: People who didnt seem to know anything. I would be in the later group but after reading the threads I still don't fully understand.
After looking around I am gathering that H.264 or H.26L as it was once called is a new form of codec that will allow MPEG 1/2 to be encoded up to 1/4 it's original size without loss of quality? I'm a little shaddy there. Also from what I'm gathering is that it is completely unstable and very slow? I would like to know who came up with the idea for this codec and what potential it has. Also I looked at the moonlight clips and wasn't impressed at all. If that is what the codec has to ofer I'd rather stick with xvid and RV10. Seemed like A) Blockiness everywhere, B) Choppy, and C)The color of the clips was completely off. Skin looked red and greens and blues faded out. Any comments?

[Tommy Carrot]

H.264 is the successor of the current mpeg4 standard, and otherwise known as mpeg4 AVC profile. It's technically superior, so theoretically it would bring the same quality at significantly smaller bitrate (30-50% less), but the current implementations are far from perfect (to say the least), they are very slow, unoptimized and untuned.

[ToiletDuck]

so is this being developed on a volunteer developer level like Keopi and xvid or is it more or less being pushed by the media industry?

[Tommy Carrot]

Xvid is a bad example, it's an implementation of mpeg4 advanced simple profile, so it's not a private experiment either. The same is the case with H.264: it's an industry standard, but anyone can make an implementation of it (but unfortunately noone did that so far...).

[bond]

h.264 (officially called AVC (Advanced Video Coding) in MPEG-4) is not the successor of MPEG-4, its part of it!

h.264 is not 1 codec, its an open codec standard
the difference is that other formats, like RV9/10, VP6, WMV9 are closed formats, meaning only one firm releases only 1 codec and this firm has pretty much all rights on this codec
an open standard is as the name says a standard, which everyone can follow it when creating a h.264 codec, which means there are many different h.264 codecs (there is for example also an opensource h.264 project running, but has been very quiet lately)

the big advantage of an open standard is that it leads to a strong competition, which means the codec developers always have to look to offer high quality otherwise people will simply use another h.264 codec, what is very good for us, the customers

back to MPEG-4:
more or less you can say the MPEG-4 standard defines two video encoding standards:
1) MPEG-4 part2: which we all now as DivX5, XviD, 3ivx aso...
2) MPEG-4 part10 (also called AVC|h.264), which is a superiour coding technology than "normal" mpeg-4

the h.264 technology is pretty new and therefore only a few h.264 codecs exist, which are not really tuned and very slow and dont offer the maximum quality they could (simply imagine how divx5 and xvid performed some years ago)

[temporance]

Originally posted by Tommy Carrot
H.264 is the successor of the current mpeg4 standard, and otherwise known as mpeg4 AVC profile. It's technically superior, so theoretically it would bring the same quality at significantly smaller bitrate (30-50% less), but the current implementations are far from perfect (to say the least), they are very slow, unoptimized and untuned.

I wouldn't say the current optimizations are untuned. Slow and unoptimized yes, but they are pretty well tuned, having the same type of RD opts as xvid's VHQ mode. I'm talking about the JVT encoder which is what most people have used to benchmark the standard.

Personally, I expect this standard to require in the region of 0-30% less bitrate than regular MPEG-4 (DivX or xvid). In other words, for some clips, there will be no advantage, but for others there might be a noticeable quality improvement at the same bitrate. This improvement will come at the cost of increased encoding times and high decoder CPU load (esp. at resolutions > 320x240).

Industry is very excited about this codec: IMHO it will not trounce MPEG-2 and MPEG-4 in the way that people expect it to.

[MfA]

Partly for PR reasons and partly because they will use it in the MPEG-4 container format MPEG has declared it as part of MPEG-4, but the text of the standard shares diddly squat with the old MPEG-4 visual standard. As far as the coding goes it is a defacto successor.

Please, credit where credit's due ... let's keep calling H.264 by that name :)

[P0l1m0rph1c]

Originally posted by Tommy Carrot
Xvid is a bad example, it's an implementation of mpeg4 advanced simple profile, so it's not a private experiment either. The same is the case with H.264: it's an industry standard, but anyone can make an implementation of it (but unfortunately noone did that so far...).

Ever heard of the x264 project?

[bond]

there are two opensource h.264 projects (next to the reference sources) available already:

fenrir's x264 (http://lyra.via.ecp.fr/) (as P0l1m0rph1c wrote)
hdot264 (http://sourceforge.net/projects/hdot264/) by charact3r (does anyone know if openhdot264 is closely related to hdot264 or more a different project?)

skal (http://skal.planet-d.net/coding/mpeg4codec.html) is also working on a h.264 encoder, but hasnt released any sources till now

[Tommy Carrot]

Originally posted by P0l1m0rph1c
Ever heard of the x264 project?
No. (http://forum.doom9.org/showthread.php?s=&postid=430128#post430128) :D

Seriously, it has the illness of all h.264 projects: it's very sporadically developed, inactive, i just don't have too much faith in it. And i cannot compile anything usable from it!! :devil:

[thegeby]

The European broadcasters in EBU seem to be rather miffed by the proposed MPEG-4 AVC/H.264 licencing deal. EBU Press release (http://www.ebu.ch/tech_texts/tech_text_d96-2003.pdf)
Their point is that the terms do not fit channels that broadcast to a narrow audience but that cover a large footprint. This may be an early salvo in a negotiation strategy, but is a pity anyway as there has been clear interest on the technical side to use this codec in DVB high definition broadcasts.

EBU tech people seems to prefer 720p as a future standard claiming that it can display standard signals better than interlaced HD. If Europe wants to avoid wasting bandwidth US style, this means one of the "new" codecs: H.264, WMV9, RV"X", VP6, DIVX. Could be interesting....

[bill_baroud]

i compiled ffmpeg some days ago (to have a new lib for ffdshow :whistle: )

and noticed a nice "h264" in the list of output format .... what does it mean ??
i didn't test it, but there is an h264 encoder in ffmpeg ?

[d'Oursse]

according to the doc, ffmpeg decode h264, but did not encode (see TODO in the doc directory, for example)

[el divx]

skal (http://skal.planet-d.net/coding/mpeg4codec.html) is also working on a h.264 encoder, but hasnt released any sources till now [/B]

Can then smeone from this forum/thread compile a version usable in vfw programms such as VD? Sources and documentation are available in skal's (http://skal.planet-d.net/coding/mpeg4codec.html) website. I'd do it myself, but I don't know anything about progrmming:o

[MfA]

I didnt even know about the 2010 thing ... personally I cant see anyone investing in H.264 with that kind of hostage situation looming. I foresee it languishing in the same patent limbo as MPEG-4 did if they cannot get agreements from all parties on a usefull license. If they dont m$ or on2 could have a field day if they play their cards right.

Glad to see the EBU agrees with me on interlacing at least :)

[el divx]

Shouldn't then the developers in this forum help people like fenrir and skal evolve what they already have started?!? I think that we just have to develop an h.264 codec that will create mpeg-4 avc(h.264)-compliant content without using reference code so that those jackoffs at M.P.E.G. won't be able to argue about using their patented code and develop it while they will still be trying to figure out the license to put on h.264.

[MfA]

That is not how patents work.

If Skal wanted help Im sure he would have asked for it ... hell, he never said he would open source it even.

[shlezman]

http://www.dvdforum.org/25scmtg-resolution.htm

"Provisional approval of MPEG2, WM9 (VC-9) and MPEG4 AVC(H.264) Video CODECs as mandatory for the HD DVD Video specification for playback devices, subject to (a) an update in 60 days regarding licensing terms and conditions, (b) a presentation by each of the respective licensing bodies at the next SC meeting and (c) possible elimination of any of the above CODECs at the next SC meeting. "

It seems that the DVD-Forum has chosen (for the moment) WM9 and H.264 as mandatory codecs for the upcomming HD DVD format.
Very strange decision, considering how much $ the customers will have to play for royalties and that over-compatibility .I womder how much time it will take for the industry to fully support all these formats (except MPEG2).

[MfA]

AFAIK there isnt even a single licensing body for H.264 at the moment, both vialicensing and the mpegla have their own licensing pool.

[justin]

okie, for status of the open source implementations:

skal is already finished his H264 codec. He is not sure if it will be made open source because there are other companies interested in using it commercially. It may become open source, but he's not sure yet

Hdot264 is not currently not being worked on at this moment and Fenrir's x264 is being worked on by him and I am trying to join in and help him with his codec

[MfA]

He should sell it and try to get a job out of it :)

I only know of one other guy who said he did an independent implementation in his own time, Wei Dai ... and he now works for FastVDO, which very recently started to promote their new H.264 codec with a remarkably simular description to the one Wei Dai had.

[Tommy Carrot]

Originally posted by justin

skal is already finished his H.264 codec.


Are you sure about this? I've heard nothing about it.

If he doesn't want to open the source, could he still release it in executable form, or he doesn't want to do that because of the license issues?

[el divx]

Why then can't he just mark it "for educational purposes only" like the XviD developers did with XviD? That way he wouldn't have any problems with mpeg licensing fees or anything, won't he?

[Joe Fenton]

Also: I've read the draft specs of the newcoming H264 standard (aka AVC. aka JVT. aka MPEG4 Part-10, even). It's fun and very challenging! And with very efficient coding properties. I'm currently writing a codec for it... It almost reached Baseline and Main Profile. Stay tuned.

That is all that is on Skal's web page. Any reports of an actual codec are just rumors based on this statement.

[MfA]

Joe some people might have you know ... talked to him.

el divx, yes he can ... but noone here suggested he could not release because of patents, apart from you. So this is getting a bit circular.

[SeeMoreDigital]

Has anybody else noticed that when you have Moonlights player and MainConcepts encoder (with decoder player filters) installed, the two of them don't get on!

For some reason MainConcept does not like Moonlights mpeg2dmx.ax filter... but I'm at a loss as to why an Mpeg2 filter is required in the first place.

I thought H.264 feet were firmly rooted in the Mpeg4 camp!

Cheers

[Tommy Carrot]

If i interpreted it correctly, x264 finally got VFW interface, so it can be used as a normal codec. Would someone be so kind to share with us a build from it? (I hope asking this is allowed here. :))

EDIT: Request cancelled. :p

[RadicalEd]

The last few ffdshows have had it :|

[Tommy Carrot]

Yep, but i cannot open the H.264 videos in Vdub with ffdshow. I hope using directly this codec would solve this problem.

[RadicalEd]

Originally posted by Tommy Carrot
Yep, but i cannot open the H.264 videos in Vdub with ffdshow.

?:|
Why not?

[Tommy Carrot]

Originally posted by RadicalEd
?:|
Why not?

See this (http://forum.doom9.org/showthread.php?s=&threadid=75841) thread.

[RadicalEd]

Hmm, strange. You're sure you changed the fourcc to H264 and enabled it in the VFW configuration's decoding>codecs tab?

[Tommy Carrot]

Damn, you're right, that works. I wasn't aware i have to manually enable the support for the requested codec in the VFW section too. Thanks man!

[justin]

I made a quick compile of x264, link (http://www.geocities.com/justinclaybaby/x264.htm)

no working configuration panel for the encoder, no easy to use installer or directshow decoder yet, but you can use Vanguard Software's free h264 decoder (http://www.videosoftinc.com/decoders.html) to decode it though, and just change the fourcc code of the ouput avi to vssh with abcAVI tag editor (http://www.divx-digest.com/software/abcavitags_editor.html) and you should be able to view the output

Still have to code in the dialogs, whoever those authors are, they're wierd people :p

[bond]

nice that you are working on h.264, but still i have the question why you support vfw? its outdated technology which doesnt even handle b-frames right...

[SeeMoreDigital]

Originally posted by justin
I made a quick compile of x264, link (http://www.geocities.com/justinclaybaby/x264.htm) "I cannie get the link to work... Captain Kirk"

[Tommy Carrot]

Originally posted by bond
why you support vfw? its outdated technology which doesnt even handle b-frames right...


What's the alternative? It's the only widely used API for encoding (except quicktime, but that doesn't count). The b-bframe handling is long time solved, not a real problem imo. The only real handicap is the missing VFR ability, but for most of us it's not important at all.

Someone (perhaps Avery himself?) said Dshow is not exactly suitable for editing, and i'm strongly against the native MP4 streams since the total lack of support, so only VFW left.

(I'm not not a developer, just my 2 cents :))

[Tommy Carrot]

Originally posted by justin
I made a quick compile of x264, link (http://www.geocities.com/justinclaybaby/x264.htm)

no working configuration panel for the encoder, no easy to use installer or directshow decoder yet, but you can use Vanguard Software's free h264 decoder (http://www.videosoftinc.com/decoders.html) to decode it though, and just change the fourcc code of the ouput avi to vssh with abcAVI tag editor (http://www.divx-digest.com/software/abcavitags_editor.html) and you should be able to view the output

Still have to code in the dialogs, whoever those authors are, they're wierd people :p

Thanks. My quick impressions: It's almost twice slower than the 2 weeks old x264 version inside the ffdshow encoder, but the quality is better. The quantizer scale is mixed up, quant 1 should be the best quality, 51 should be the worst. Oh, and it would be great if disabling the loop-filter would be possible in the future builds (but i guess this is why the advanced button is there :)).

[bond]

Originally posted by Tommy Carrot
What's the alternative? It's the only widely used API for encoding (except quicktime, but that doesn't count). The b-bframe handling is long time solved, not a real problem imo.not totally correct, there is a workaround avialable in virtualdub(mod) which makes b-frames work with vfw (in divx5 and xvid), but other vfw apps will not offer this workaround
therefore other companies like m$, offering a vfw version of wmv9, dont allow b-frames in their vfw codec, b-frames are only available in their wmencoder
(not to speak of that the avi container itself isnt able to handle b-frames without hacks, not to speak of other h.264 specific things, like markers)

an alternative would be a dshow encoder or even better a commandline encoder (dont understand whats wrong with this, real uses it for rv9 and it would not be that windows-centric as vfw and dshow)

but yes there definitely is the need for a better interface (hope gstreamer, or at least dshow, will become something widely usable in the future)

The only real handicap is the missing VFR ability, but for most of us it's not important at all.well simply not knowing it, or never having tested it doesnt mean that its not important ;)

Someone (perhaps Avery himself?) said Dshow is not exactly suitable for editingthe 3ivx guys say the contrary and from what avery wrote he had some very specific problems which made him drop the idea of implementing dshow, not altogether not solvable ones

and i'm strongly against the native MP4 streams since the total lack of support, so only VFW left.what is a native mp4 stream and what does it have to do with vfw?

[Tommy Carrot]

Originally posted by bond
not totally correct, there is a workaround avialable in virtualdub(mod) which makes b-frames work with vfw (in divx5 and xvid), but other vfw apps will not offer this workaround
therefore other companies like m$, offering a vfw version of wmv9, dont allow b-frames in their vfw codec, b-frames are only available in their wmencoder
(not to speak of that the avi container itself isnt able to handle b-frames without hacks, not to speak of other h.264 specific things, like markers)
Look, i didn't say the current solution is perfect, or elegant, but works without issues. And afaik those workarounds are not necessary for packed bitstreams anymore.
but yes there definitely is the need for a better interface (hope gstreamer, or at least dshow, will become something widely usable in the future)

Ok, i agree, but those are not really available right now, afaik no encoder app supports them.
what is a native mp4 stream and what does it have to do with vfw?
I mentioned that only because you always propagate using MP4 container for Mpeg4 codecs, and i had to express my disagreement. :p

[bond]

Originally posted by Tommy Carrot
Look, i didn't say the current solution is perfect, or elegant, but works without issues. And afaik those workarounds are not necessary for packed bitstreams anymore.hm not sure if packed bitstream avoids delay frames
still i doubt that the x264 vfw encoder writes packed bitstreams

I mentioned that only because you always propagate using MP4 container for Mpeg4 codecs, and i had to express my disagreement. :p hrhr
ok still vfw and mp4 dont exclude each other, you could also encode with a vfw encoder directly into mp4 (if there would exist a tool which could combine the two :D )

[SeeMoreDigital]

Originally posted by Tommy Carrot
...I mentioned that only because you always propagate using MP4 container for Mpeg4 codecs, and i had to express my disagreement. :p Your disagreement is duly noted!

Tommy, please list your grievances with the container?


Cheers

[Tommy Carrot]

Originally posted by bond
hm not sure if packed bitstream avoids delay frames
still i doubt that the x264 vfw encoder writes packed bitstreams

I though packed bitstream is exactly for avoiding delay. X264 doesn't have b-frames so far, but Videosoft's H.264 has, and it uses packed bitstream.

[Tommy Carrot]

Originally posted by SeeMoreDigital
Your disagreement is duly noted!

Tommy, please list your grievances with the container?


Not with the container, i know its superiority, but with the support for it. Until i have to use complicated methods to mux into it, and editing is impossible, i cannot see any point to use it.

[bond]

Originally posted by Tommy Carrot
I though packed bitstream is exactly for avoiding delay.hm i talked about an issue of vfw during encoding, not during decoding:
when encoding vfw uses always a 1 frame in, 1 frame out sheme, now with b-frames it gets 1 frame input but cant output 1 frame, therefore it outputs a so called "delay frame" (as it has to output something), which breaks the mpeg-4 compliance (yeah its nice ;) )
virtualdub(mod) automatically offers a workaround for this problem and detects these frames and drops them during encoding, but i doubt any other tool using vfw codecs will do this too, its a workaround nowhere specified...
vfw is simply outdated technology, not smart enough to handle b-frames on its own

X264 doesn't have b-frames so farhm according to fenrirs site b-frames are already "partially supported", whatever this means :D

but Videosoft's H.264 has, and it uses packed bitstream.where did you read this?

[Tommy Carrot]

Originally posted by bond
where did you read this?

I didn't read, i've tried. :D Packed bitstream has a peculiar characteristic in the virtualdub encoding status window which is easy to recognize: The frames in the places of b-frames are empty (dropped frames).

[Tommy Carrot]

I don't know if anyone cares, but here comes my opinions about the x264 in the latest ffdshow.

Well, the encoding speed improved a lot, more than 2x faster than the previous version, i can get about 8-12 fps on 720xXXX material, even using CABAC coder doesn't really slowing it down. The quality is improved as well, the motions are less annoying (though still not perfect), and the detail-preservation is also improved (in this regard it's already _much_ better than Xvid or any other mpeg4 codec).

Another thing: considering that this build and Justin's separated x264 build are using almost exactly the same codebase, the encoding-speed difference is huge, this is almost 5 times faster.

[ToiletDuck]

I care :cool: So let me get this strait. The new x264 codec has the same quality as xvid does now? The one i downloaded clips for a while back, while on its way, did not look so good.
Duck

[Tommy Carrot]

I would say that in certain aspects it's much better, in others it's worse. For example at the same bitrate x264 has much more details, the image is sharper (with disabled loop-filter, of course), etc. But... x264 has jumping blocks, the motion is not fluent, xvid is certainly more pleasing to the eye due to its much better ME algorithm. X264 is simply not mature yet, it still has some issues, but it also shows that H.264 has much bigger potential than mpeg4 ASP codecs.

[ToiletDuck]

Sweet. That is good to hear. I wish the jumpyness was taken care of. Any idea how long it will be till we see a usefull codec?
Duck