The H.264/AVC/MPEG4 discussion thread

[Quarkboy]

Originally Posted by TheFluff

@Eeknay: That's interesting, but... no CABAC and no inloop deblocking? Ugh. 5.1 LC-AAC at that bitrate isn't likely to sound very nice, either... XviD+AC3 is probably a better alternative for quality with those limitations...

Xbox ~= Pentium III 800 Mhz system or so... so to playback h.264 CABAC and deblocking needs to be turned off to ensure real time playback. That's where those settings come from.

As to your second point, I really don't know of any comparisons between h.264 no cabac no deblocking at lowish bitrates and xvid... The quality might not be too different, depending on the source.

[TheFluff]

Originally Posted by Quarkboy

Xbox ~= Pentium III 800 Mhz system or so... so to playback h.264 CABAC and deblocking needs to be turned off to ensure real time playback. That's where those settings come from.

Of course I know why they're there, I was just commenting on the fact that the restrictions probably make H264 much less superior to a good MPEG4 ASP codec than it usually is with all HQ features enabled. Making special encodes for Xbox when you can just download XviD encodes with similiar quality and much less hassle seems a bit unnecessary, even if you might have to sacriface some bandwidth...

[Zero1]

Unfortunately I missed replying to this thread before it got locked, and since I intend to post here anyway, I might as well catch up. I think it is still somewhat relevant.

Originally Posted by NoSanninWa

While that is an excellent thread, it is intended for a discussion of h264 which goes well beyond the simple question that is asked by this thread. If you actually want to discuss h264 in detail, please do so there, but I'm going to leave this thread intact to explain the matters to newbies who aren't up to the technical demands of reading that other thread.

Originally Posted by NoSanninWa

This thread's gone well beyond answering the original question. It isn't a place for encoders to chat with each other about h264, nor an XboX video help thread. This thread was intended to explain a specific question to absolute newbies. Even if it had stayed on topic, the conversation isn't at the newbie level any more.

Hate to say I told you so, but I knew it would go in that direction :p (hence my suggesting we keep it in the H.264 thread to save the forum from another thread). Unfortunately it "went" in that direction, because it's encoders that were explaining to the newbies why the encoders are switching, and as things do, they kind of verge off topic since one topic can easily relate to another.

Originally Posted by TougeSil80

Compared to Xvid, how much more efficient is the h.264 codec, and what's the minimal hardware that can run it smoothly? Thanks.

It's almost impossible to specify since it depends on the complexity of the video you are coding. It also depends on how much spatial and temporal redundancy there is. Realistic figures seem to be 10-30%. CABAC itself (the entropy coder) is said to be ~10% more efficient than CAVLC, and CAVLC is more efficient than Huffman (the entropy coding used in MPEG-2 & MPEG-4 Visual). So it's feasible to expect around 10% reduction, or there about when using CABAC in H.264, before you even touch the more advanced motion estimation and prediction features.
As for minimal hardware, this is also hard to specify, since H.264 encodes can vary in complexity in more ways than one (for example number of reference frames, number of B-frames, bitrate, entropy coding method). I won't commit myself, but I will say that my old Duron 750MHz (overclocked to 900MHz ;)) is able to play something like 640x480 H.264 with 5 reference frames (possibly more, haven't tested). An easier way to gauge is that using CoreAVC as the decoder, decoding H.264 requires approximately the same CPU power as decoding an ASP encode with XviD itself (as we found out in this thread earlier (or was it the old one?), and reminded by RaistlinMajere's signature).

Originally Posted by wingdarkness

@Rondo, the honest truth is some people don't like the $hit (or the change) as much as others and would rather convert it then have to change the comfort-level of their codec packages or circumvent in some other way to watch their favorite shows...

No, it's not as simple as "people don't like the $hit"; a few legitimate reasons for wanting to transcode H.264 releases to ASP (i.e. DivX or XviD) would be that their computer is too slow to play H.264. Actually, that's not even completely legitimate anymore considering the awesome efficiency of CoreAVC, and the ever decreasing price of computer parts (new parts are released, so old parts become cheap, whereas these old parts that are becoming cheap are sufficient to play H.264). But I do sympathise with younger leechers that are perhaps still in school, college or university and don't have an income, or a very good one. The other reason might be that they have a hardware player, a so called "DivX player", it's obvious why you would want to transcode to DivX or XviD if you have a DivX player, isn't it?

As for your obsession for film grain (which is only a decoder effect, which isn't obligated to be there), H.264 apparently has a feature called FGT (Film Grain Technology, how original(!)). In laymens terms, it sounds as though it does a similar job with video, as HE-AAC does with audio. It cuts the high frequencies (high pitch sound in music, sharp edges/fine lines in video), and reconstructs them on playback. Whilst I'm not a big fan of HE-AAC (it's too destructive to be used for HQ audio IMO, but for low bitrates it's awesome), the actual reconstruction is pretty good, although I did find the midrange was somewhat lacking. Maybe that is a problem of the particular encoder I used.
Anyway, check it out here: http://www.lge.com/products/supermul...iew.jsp?id=102

Originally Posted by wingdarkness

Yes I do like DivX and the subsequent Film Effect, but i do acknowledge that on lower-sized really crappy looking fansubs h264 can be a bonus, but for DVD-rips and higher-sized fansubs with already good quality I find it to be marginal at best and not worth the problems that exists with certain encodes...Everyone's entitled to their veiw though...

Since you are too ignorant to realise the truth, I'll tell you. Lower sized does not automatically equate to lower quality, there are many factors. H.264 is more efficient than MPEG-4 Visual (XviD/DivX), meaning that you can obtain the same or similar quality at a lower filesize (which means it's the same or equivalent (not uncommonly better quality also) quality than the DivX version even though it's smaller), or higher quality at the same filesize. Quality has absolutely nothing to do with the DivX film filter; when you are comparing quality you need look at both videos using the same media player, and same or equivalent decoder settings (meaning post processing must be off). In effect you need to see the "raw" image, not some processed image that is laden with artificial grain, or smoothed by post processing filters. Then you compare which is least blocky and retains the most detail. There are other things to note, but these are the main ones. You must also check 2 encodes that are made from the same source; it's no good checking one group's H.264 encode and a different group's DivX/XviD encode. For starters there's the possibility that they used different raws, different filters (i.e. filtering more will cause loss of detail) or might even be using lame or suboptimal encoder settings. The quality can vary hugely before you even get down to encoding.

By the way, I think that what you say isn't really a view, it's just huge bias.

Originally Posted by wingdarkness

I really am happy that alot of the places I go have chosen to make 2 versions because they understand that alot of their fanbase perfers a DivX version aswell...

I doubt multiple versions will be around for long. History shows that after a while, everyone eventually migrates. As much as I like to see progress, I'd also like to see people continuing using and developing XviD. H.264 is awesome and all, but ASP is a nice accompaniment. Also remember that MPEG-4 Visual is capable of more than just rectangular video (though it's mostly not implemented since everyone just wants regular video coding ;_:); scope wise it can do a lot more than H.264, but H.264 was designed solely as an incredibly efficient "natural" video coding standard.

I really wish to see XviD and x264 co-exist for a long time, rather than a huge switch to x264 and seeing XviD being forgotten. Remember that with the efficiency that H.264 has, it has higher decoding requirements. This is not suitable for portable devices like mobile phones. The PSP and/or iPod would benefit also, lower CPU usage means longer battery life. There is still a market for XviD (well, MPEG-4 ASP in general).

Originally Posted by NoSanninWa

CPUs of 1.0 GHz are fine. If your system is less than that you have a chance of running into trouble, though the specifics of exactly how much power seem to vary by user. Some people claim that their 900 MHz system can't handle it, while I've heard another claim that he can run almost all h264 encodes on his 400 MHZ system.

That was probably me, but I've had trouble underclocking to 400MHz for a while, 600MHz is the best I can do these days. Anyway, you shouldn't take that literally as "Someone claims their PC @ 400MHz can decode H.264" I ran some tests while underclocked to see what the lowest CPU speed I could play it back at was, and did an arithmetic benchmark on the CPU to see what other CPU's would rate similarly (which should take into account cache etc, not sure about instruction sets, but I guess it does). This was decoded with FFDShow, and as the graph suggests, 800MHz Duron is theoretically borderline; which seems about right considering I've played videos on my "real" Duron750 @ 900MHz. Apparently though, we cannot trust Windows task manager for CPU usage, but this should at least have provided some kind of guesstimate.

In fact, I dug through the archive and found the image:
http://img81.imageshack.us/my.php?image=untitled2gr.jpg

Originally Posted by NoSanninWa

Unfortunately that post was lost in the forum hack and I don't remember who it was off-hand, but there are obviously a few possibilities for how this feat was managed:

* Decent RAM
* Better video card than your brother has
* He removed all unessential programs from start up
* He was lying about it

The solution might be one or more of the above

Well even if it wasn't me, for reference that was done when I had a Radeon 9800, and 512 or 1024 MB RAM (I don't recall)

Originally Posted by LytHka

Problem with x264 codec is that it disappoints. You had encoders going "oh, we'll keep the current quality and lower filesize." This is not the case by many groups. They just like to keep the same filesize for "better" quality. But let's be honest: only an incompetent encoder can't keep TV-rip quality on the same level in a similar manner with xvid as he is doing now with x264. TV rips really aren't that great, so of course nobody notices the difference.

This is a kind of hit and miss statement. I agree that H.264 should be used to lower the filesize, while maintaining equivalent or better quality. As for incompetence (or maybe just gross impatience...), it certainly exists. I cringe at the thought of people switching to x264 "just because" or cutting corners with x264 in order to speed it up. If you aren't prepared to wait for quality, then you are using the wrong encoder right now. Go back to XviD, which although less efficient than x264 (due to it being a different standard) has a much more desirable quality/speed ratio. If you are going to use more relaxed settings than x264's defaults, you might as well go back to XviD, else you will be switching to a newer format which will no doubt isolate a few people, for no amazing gains. If you are going to cut off some people, might as well go all out and do the best job you can so at least the benefit is felt somewhere down the line.

What I didn't agree with was the comment that x264 disappoints. For the first time in ages, I have been more than pleased with the encodes I can turn out, or rather the improvement over a same sized encode using XviD, or achieving the same or better quality at a lower size. I think you will find it's the encoders using x264 which is disappointing you. I guess you meant that, obviously, but the first line wasn't very clear.

Originally Posted by monstert

Quick question, x264=h.264?

EDIT: Oh, ok, thanks SSS. That article's cleared up some confusion I've had.

Seeing as TheFluff did a fine job of describing H.264 and MPEG-4 Visual, (just how I would have explained it, bar referencing to the ISO number :D) I will just give a quick explanation.

H.264 is the name of a video coding standard, it is also called AVC (Advanced Video Coding) because it was a joint standard between MPEG and ITU. ITU call it H.264 (which is consistent with the naming of convention of previous standards like H.261, H.262, H.263), and MPEG call it AVC (Advanced Video Coding), which I believe is a clever gimmick seeing as their audio standard is called AAC (Advanced Audio Coding). The leading open source encoder is called x264 (see www.x264.nl for information).

MPEG-4 Visual is the name of an older, well known video coding standard. It may also be referred to as MPEG-4 SP (Simple Profile) or MPEG-4 ASP (Advanced Simple Profile), since the main use of MPEG-4 Visual is for natural rectangular video, despite it having such tools for animation, object based coding etc. The MPEG-4 Visual has a wider scope in general, but H.264 only concentrates on natural video coding, and is much more complex and detailed than the video coding in MPEG-4 Visual. The leading open source encoder is called XviD, there is also a popular commercial alternative called DivX (names I know you will be familiar with), but why pay more for less? (when you can get higher quality, and for free) ;) Both DivX and XviD support MPEG-4 ASP (and SP also since ASP contains all of SP's features).

So there you go; H.264 is a video coding standard, and an opensource encoder for this is called x264. MPEG-4 Visual (or MPEG-4 SP or MPEG-4 ASP) is a video coding standard, and an opensource encoder for this called XviD.

Originally Posted by TheFluff

but for h264 stuff, "h264" is usually used no matter what encoder was used to create the file (of course, some people use "x264" anyway, increasing the confusion).

Agreed, we will come to this later...

Originally Posted by LytHka

I used "x264" because nobody uses anything else than x264 to encode. "XviD" works well, "x264" works well. Both are codecs. Nobody cares what ISO standard somebody/something uses/implements. It's information, a lot of useless information, especially to the leecher (like you said). So I'd rethink who's causing the confusion now...

EDIT: To the stupid person quoting me, my point was that it doesn't matter.

Well, where to start. Calling H.264 encodes by their encoder name (in one case, x264) is already starting to confuse people. What does it matter if you encode a H.264 video with x264, Ateme, Elecard, Quicktime or Mainconcept? Do you expect people to label their encodes as such? The syntax of the bitstream should be the same, and thus interoperable with compliant H.264 decoders. A H.264 bitstream is a H.264 bitstream is a H.264 bitstream... (Unless you use VfW which requires hacks). The whole idea of MPEG and what they do is to give some kind of "open" industry standard, rather than us being ruled by the likes of Real and Microsoft with their proprietary codecs and containers.

How about if people start labelling their MP3's or the audio in their fansubs as LAME or Fraunhofer, or Nero, iTunes, Winamp, 3GP reference or FAAC for AAC? That would cause a bunch of confusion, since Mainconcept and Ateme produce other encoders also (MPEG-2 and MPEG-4 Visual). The fact is that while the encoders might vary in quality and features, they all output the same compliant streams that are playable through capable, compliant decoders, be it hardware or software.

Then you get hardware. Since MPEG-4 ASP has effectively been partitioned as DivX and XviD, almost implying that they are different codecs, or somehow incompatible, you get "DivX" players, not MPEG-4 ASP players, but "DivX" players. You might say, "hang on, what about the incompatibilities I've seen", well that's a combination of people using AVI and VfW, and DivX disregarding the specs somewhat, and creating their own unofficial profiles. One of these was due to DivX's half assed GMC decoding implementation which only used to support 1 warp point, if you know XviD, you may know it uses 3. I believe (though I might be wrong) that a compliant decoder should support all the features of a selected profile, that would mean that the DivX decoders and players would be able to decode up to 6 warp point GMC (the maximum available). In other words, if a decoder claims to be an ASP decoder, it should support ALL of the features of ASP fully, and not partially implemented.

Again, this goes back to DivX's name and disregard for the specs.

Players that are not obligated to decode XviD encodes, because they are made to DivX Networks specifications. That means they are only guaranteed to decode DivX encodes (which means that there is only partial implementation of ASP decoding features). If it was a MPEG-4 ASP player, it would have to play any compliant MPEG-4 ASP stream, meaning that there should be no issue of compatibility between DivX and XviD encodes, barring the fact that they use hacks for VfW compatibility. That would mean (if DivX, XviD and libavcodec decoders follow the spec) that you could use any ASP feature you wanted without worry, be it GMC, QPEL or B-frames. It's an excuse for opensource, since they are only people doing it in their free time, but a company should do things properly, especially when they expect people to pay for their products.

In my opinion, since DivX3.11a, the knock on effect of MPEG-4 in AVI has been damaging. Given that DivX 3.11a was a hack, it didn't do or require anything particularly undesirable specs (AVI/VfW) wise (as opposed to ASP which uses B-frames and requiring hacks). Maybe SBC's/Nandub's Low/Fast motion DLL switching was a bit naughty, I don't know, it was before my time :p.

Why do I think DivX3.11a had a damaging knock on effect? Well basically (I guess) people was labelling the encodes as DivX, or DivX SBC to differentiate from MSMPEG4 (which I believe is a non standard simple profile implementation). Then comes natural progression, DivX (several versions later) eventually moved to ASP (which means B-frames, yay!). So as not to upset their userbase, they thought it wise to stick with AVI and just develop a hack called packed bitstream, which basically packs P and B frames together so two frames get forced through and read at once, since VfW has a one frame in, one frame out limitation (you need multiple frames to decode B-frames).

Even later on down the line, we see the .divx format, which is nothing more than AVI with even more hacks. These hacks are even more evil though in my opinion. Yes, I'm talking about dual audio and menus in AVI. Yes, about dual audio, it is possible with AVI, but the default splitter supplied with Windows does not support it AFAIK (which accounts for like 99% of people using Windows). I think you will probably just get 2 audio streams playing at once. I don't know, and don't care to find out if Haali's splitter has the capability; I'm content with MKV and MP4.

IF YOU WANT DUAL AUDIO AND/OR MENUS, CONTRIBUTE TO MP4 AND/OR MKV RATHER THAN WASTING MANPOWER HACKING OLD FORMATS, AND HINDERING THE DEVELOPMENT OF NEWER ONES.

But no, they are content to stick with packed bitstreams and/or frame lag, and CBR audio (or VBR if you don't mind a workaround).

It's not so much the "hacking" that bothers me, it's that it's counter productive. There are capable, well implemented AND opensource projects out there, that would be grateful for some help.

Had people have done things "right" all those years ago, we would be seeing DivX and XviD encodes, no, MPEG-4 ASP encodes in MP4 (no, this isn't an MP4 hoaring, it's just the simple fact that MP4 existed before MKV and would have been used instead of AVI), and the general support (although very, very good even right now) would be much higher. The fact that it's an ISO standard means companies are happy to implement it. I mean just look at the amount of mobile phones that support .mp4, you also have the iPod, and the PSP (which requires some custom atom I believe).

This is why I believe it's important to use H.264 as a fresh start. We are already doing the right thing by creating native streams (read: non hacked for VfW), and for the most part people refer to it as H.264. Also some people are using the native container (MP4), and others with requirements that MP4 does not aim to fulfil (due to the intention of interoperability), such as AC3, or the opensource softsub formats, use MKV (one thing I don't get is when people put H.264 + AAC in MKV, and don't make use of a single MKV feature, not softsubs, not even chapters). Sometimes you get AVC thrown in, but maybe that's just a dual standard we will end up living with, think anime; do you call a short series an OAV (original animated video) or an OVA (original video animation)?

I'm not a complete specs Nazi, I just dislike the actions of idiot people that makes stuff incompatible.

Sidenote: For those of you that dislike the idea of being "confined" to profiles and levels, you will be happy to know that you can encode up to 4096x2304@26.7 FPS and still fall within a specified level (that also translates to 1920x1088@120.5 FPS). So encode freely, and still be "compliant" :D

Originally Posted by cf18

Anyone have other tips and optimization for H.264 decoding? There are a few HD H.264 releases that is totally unplayable on my box.

Short of using CoreAVC, there probably aren't many options left aside from overclocking... Personally if I was in your position (even though I'm not I'm tempted), I would let the group know how useless HD fansubs are right now. AFAIK the HD channels are encrypted meaning no stream dumps (unless that is cracked, but I doubt it), and I don't know of any analogue cards that do 720p or higher. It's usually 480 lines for NTSC or 576 for PAL. Absolute max including inactive area would be 525 lines for NTSC or 625 lines for PAL, so I seriously question upscaling (on the raw capper/provider's part). I find that on so called HD raws that the quality is no better than normal (worse in some cases, like excessive banding), so I question their integrity.

Also, now question your target audience. It will generally be people with computers (OMFG WHAT!?) and computer users usually have monitors in the region of 15"-21"; let's say 17" as an average. When I had a 19" monitor, I was still using 1024x768 (and enjoying how everything was OMG HUEG, going from a 14" monitor). Now I am using this 21" flat CRT (same visible area as a 22" CRT supposedly) I have jacked it up a little to 1280x960; sometimes I might crank it up to 1600x1200 or 2048x1536 when video editing with D1 material, but that's rare. What I am saying, is given the average screen sizes and resolutions (remember that although you might be able to use the higher resolutions, you might not be able to do so at a comfortable refresh rate), I'm of the opinion that HD as far as fansubs go (more so current CG series) is exuberant. It's kind of like 5.1 surround a few years back, it's a nice feature that a minority benefited from. Well 5.1 is quite widespread now, but I don't see many people benefiting from HD, unless they have 40"+ monitors.

I think that the PAL sizes are good enough balance between a higher resolution and filesize/CPU requirements; take 1024x576 or 768x576 for example (assuming you had a "real" HD source and scaled it down to this)

Originally Posted by Ronbo

What I’m looking for are real world observations and not just tech specs.
I would also like some feedback from the fan-sub groups that are using H.264 in regards to whether or not it has lived up to their expectations.

H.264, or more specifically x264 has continued to amaze me. I've been able to drop in the region of 20-40% filesize using H.264 + LC-AAC together, as opposed to MPEG-4 ASP + MP3. That's an insane amount when you consider the large compression ratio already. For a bit of useless information, an uncompressed YV12 encode, 640x480@23.976 @ 24 minutes is approximately 15.5GB.

A YV12 frame is exactly half the size of a RGB frame. This is because RGB stores 3 values per pixel (one value each for R, G and B), 640*480*3=921600 bytes. YV12 on the other hand, stores the image as 3 planes; you have luma (brightness) and chroma (blue and red). The luma is stored at full resolution (640x480) and the chroma is subsampled, in the case of YV12 this is 1 chroma sample per 4 luma samples; effectively quarter of the resolution. The red and blue chroma planes are stored at 320x240 each. Why is green not stored? Well that's because it can be calculated from the blue and red values :). Pretty clever eh? So how does this translate to half the filesize? Well the luma plane stores 1 value per pixel, the chroma planes also store 1 value per pixel, but remember they are 1/4 of the resolution (320x240). Now we have: Luma (Y)=640*480*1=307200 bytes, Chroma Blue (Cb)=320*240=76800 bytes, Chroma Red (Cr)=320*240=76800 bytes, therefore 307200 + 76800 + 76800 = 460800 bytes (RGB is 921600 bytes).

Originally Posted by Ronbo

Seems to me that H.264’s claim to fame lays in its real time transmission bandwidth reduction.

Yes, but let's not forget that there is more than one way to utilise an increase in efficiency. You can lower the filesize/bitrate for the same quality, saving you space and transmission time, or you can keep the same filesize/bitrate and benefit from the efficiency in way of an increase of quality.

Originally Posted by Ronbo

Which brings up another question!
Why use MKV as a container for H.264 encodes?
Why not use an industry standard container like MPEG 4 that plays on PC‘s as well as set top boxes?

People will know me as pro-MP4, which does not automatically mean anti-MKV (I like MKV for transcoding my stream dumps from DVB). So why use MKV you say? There are a huge list of reasons, a few of them being that you can use Vorbis audio (the aoTuV tuned version is really nice), Variable Frame Rate, ASS/SSA softsubs (also DVD subpictures, and a bunch of other formats) and a few other cool things like sequential linking, chapters linking to external files etc. What I didn't understand was why people put H.264 + AAC in MKV without using any of MKV's features, not even chapters. I guess you could put it down to consistency (e.g. if they have a lot of other MKV releases already). Personally I will use MP4 for a basic H.264 + AAC + Chapters; but if I want VFR, I have no problems in using MKV.

Originally Posted by TheFluff

Using the name of the standard makes more sense than for ASP, since with ASP there's the subtle incompatibilities between DivX and everything else - with h264 there are no such evilnesses, at least not yet.

Well the problems that have existed for ASP are due to half assed commercial decoders (such as DivX) and/or hacks required for VfW. Thankfully Nero and Ateme are working closely and are pretty much leading the way with a solid, well featured decoder, and on the end user side of things, the majority of people recognise that VfW is too old now, and are creating native H.264 in MKV or MP4. About the only issue with H.264 now is the decoding requirements, which aren't extortionate when using an efficient decoder like CoreAVC. Having said that, capable hardware is now at bargain bin prices (well almost).

Originally Posted by TheFluff

Additionally, MKV is an open standard, while MP4 is owned (and probably patented) by the MPEG consortium, which matters a lot to some people.

Not wanting to "troll" your post, but although MKV may be patent free, H.264 + AAC is not (additionally, neither are MPEG-4 ASP or MP3), which kind of defeats the objective if someone is using MKV solely because you don't like patents (hint, use it for it's features ;)). You could use Theora and Vorbis, but would you really want to shoot yourself in the foot (Theora isn't too hot right now, but that's probably because the good algorithms are patented...) just to be able to say, "Hey guys, what we're doing is illegal, but at least our tools are patent free!"

One thing I will throw in, is that H.264 Baseline should be patent free (that was the design criteria), whether or not it still is I don't know; but baseline is horribly simple. MPEG has had a say in a lot of the coding tools, or rather standards we have used when you think about it.

Originally Posted by Jekyll

The current Blu-Ray specs do not include support for the MP4 container. They describe storage of H.264 in MPEG2-TS. I don't know about HD-DVD, though.

Bluray is a dead loss in my opinion. It's the new age betamax (hey, its Betamax (Bluray) vs. VHS (HD-DVD)). First it's more expensive to produce the media, second it requires an almost complete retooling of the factory, or their manufacturing process, thirdly, there was some hoo-hah a while about about some Sony big shot commenting that H.264 is not significantly better than MPEG-2; and so pre-recorded Bluray discs will use MPEG-2. The unfortunate thing with Sony is that they can make some nice stuff, but they fail to deliver (usually in a crippled or proprietary format way).
HD-DVD on the other hand, is cheap, and can be produced with some minor adjustments to the production line. You also have the name; everyone is familiar with DVD, even my 80 year old grandparents. Then you have the buzzwords, HD, HDTV. Well Joe Average only needs to put 2 + 2 together to get 4 and realise that HD-DVD is a high definition DVD (or as the average consumer might see it, "better quality").

Originally Posted by SirCanealot

H.264 represents a huge step in the quality of video, much like DivX to XVid was. The problem now is that the community is much larger than it was in the DivX-XVid days.

It's probably what you meant, but I find the quality improvement is huge. Probably as significant as DivX3.11a (no SBC) > Xvid 1.1 (maybe better).

Originally Posted by Access

h.264 is a standard while things like divx311alpha, xvid, etc. are singular codecs (with the decoder, encoder, etc. built in to the codec). Some of these individual codecs could inter-operate b'cos of MPEG-4 h.263 or something like that, but they were still .avi's themselves and such needed something to process the .avi wrapper.

Well, H.264 is a standard, yes, and people use encoders that output using this standard. XviD is an encoder that outputs bitstreams "compatible" with MPEG-4 SP/ASP (which is a standard). So it's not the case that XviD is some proprietary format (be it opensource and non patented, or corporation owned software like WMV).

h.264 is like the old days with MPEG-1 which means you can use any compliant decoder and encoder you want and they all work together, gauranteed (at least on paper). Long ago MPEG-1 was the favored type of file for hiqh-quality video and there were many good encoders like TMPGEnc, bbMPEG, LSX-MPEG, etc. B'cos there was competition between individual encoders (software, not people). At some point MPEG-1 was eclipsed by MS-MPEG4 V2/V3 and .avi became a de-facto standard.

Kind of random, but yes. You can encode MPEG-4 SP using short header mode and it should be perfectly decodable by a H.263 decoder. Also yes, H.264 + AAC in .mp4 are intended as interoperable standards (there is more to interoperability than just hardware players, remember) and effectively co-exist with or even replace MPEG-1 and .mpg. Also, while it's true that more advanced methods of compression stole MPEG1's thunder, it still gets used even these days (though more people tend to use MPEG-2).

Originally Posted by movax

Similarly today, we have two major implementations of MPEG-4 AVC...Ateme's (aka Nero Recode) and x264 (OSS). Both can produce MPEG-4 AVC complaint video as well. There's nothing remotely "hackish" of DivX/XviD/x264/etc.

As you say, DivX, XviD and x264 all produce bitstreams that comply with the specified syntax; the only thing regarded as hackish is packed bitstream. Other than that, it's relatively Ok. The XviD command line (which can output an elementary stream for muxing to MP4) is perfectly 100% spec compliant (AFAIK).

Originally Posted by Nicholi

That is a little wrong and TheFluff already tried to explain it. XviD and DivX were both created from a standard just like H.264/AVC is, and its name was ISO/IEC 14496-2 or MPEG4-ASP for simplicity (Advanced Simple Profile). Unfortunately back then no one made compatible MPEG4-ASP compliant decoders, and much of the use of MPEG4-ASP in AVI actually made it "incompatible" in some sense. However if there had been a MPEG4-ASP compliant decoder it could play any and all XviD/DivX encodes. We have one today, which has existed for quite some time, it is known as libavcodec which is part of the FFMPEG project and most notably found in FFDShow. Also as time went on both the XviD and DivX "teams" made their decoders more MPEG4-ASP compliant which is why both of them today, as with almost any MPEG4-ASP decoder, have an option to decode all MPEG4-ASP content.

MPEG4-ASP was mangled in its use though. Everyone made their own little encoders which did stupid little things which essentially strayed from the standard, which is why general support of them is hard to follow by other "compliant" decoders. With H.264/AVC it is a whole new ballgame. Everyones smarter and knows what to do. Following the standard will allow any video Encoder X made to be decoded by Decoders A, B, and C. There are a few minor nuances like Baseline, Main, and High Profile encodes which not every encoder/decoder can use, however those are limitations set by the standard which allow one to know what is and is not supported by a decoder.

100% agreed. Everything that was said was perfectly accurate, and you got the point across in 2 paragraphs as opposed to ranting about it for 22 paragraphs or something :rolleyes:. It's reassuring to know that other people appreciate how fucked up ASP got due to whiny end users and companies that bend over backwards to make encoding noob friendly. I laugh when people say they want XviD in AVI fansubs because it is "compatible". If only they knew the whole story. Ultimately, the end user fucked themselves over (and others suffered in the process). They want ASP in AVI (which requires hacks and non spec streams) but then whine about the abysmal state of hardware players, missing or incomplete features (again, going back to DivX only doing a botch job and partially implementing stuff).

Originally Posted by DeathWolf

just to put a grain of salt(while i agree with most of was said)
h264 and mkv/mp4 have currently one prob: close to no compatibility with hardware players
(and yes i know this isnt a big part of the leechers but still)

This is true, but hardware compatibility for ASP is not a great deal better now is it? Hopefully with HD-DVD and Bluray being able to decode H.264 being a mandatory requirement, things will start looking up. One thing is kind of reassuring is that if these HD players are required to be able to decode 720p and then up to 1080i/p, then it will handle SD fansubs with ease. As I mentioned before, a HD-DVD player/Bluray will probably support Levels 4.1/4.2 (which can handle 1920x1088 (doesn't specify interlaced or progressive)) at 30.1 or 60.2 FPS respectively. The same profiles are capable of 1280x720 at 68.3 FPS (level 4.1) and 136.5 FPS (level 4.2). It doesn't give any more information, but resolutions of 800x600 and under can handle in excess of 172FPS (that seems to be capped throughout the graph as the max framerate). So as you can see there is more than enough overhead if you wish to use really insane settings for SD encodes (or in theory).

Originally Posted by Bot1

the perfect media center i can think of that plays every h.264 release in any container is...

me computer!
it takes about five minutes and some cables to be able to view it on my tv :P

Truth. Although a nice, quiet standalone player is a tempting thought (Tornados are great fans, but it gets noisy in there). Also the thought of being able to throw some stuff on a disc and watch it on a friends HD-DVD player (take a step with me into the future...) without worrying about the amount of RAM his computer or standalone has, or how many MHz or cores his CPU has, or even if he has the necessities to decode (that isn't a big problem though) is nice.

Originally Posted by Eeknay

Well, good luck with that when everyone completely adopts h264. Also don't get too obsessed with relying on a hardware player (which I've never seen the logic in, really) since h264+mp4 ain't looking too hot right now for next gen players (although clearly everything is subject to change).

As you quite rightly say, things are subject to change. However, it is highly likely that for whatever program stream they decide to use, it will be based on MP4, or at the very least implement MP4 systems (MP4 systems being menus, chapters, interactivity etc. The kind of stuff you get on DVD, but is capable of a lot more). As I said on Doom9:

Originally Posted by Zero1

What with the Nero/KiSS player talks a while back (and Nero selling software that can create .mp4 files), I would say it's highly likely that at least Nero/KiSS players will support MP4 (Think about it, it's a selling point for both the software and hardware). In fact I hate to make such an assumption, but I wouldn't be surprised if MP4 was supported by default by most if not all HD/Bluray players (Kind of like how (some/most?) DVD players also play MP3 files burned as a data disc, and also (S)VCDs & Photo CDs).

Originally Posted by SirCanealot

Then start buying DVDs. Fansubs aren't intended for viewing everywhere. They are intended for view on a specific bunch of media players (PCs). Fansubs have never been released with other media players in mind. Consider yourself lucky if they work at all.

Fair comment seeing as fansubbing has almost completely migrated from VHS hard copies to online distro (There's got to be some old skoolers out there somewhere, who knows). Also I wouldn't be too pleased at the thought of crippling my encodes to be playable for a somewhat niche market (niche market compared to DVDs at least). If a standard hardware player existed, I would consider making adjustments or compromises to my typesetting (i.e. overscan if it applies) so it would be viewable on TV, but not look like ass on a PC monitor. As for actual encoding settings, well it would seem I don't need to worry about those ;)

Originally Posted by Quarkboy

h.264 is a fixed spec, so let's all hope and pray that when players start to appear, we get the kind of universal compatibility we have with mpeg2 right now. I'd like to think that'll be the case, anyway.

I think the chances of that are good. Here is a bit from a document I was just skimming through:

Originally Posted by JVT-N002d0

We also note some recent developments in the community that may be of interest to our participants:
– The application community appears to be progressing well with widespread adoption of H.264/AVC with final specification or good progress toward final specification of H.264/AVC use in the application communities of IETF AVT, 3GPP (rel 6), 3GPP2, ATSC, DVB (TS 102 005 and TS 101 154), DVD Forum, Blu-ray Disc Association, DMB (Korea), ARIB (Japan mobile segment broadcast), and US DoD MISB (and of course MPEG and the ITU-T).
– The High profile recently completed as part of the FRExt extensions appears to have strong momentum for adoption – possibly even overtaking the Main profile as the primary profile expected to be deployed in large-volume entertainment-quality applications. Evidence of the adoption momentum for the High profile can be seen in recent actions of the DVB, Blu-ray Disc Association, and DVD Forum.

Originally Posted by spie04-h264OverviewPaper

Initial industry feedback has been dramatic in its rapid embrace of FRExt. The High profile appears certain to be incorporated into several important near-term application specifications, particularly including
- The HD-DVD specification of the DVD Forum
- The BD-ROM Video specification of the Blu-ray Disc Association, and
- The DVB (digital video broadcast) standards for European broadcast television
Several other environments may soon embrace it as well (e.g., the Advanced Television Systems Committee (ATSC) in the U.S., and various designs for satellite and cable television). Indeed, it appears that the High profile may rapidly overtake the Main profile in terms of dominant near-term industry implementation interest. This is because the High profile adds more coding efficiency to what was previously defined in the Main profile, without adding a significant amount of implementation complexity.

Well that's perhaps some food for thought. I was actually going to post more (and something slightly more interesting), but laziness has caught up with me yet again.

[TheFluff]

Gawd, Zero1, do you HAVE to write a minor novel-sized post when you revive this thread? :P

Another problem with MPEG4 ASP incompabilities is the iDCT - I point interested parties to this page, which gives a pretty good summary.

Originally Posted by Zero1

Not wanting to "troll" your post, but although MKV may be patent free, H.264 + AAC is not (additionally, neither are MPEG-4 ASP or MP3), which kind of defeats the objective if someone is using MKV solely because you don't like patents (hint, use it for it's features ).

Hush, you... :/

Originally Posted by Zero1

What I didn't understand was why people put H.264 + AAC in MKV without using any of MKV's features, not even chapters.

Yes, this is one thing that puzzles me also. It seems that most fansubbers that use MKV don't even bother with stream names or language tags... which is just pure sloppiness IMHO. If you see an MKV with proper tags, stream names and chapters, poke around until you find out who encoded it. In my experience, in 9 cases out of 10, that person is or was a DVD-ripper... Not too surprising, maybe, considering how much longer the DVD community has had to adapt to the format.

Originally Posted by Lythka

Problem with x264 codec is that it disappoints. You had encoders going "oh, we'll keep the current quality and lower filesize." This is not the case by many groups. They just like to keep the same filesize for "better" quality. But let's be honest: only an incompetent encoder can't keep TV-rip quality on the same level in a similar manner with xvid as he is doing now with x264. TV rips really aren't that great, so of course nobody notices the difference.

I was going to reply to this earlier, but I kinda forgot.
Anyway... it actually seems to depend more on the encoder than on the codec. A good encoder using XviD can beat a mediocre one using x264, even if both are using the same raw. On the other hand, there can be a considerably bigger difference between a good encoder using x264 and a mediocre one using XviD, than if both were using XviD.

[FarthingRedFox]

I hate to be a jerk and all
but, The MPEG4 trend isn't working

Nanami-chan is an example of what i'm talking about

plus the MPEG4 format too complex for the common fansub viewer to understand

[Eeknay]

The common fansub viewer doesn't have to *understand* h264 (also you realize when you say MPEG4 that doesn't really mean anything, there are many different parts and profiles), they just have to the means to click and play it. If they learn anything (or form an opinion) about it, that's a bonus.

Also, what's wrong with Nanami-chan?

[DeathWolf]

and as ever: as long as it works....
sadly mkv AND mp4 both still need better tools to work on for editing.
(at the current time they really dont ahve much than really low level edit capabilities, and no, vdubmod doesnt count)

[Zero1]

Originally Posted by FarthingRedFox

I hate to be a jerk and all
but, The MPEG4 trend isn't working

Nanami-chan is an example of what i'm talking about

plus the MPEG4 format too complex for the common fansub viewer to understand

The MPEG-4 trend has been working since circa 2001 (the video coding that is, the container has failed to take off for reasons described in my previous post, mostly cause people want to stick with AVI). And what is so complex about installing Haali's splitter and CoreAVC or FFDShow? I really don't see complex as an excuse

Originally Posted by DeathWolf

and as ever: as long as it works....
sadly mkv AND mp4 both still need better tools to work on for editing.
(at the current time they really dont ahve much than really low level edit capabilities, and no, vdubmod doesnt count)

That sounds like an arguement of an AVI/VfW fanboy, don't dissapoint me DeathWolf
Well as for editing; I quite agree that using XviD VfW and the likes for workraws is much easier than dealing with H.264, but as a final output format, I don't see what is wrong with H.264, or where editability comes into it. Fansubs are for watching, not NLE :/

Besides, if by editing you mean extracting a chunk to send to a friend, both MKVtoolnix and MP4box have sufficient abilities to do such. The only thing lacking from these is a preview window (well you can use vdub to get your times).

You know as well as I do that editability and ASP isn't terribly flexible unless you are cutting on Intra frames (which IMO shoots down the arguement of editability, if you want editability use an Intra only codec).

Maybe I'm missing something to this editability arguement that sometimes crops up, please elaborate

[Ronbo]

Has anyone actually tried to encode a true HD broadcast using h.264 into a container that is the same size as a standard broadcast transmission? And what will be the ramifications if we use h.264 broadcasts that have DRM protection as part of its encoding?

[Eeknay]

Has anyone actually tried to encode a true HD broadcast using h.264 into a container that is the same size as a standard broadcast transmission?

I'm not quite sure what you're trying to ask here.

And what will be the ramifications if we use h.264 broadcasts that have DRM protection as part of its encoding?

Most stuff nowadays is encrypted so that it can't be captured, DRM doesn't really factor into it. Even if it weren't encrypted there's only one capture card on the market at the moment that can do HD h264 (to my knowledge) and it's pretty rare, not to mention no tools that can edit the stream you capture. In the future I'm sure things will be different but for now sat/cable companies probably aren't too worried (besides, there aren't many HD h264 channels anyway so the point is kinda moot).

[Ronbo]

Originally Posted by Eeknay

I'm not quite sure what you're trying to ask here.

Yeh, that probably was a confusing question. I’ll try to explain it a little better.
HD broadcasts will have up to 4 times as much information to transmit as compared to standard broadcasts. H264 gives them this ability while at the same time allowing them to use their current methods of transmission.
In order for us to experience this same benefit we should be able to compress an HD broadcast to one quarter the size using H264 as compared to lets say Xvid.
I was just wondering if anyone had actually tried this and was able to get it to work without the use of an H264 hardware based decoder.

[lamer_de]

HD broadcasts will have up to 4 times as much information to transmit as compared to standard broadcasts. H264 gives them this ability while at the same time allowing them to use their current methods of transmission.
In order for us to experience this same benefit we should be able to compress an HD broadcast to one quarter the size using H264 as compared to lets say Xvid.

Yes, there are reencodes of US HDTV broadcasts at roughly one quarter the size (1.4GB for 45mins vs 5-6 GB MPEG2) on the net in both xvid or h264. However, TV stations usually do their encoding 1 pass realtime, which at HDTV res is only possible in hardware atm. Hence they need higher bitrates as well. MPG2 HDTV is usually 16-18mbit (less for 720p), H264 HDTV should look good at 8mbit, I guess. I think Pro7 (German free tv channel that broadcasts some movies in hdtv h264) uses something around 6 mbit or so, but I could be wrong, cause I don't have any streams. And yes, once the streams will be copy-protected/drm'ed, you can't access them any more. See Japan for an example of that :P I somehow doubt TV stations use many of the advanced features, because they eat procssing power during encoding. And they're usually interlaced, and the only filters that support that on the pc are nero (not even sure here) and coreavc in the pro version.

CU,
lamer_de

[Eeknay]

So you're asking has anyone ever re-encoded a HD transport stream to a much smaller file using h264, and if they have, have they managed to play it back without their computer exploding?

EDIT; heh Lamer kinda answered already, but yeah, there are rips out there at 700MB HRHD (960x540) xvid vs the 4GB original MPEG2 TS (file sizes varying on network/res/bitrate etc). No one really uses h264 that much (at least not for "scene"/wide distribution) but I do know a few people who re-encode their episodes to 700MB 720p h264. I personally have encoded a 1080i movie to 720p with a bitrate of around 4Mbit/s and it still looked great. If you keep it at 1080 then I expect 6-8Mbit/s would look good, yeah.

[DryFire]

Originally Posted by Zero1

If you aren't prepared to wait for quality, then you are using the wrong encoder right now. Go back to XviD, which although less efficient than x264 (due to it being a different standard) has a much more desirable quality/speed ratio. If you are going to use more relaxed settings than x264's defaults, you might as well go back to XviD, else you will be switching to a newer format which will no doubt isolate a few people, for no amazing gains. If you are going to cut off some people, might as well go all out and do the best job you can so at least the benefit is felt somewhere down the line.

I'm not quite sure I agree.

Looking at this:
http://forum.doom9.org/showthread.ph...t=speed+v+psnr

It would seem x264 can still beat Xvid in both speed and quality. I don't know how much faith you put into PSNR and SSIM but it seems like something worth looking into.

Though I can't say I've done any tests in this regard.

Truth. Although a nice, quiet standalone player is a tempting thought (Tornados are great fans, but it gets noisy in there).

I'm surprised those tornado's haven't made you deaf. I couldn't stand to be near a computer with one; I can barely stand the noise coming from the A64's stock cooler. Though there's no need to worry, you could make a computer that is quiet enough to where you can't hear it from a few meters out. For that I point you to http://silentpcreview.com/ .

[TheFluff]

Speaking of that, CoreAVC finally got released today, after several delays. The "enterprise" edition still isn't out, the website has lots of TM's but little else, the Pro version says "GPU support to be added at a later date" and the features of each version (the latest seems to be 0.0.0.9 alpha) are "subject to change". The Pro version (the one worth investing in, the standard variant is pointless) costs $19.95, and that is supposedly a special 30% off offer.

Meanwhile, libavcodec has gotten a few optimizations to its h264 decoding lately...

[Eeknay]

The prices are pretty sensible. I'm not completely sold yet though, I'd like to know whether there's been any further improvements over the alpha we've all got and I guess it depends how much Enterprise costs also.

[Ronbo]

Correct me if I’m wrong but doesn’t a resolution of 1080 take 2 & a half times more processing power than a resolution of 720 using H.264?
Fuji even states that H.264 is more complex compared to former compression methods, and is known for requiring processing power that is approximately 10 times that which is required for MPEG-2.
Given this, will software based decoders actually be able to handle H.264 at HD resolutions of 1080 without bogging down our systems or just flat out not working?

[Eeknay]

You need a monster of a CPU to do 1080 h264. It would be extremely demanding even with CoreAVC (I did a test with some HD material... slideshow heaven). So yeah, your average machine isn't going to be able to handle it.

[Quarkboy]

Originally Posted by Ronbo

Correct me if I’m wrong but doesn’t a resolution of 1080 take 2 & a half times more processing power than a resolution of 720 using H.264?
Fuji even states that H.264 is more complex compared to former compression methods, and is known for requiring processing power that is approximately 10 times that which is required for MPEG-2.
Given this, will software based decoders actually be able to handle H.264 at HD resolutions of 1080 without bogging down our systems or just flat out not working?

The short answer is: depends on your system. If you've got a pretty fast P4 with new memory, you can probably decode true HD h.264 at 1080 now in real time. But my poor Athlon 64 3100 isn't going to cut it. This however can be mitigated by hardware acceleration, which is already implemented in certain high-end video cards, which can offload some of the more time consuming operations like deblocking to hardware.

If you remember, in the early days of mpeg2 we had the same issues, and hardware mpeg2 acceleration is now pretty standard, even though it's unneccesary for most systems. I think the same thing will happen with h264.

[Ronbo]

Am I ok with this setup or will I have to upgrade?

Super Alien 12bay tower case w/6 fans
Antec 550w Truecontrol power supply
3ghz P4 HT (Intel)
Abit IC7 800MHZ FSB Motherboard
1GB DDR Ram PC3200
ATI Radion 9800 Pro 256MB
19” Samsung 995DF Monitor
1-WD 120GB HD (Main)
1-WD 250GB Internal HD
4-Maxtor 250GB Internal HD’s
2-Maxtor 300GB External HD’s
1-Maxtor 500GB External HD
1-TDK 840G Multiformat DVD recorder
1-TDK 440N Multiformat DVD recorder