Jump to content

Talk:Advanced Video Coding/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3

H.264 is ISO MPEG-4 part 10?

The article mentions that H.264 is ISO MPEG-4 part 10. However, the wikipedia article about H.263 mentions that it is MPEG-4 part 10 as well. Therefore, one of the two articles must have an error, right?

Reply: No, you misread the H.263 article. It does NOT say that H.263 is MPEG-4 part 10. It does say that H.264 is. --Snacky 08:11, 18 Jan 2005 (UTC)

Note: H.263 in its barebones configuration (ie without the options in its various annexes) is equivalent to MPEG-4 Part 2 also in its barebones mode. My understanding is that, due to bitstream syntax differences, they are not interoperable. Simaocampos (talk) 15:35, 4 June 2008 (UTC)

The article mentions that "H.264/AVC has a reference implementation that can be freely downloaded". I always believed that all itu and iso stuff costs a lot of money to download. A link in the "external links" section to this "free reference implementation" could verify the article's claim. --Robert

Reply: see ftp://standards.polycom.com/reference_software/

Find here the practically useless JM reference encoder source code. I say practically because this software is far too slow for normal use, but it's helpful to read for someone who's trying to implement their own encoder. Of course, the code itself is free. But AIUI, using or distributing either h.264 videos or software packages is probably only allowed if you've paid the licensing fees. This doesn't preclude the JVT guys from showing us a sample implementation - indeed, it's probably in their interest to do so, because it furthers the adoption of their open standard. --Snacky 08:07, 18 Jan 2005 (UTC)

Thanks for the link, but this ftp directory seems to be only temporary, as it has already been removed at the time of my writing (23 Jan 2005). Maybe there is a different location where all those documents are really, officially stored, and that we could also add to the list of external links in the article? Anybody knows more about this? --Robert


Nothing has been removed. It's a perfectly good link. There is no reason to believe the directory is temporary and iirc it's hosted the reference software for a relatively long time. --Snacky 05:05, 25 Jan 2005 (UTC)

20 Feb 2005 Update: See the external links section for up-to-date URLs for reference code and JVT documents. -4.65.144.54

The Polycom repository has been moved on a permanent basis to ITU. For the particular URL mentioned above, please look at: http://ftp3.itu.ch/av-arch/jvt-site/reference_software/ Simaocampos (talk) 15:36, 4 June 2008 (UTC)

H.264 or MPEG-4 Part 10 name?

Well, I'm of the opinion that MPEG-4 Part 10 is a more neat and library-codec wise better name. What do you other people think about this? It fits the other MPEG-4 Parts better in a chronological order if this one has MPEG-4 Part 10 instead of H.264 and I think we should all take it cool with the name reverts until we've all decided what it should be. Okay?

Just noticed this. Unlike other parts of MPEG-4, this is a joint standard between both ITU-T (where it fits in the H.26x family of standards) and ISO/IEC, where it is one element of ISO/IEC 14496 (a family of standards with the informal nick-name "MPEG-4"). The official name in ITU-T is H.264, a name which is consistent with the naming of the other ITU-T video coding standards. The official name in ISO/IEC is 14496-10. See links section for official publication names. To fit with the usual treatment of the subject in publications, my proposal now on the table is the use of a joint/hybrid name for the page. Practically nobody really calls it "MPEG-4 Part 10" -- people tend to call it "H.264" or "MPEG-4 AVC" or "AVC" or a hybrid name (typically "H.264/AVC" or "H.264/MPEG-4 AVC" or "AVC/H.264"), but not often "MPEG-4 Part 10". If the idea is to "take it cool", I would suggest that the previous name under which the page was developed seemed pretty "cool" until a couple of days ago, thus it seems more of a consensus than your recent rename. Cat5nap 21:21, 3 Apr 2005 (UTC)

You got a point. But think about it: what does H.264 or AVC tell you from a n00b point of view? Nothing. Anyone who doesn't know anything about codecs/digital audio/video wouldn't be able to glean anything from H.26x or AVC. MPEG-4 Part 10 on the other hand gives a n00b an insight of what this is. I'm not saying that you're n00b, we know what these kind of stuff are, but Wikipedia in my opinion has to be all around fair in being user friendly so everyone can understand. Or what do you think?
What does "MPEG-4 Part 10" tell a n00b? My guess is that someone coming upon the standard primarily only by the name "MPEG-4 Part 10" would get the impression that it is something that must be used as part of some larger environment called MPEG-4, which would be an incorrect impression. It is a stand-alone specification that can be used in many different system environments. (Otherwise, all these names might seem like arbitrary strings of characters to a raw n00b.) I would guess that a n00b would only find their way to this page by looking at what someone else called the thing, and we clearly need to provide links to help that process. I think most publications use hybrid names (the Richardson book calls it H.264 in the title, and I think all the other referenced overview articles in the external reference section use a hybrid name). Cat5nap 21:54, 3 Apr 2005 (UTC)

"I would guess that a n00b would only find their way to this page by looking at what someone else called the thing, and we clearly need to provide links to help that process." <--- Sure, and that's where the redirect links come in :) That's why I don't see the problem with the article being called MPEG-4 Part 10, since people will find their way to H.264 either way. And about the impression thing, you generally use this part of MPEG-4 with other parts of MPEG-4 (even though it can be used with other non-MPEG-4 parts). Therefore, I can't see why it's a wrong impression. It most definitely should be used only with other MPEG-4 parts as well (for compliance issues). QuickTime will probably not allow the use of H.264 as complete MPEG-4 compliance in anything outside of the MPEG-4 specifics. And Nero Digital is aiming for complete MPEG-4 compliance and don't allow anything non-MPEG-4 in their codecs (yes, I know about the vobsubs in MPEG-4, but that's most likely to change).

One significant use of the codec will be in MPEG-2 systems streams. Applications such as HD-DVD, Blu-Ray and direct-broadcast satellite TV will put the video into MPEG-2 streams, allowing the video codec to be used without other parts of MPEG-4. Perhaps sometimes an MPEG-4 audio codec will also be in use in the system, but such a system can "mix and match" codecs and other aspects at will. Similarly, this video codec is used in videoconferencing systems without ordinarily using any other part of MPEG-4. That is not to say that there's anything bad about using it with other parts of MPEG-4 - just that some applications can work fine without doing that. I think we won't know for a while whether it will "generally" be used with other parts of MPEG-4 or not. Getting back to what it is usually called, I checked the two implementers that you seem to favor: Apple and Nero. Apple seems to primarily call it "H.264" on their web sites, etc. Nero uses a hybrid name - they appear to mostly call it "AVC/H.264" in their press releases. Cat5nap 23:31, 5 Apr 2005 (UTC)

Quarter pixels and YUV

"Quarter-pixel precision for motion compensation, enabling very precise description of the displacements of moving areas. For chroma the resolution is typically halved (see 4:2:0) therefore the motion compensation precision is down to one-eighth pixel."

Shouldn't this be "one-half pixel"? Or is it indicating that one quarter pixel in output space is one eigth in chroma space?

Response: "Quarter-pixel" in luma domain corresponds to "one-eighth pixel" in chroma domain (for 4:2:0 format imagery). -81.254.58.235 14:27, 22 October 2005 (UTC)

No it doesn't. Quarter-pixel is more precise than half-pixel. Eigth-pixel would be more precise than quarter-pixel. When you half the resolution, each chroma pixel corresponds to two output pixels. Therefore, a quarter-pixel at output (and luma) resolution is a half-pixel for chroma-purposes. Any other way doesn't make sense if if reduces accuracy, i.e. if eigth-pixel accuracy were used in chroma, then precision wouldn't be "down". If you disagree, please explain what you're on about instead of merely restating the language in question. 199.174.240.231 12:14, 8 June 2006 (UTC)
In essence, if you have 3 pixels on the luma plane with with quarter pixel sampling between them (+...+...+) which maps onto two chroma pixels then to accurately take a sample from the chroma planes that are aligned with the luma plane we need to have take eight-pixel samples from the chroma planes (+.......+). However this isn't how previous standards have worked (they generally rounded off and took half-pixel samples on the chroma planes), possibly due to the higher cost involved in more intensive interpolation. AlyM 22:28, 8 June 2006 (UTC)
Right (although it would be four samples in luma that would correspond to two samples in chroma). For the definite answer, just look at the standard. Section 8.4.2.2.2, equation 8-266 of the current version has this equation: predPartLXC[xC,yC] = ((8–xFracC)*(8–yFracC)*A + xFracC*(8–yFracC)*B + (8–xFracC)*yFracC*C + xFracC*yFracC*D + 32) >> 6. This is obviously linear interplation with one-eighth grid units. -131.107.0.73 18:17, 16 May 2007 (UTC)

"ghakko", since you have ignored my email, i'll try this talk page... why did you delete the link i put up on the h.264 page? Unsigned comment by 64.169.232.175 on 05:45, 15 July 2005 UTC

  1. Please sign your comments with ~~~~.
  2. Ask on talk pages instead of sending mail first: it leaves a public trail of correspondence that others can follow.
  3. I noticed you linked to your site from both the Nero Digital and H.264 articles.
    • In the former case, it was abundantly clear that you were trying to drive traffic to your site by adding an endorsement to the article text.
    • In the latter case, external links to advertising-heavy sites is still very much frowned upon, especially when the site linked to does not contain neutral and factual information not already in the article. That some articles have accumulated many such links really behooves us to sift through and clean them out, not others to jump on the bandwagon.
—Ghakko 09:04, 15 July 2005 (UTC)
"ghakko", i do not have any of my products advertised or for sale on my codectest.com website... i followed the link you visited at my site via the server logs; you did not look at all 4 pages, you did not download the test clips that i created in multiple video formats, you totally ignored the email that i sent to you wrt this problem, and for some strange reason the h.264 page reverted to a version prior to the deletion that you made, with no record of that later edit.
since you did not bother to evaluate the link that i posted, you are unqualified to decide whether or not it is an "endorsement" of any kind... most especially, the trail you left in my server logs proved that you did not even go to the nero digital page! and if you truly wanted a "public trail of correspondence", then you would have posted my email to this thread... which you did not do, of course.
beyond all that, you have no visible record of any competence in the area of codecs, since your identity is carefully hidden... a search for "ghakko" on all wikipedia links shows zero technical expertise of any sort... are you some kind of a self-appointed admin drone?
out of respect for the hard work that people other than you have done on the h.264 page, i have not engaged in an edit war out there... i am willing to justify to some extent why the links to codectest.com should be part of this archive, but you will first need to understand what i have created at codectest.com.
Unsigned comment by Osv on 06:48, 20 July 2005 (UTC)
Hello again.
Don't make personal attacks. It hardly helps to be abrasive and unpleasant. As for the rest, let's re-iterate:
  1. Don't link to advertising-heavy sites.
  2. Don't promote yourself or your ventures.
  3. Try to link only to objective, neutral and informative sources. Benchmarks, specifications, scientific papers are examples of such sources, editorials are not.
  4. Don't disguise endorsements as article text.
All of these are policy.
And finally, keep in mind that we don't hate you.  ;-) I wish you a good day, and all the best on your new site.
—Ghakko 12:43, 20 July 2005 (UTC)
"ghakko", i see that you have not responded to any of the points that i raised... it is going to be difficult to carry on a conversation with someone who ignores everything that is posted to this thread.
so i will repeat, have you gone out to codectest.com to evaluate it's content? have you looked at *all* of the pages, and downloaded the video comparison test clips?
Unsigned comment by Osv on 13:12, 21 July 2005
Let's re-re-iterate. This would be fine if there was:
  • A objective metric of some sort. This could be:
    • A similarity index of some sort. Many benchmarkers use the PSNR or the SSIM (between pairs of frames from the source and encoded video). I can offer suggestions if you need help in putting together a benchmark harness on a Unix system.
    • The results of a randomized viewing test. It would have to have a methodology similar to that of the ABC/HR or ABX listener tests for audio codecs.
  • A wide variety of source material.
  • Full disclosure of the method.
Instead, you say "I believe codecs W and X is better than codec Y and Z. Here's some sample clips to illustrate." That's editorial, not objective information. Vendors often do exactly this when plugging their own codecs.
Of course, there still is the issue of self-promotion, the rather underhanded way with which it was done and the amount of advertising on the site itself. As said before, this is a no-no.
And finally, please sign your replies and try not to fall back onto ad hominem attacks. It's not particularly helpful in this discussion. Let's instead hope we can find some amicable closure to this. Have a nice day. :)
—Ghakko 05:48, 21 July 2005 (UTC)
"ghakko", i will re-re-reiterate: have you looked at *all* of the pages, and downloaded the video comparison test clips? no, you certainly have not.
let me remind you that "Failure to pursue discussion in good faith shows that you are trying to escalate the dispute instead of resolving it." ...your ongoing refusal to evalute codectest.com on it's merits is proof enough of that.
stop making generalizations that do not apply to this situation... for instance, i am not a codec vendor, and nowhere on codectest.com do i pick a specific overwhelming "winner" of any codec comparison testing.
things like psnr testing certainly do have their place, but they are metrics that the general public is totally unable to relate to... hence the creation of codectest.com, which is designed to let people make their own decisions about which codec is best for their application, by viewing actual video clips.
you have lost sight of the fact that wikipedia is designed for the general public to use... this h.264 page is not something that the average joe can relate to at all, and i am trying to help that situation.
Unsigned comment by Osv on 19:57, 21 July 2005 (UTC)
And saying "you're not assuming good faith" is generally one of the obvious signs of bad faith. You have lost sight of the fact that Wikipedia is an encyclopedia, not a means for boosting traffic to your ad-laden site. Linking to yourself is considered very bad form. -- Cyrius|✎ 03:10, 22 July 2005 (UTC)
And I must remind you, Osv, that good faith does not imply a willingness to blindly accept assertions.  ;-) In fact, it's quite ironic that you've brought it up when you haven't been civil or even addressed any of the original objections: personal promotion, lack of objective information, link to a advertising-heavy site or the use of article text for endorsement.
So let's just wind up on the understanding that any attempt to re-add a link to your site will be reverted. Have a good day, and may you one day contribute usefully to the Wikipedia.
—Ghakko 11:14, 22 July 2005 (UTC)

"cyrius", i never made the statement "you're not assuming good faith"... mis-quoting someone like that is hardly an acceptable method of communication, perhaps you could re-phrase it so that it makes sense?

the concept that i am going thru this hassle just for a wikipedia link is very amusing, and it shows a fundamental lack of understanding about how the internet operates.

every ad on codectest.com is screened to be topical content, and there are no pop-ups or pop-unders... the phrase "ad-laden" is hardly appropriate.

"ghakko", i first sent you a courteous email about this issue that you totally ignored, and you failed to put it into this talk paper... your rude behavior there set the tone of this discussion from the start, and you conveniently keep ignoring that issue... your ongoing refusal to acknowledge that is where your bad faith in this discussion keeps showing up.

i put up a website where people can make their own decisions about which codec is best by looking at actual video footage... they judge for themselves what footage looks the best, it's the ultimate in objectivity, and there can be no external endorsement of any codec by anyone in that kind of a personal judgement situation... once again, you have failed to address those points on this talk page, which again shows the level of bad faith that you are communicating at.

wikipeda is here to be edited by the public, and i have relevant content that addresses some of the shortcomings of this h.264 page.

It was a paraphrase of what you seemed to be getting at, not an exact quote. And please read Wikipedia:External links:
"Wikipedia disapproves strongly of links that are added for advertising purposes. Adding links to one's own page is strongly discouraged."
You claim it is not the former, but there is no argument that it is the latter. Adding this link to your site will benefit you, and you are thus not in a position to accurately judge the link's value to Wikipedia. -- Cyrius|✎ 23:27, 22 July 2005 (UTC)

"cyrius", you claimed that it is the former, but you are unable to offer any concrete proof of exactly how it will "benefit" me, and you have also failed to specifically define "benefit"... for instance, your arguments might be: this h.264 page gets xxx amount of web traffic based on the server logs, as seen at wikipedia.org/xxx.html... you will receive xxx number of clicks back to codectest.com... and then, specifically what the nature of the "benefit" to those clicks is.

the reason you must be specific is because both you and "ghakko" persist in using generalities to hide the real facts of this specific case.

wrt your claim that "it is the latter", i will remind you that wikipedia.org is riddled with links back to "ad-laden" websites... for instance: http://en.wikipedia.org/wiki/Slashdot.org has an entire wikipedia page dedicated to it! the slashdot home page has a very large block of paid advertising links in the upper right-hand corner labeled "marketplace links".

that directly contradicts the bogus generalities you just posted: "Wikipedia:External links:

"Wikipedia disapproves strongly of links that are added for advertising purposes."

"ghakko" must respond directly to this, or it will be further proof of his failure to use good faith in this discussion.

"Adding links to one's own page is strongly discouraged." What part of this do you not understand? -- Cyrius|✎ 17:50, 23 July 2005 (UTC)
You're accusing him of not having good faith, but you fail to explain why your site provides enough value that you feel compelled to link it instead of letting others do it. I think Ghakko's in the right here. Thsgrn 17:41, 24 July 2005 (UTC)
Oh, and the link to slashdot was added to the slashdot article because the article was about slashdot. Is this article about your website? No? Okay then. Thsgrn 17:43, 24 July 2005 (UTC)

Hello, I just had a read through of this discussion and looked briefly at the website in question, to try and help out this dispute on whether it should be included or not. I'm not overly knowledgable about codecs, but I know enough to understand the general nature of this dispute.

My thoughts on this is that the codectest.com link is not a necessary addition. Personally, I do not find the website simple to use or even navigate. For a comparison site, compareison tables with ticks/crosses on features are helpful, this website has paragraphs of text in bold which I find somewhat difficult to read. The website also has a large amount of space taken up by adverts. From what the website owner wrote above, I get the impression that either it's a new site or not a very popular one (as he tracked ghakko's page visits).

One Wikipedia policy to keep in mind is that you should not add external links to content you have created, whether it be a novel, a thesis or a website - therefore I think that it should be up to others, not the person posting above, to add this link if they feel it is useful.

I think some of the information on the site is useful, so please add it to the appropriate articles, citing appropriate sources (but be wary of not including any original research). Having knowlegable contributors about complicated topics like media codecs is incredibly helpful to Wikipedia. Talrias (t | e | c) 17:54, 24 July 2005 (UTC)

"cyrius", you totally failed to respond to the comments i made wrt to the bogus generalities that *you* posted: " Adding this link to your site will benefit you"... your inability to show exactly how i "benefit" from a wikipedia link will constitute your agreement with my line of reasoning, is that not correct? ongoing failure to respond to this point of the conversation will prove bad faith on your part.

beyond that, your absurd comment :"Adding links to one's own page is strongly discouraged." What part of this do you not understand?" can easily be overcome if someone else adds the codectest.com link, is that not correct? respond directly to this question, or it will be further evidence of bad faith discussion on your part...

FELLOW WIKIPEDIANS: either agree, or disagree, with each point, so that we can get it settled and move on with this discussion... random sniping from people like "thsgrn", who have clearly not bothered to read the thread at all, or visit codectest.com, will not move this discussion forward.

I did look. I also read the thread. The site has google ads on the left in all pages that I saw, on the right of some, and in the middle of others. You have advertisements, and thus obviously benefit from links to your page. You can hardly deny that. Michael Ralston 18:51, 24 July 2005 (UTC)

"Talrias", thank you for being the first wikipedian to actually go out and look at the website in question, lol... i appreciate your comments, and i agree that there are issues with negotiating the layout of the site to arrive at the most meaningful conclusion... that was evidenced by the fact that you did not make any mention of actually downloading and viewing the comparison test clips, which is supposed to be the entire point of the website.

since you would be making your own judgements on codec quality by looking at the clips, there is no reason for me to put up comparison tables on the website... i realize that actually looking at the video is a new concept for many people, but i judge codecs all the time like that as part of my job.

please be clear that i made no attempt to edit the body of text on either the h.264 page or the nero digital page.

"Michael Ralston", you have failed to define exactly how a link from wikipedia would "benefit" codectest.com... "obviously" is a meaningless term... most importantly, tho, you have also failed to address the point i made earlier about wikipedia being riddled with links to websites that have advertising on them, and how that is any different from a wikipedia link back to codectest.com.

i will help sort out this confusion for both you and your fellow wikipedians by notating a wikipeda page that has *news source* links back to websites that have massive amounts of advertising: http://en.wikinews.org/wiki/Many_dead_in_Egyptian_resort_blasts has links back to:

http://www.ctv.ca/servlet/ArticleNews/story/CTVNews/20050724_egypt_bombings_050723/?hub=World http://news.yahoo.com/s/ap/20050723/ap_on_re_mi_ea/egypt_explosions;_ylt=AqKcVc2qo54c42Ar7QTesHSs0NUE;_ylu=X3oDMTA2Z2szazkxBHNlYwN0bQ-- http://www.foxnews.com/story/0,2933,163429,00.html http://today.reuters.com/news/NewsArticle.aspx?type=topNews&storyID=2005-07-23T104409Z_01_N23649802_RTRIDST_0_NEWS-EGYPT-EXPLOSIONS-DC.XML

so we see that it is a standard operating procedure for wikipedia.org to constantly quote, on a daily basis, advertising-based websites as authoritative sources of information.

therefore, advertising on codectest.com is clearly not relevant to this discussion.

The difference is that Reuters doesn't come along demanding that we link to them. Linking to your own site is strongly discouraged. Why are you being so insistent? -- Cyrius|✎ 01:36, 25 July 2005 (UTC)

"cyrius", you have *once again* failed to respond to my point wrt to a link to codectest.com being put in by someone other than myself... stop avoiding the subject! it shows bad faith on your part.

i notice that you have also failed to respond to the point i made wrt the many current wikipedia links to "ad-laden" websites.

your negative, selective sniping is not moving the discussion forward.

The subject is that you are putting in a link to your site, and we'd like you to stop. You now appear to be looking for weaknesses in Wikipedia's rules and guidelines in order to get the link in the article. Why are you so intent on having Wikipedia link to your site? -- Cyrius|✎ 02:20, 26 July 2005 (UTC)

"cyrius", i'd like to know the real reason why a link to codectest.com is bothering you so much... by now, it is clear to all of us that you refuse to look at the website and evaluate the content, which is counter-productive to the most basic wikipedia tenents... it shows that you have an ulterior motive for keeping the status quo out here... do you feel threatened? is this some kind of a control issue for you?

Stop trying to play therapist. Your site consists of four pages and a 13 megabyte zip file, with no actual technical content. On those four pages, the reader will see some 48 individual Google text ads. You can't (won't?) even make your off-site links work. The entire purpose of the site is to get people to download the video clip, which is conveniently an ad for your other site, sportcompactdragracing.com. You are engaging in self-promotion, and I claim my five dollars. -- Cyrius|✎ 00:00, 27 July 2005 (UTC)

"cyrius", i see that the concept of therapy really motivates you ;-) funny, i've been on the usenet since ~1986, and i've never seen that expression you highlighted... seriously tho, thanks for checking out the website, i'm glad that you noticed the lack of detailed tech content, must i repeat that it's not designed for doom9 codec nerds?? it's targeted for 99.99% of the internet... but having a link back to it WILL help those wikipedia visitors who aren't doom9 codec nerds... i'm kinda wondering why you don't understand that? you seriously don't think that people looking for info on h.264 would be interested in drag racing, do you? where is the connection? fyi, i currently serve up ~100 gigs a month of free drag racing content, so you can forget the idea of self-promotion... i don't need wikipedia for that.

btw, since you missed the live link at the bottom of each page, you really don't get your 5 pounds after all, lol... the url text on the video clips is there in part for copyright purposes, but mostly it's there so that people can compare the aliasing capabilities of encoders/codecs... talking head footage does not stress an encoder/codec nearly as much as fast action does... hopefully you noticed that i went into quite a bit of detail about the encoding test parameters, i guess that you just conveniently failed to mention it.

one thing that you really need to do is to admit to yourself that links to sites with advertising will forever be a permanent part of wikipedia.org; i already proved that... in the real world, people have bandwidth and hosting costs to pay for.

The bottom line is that it's contrary to policy, notwithstanding the blatant advertising. As it stands, the site doesn't even justify its specious conclusions on codec quality. - mako 10:00, 1 August 2005 (UTC)

Osv:

  1. Sign your comments with ~~~~.
  2. Don't make personal attacks. This means commenting on what other people have done or said ("you did this," "he said that," etc).
  3. If you operate a website that you think it would be useful to link to from Wikipedia, instead of adding a link to it, post a comment in the talk page and leave others to link to it if they agree. If there is ever any information that is about you or your websites, that you think should be in Wikipedia, merely draw attention to it (in Talk pages) and allow others to write it up.
J Alexander D Atkins 11:44, 30 November 2005 (UTC)

I beg your pardon, that is not Wikipedia's definition of a personal attack - but I wouldn't do it anyway. - J Alexander D Atkins 11:54, 30 November 2005 (UTC)

Quicktime better than x264?

A recent edit added this in regards to x264 "and also because it is generally accepted to be inferior to proprietary H.264 coders such as QuickTime's implementation."

Does anyone else think that this is false? I was under the impression that x264 is one of the best H.264 encoders, with Ateme somewhat better. Qutezuce

This is not true. x264 is way superior.
EliasAlucard|Talk 21:34, 25 Jul, 2005 (UTC)
May I add that Quicktime's encoder appears to be closely based on JM, which is why it's wildly, insanely, unusably slow. On the flip side, its ultra-slow approaches do just happen to achieve quality that's very similar to JM's. And if you completely ignore speed, Quicktime's best quality is better than x264's best quality.
However, I don't think most users are willing to completely ignore speed/quality tradeoffs. So, for example, with certain settings combinations, Quicktime might take 60 hours to encode your video where x264 might take 2 hours. Suppose with these settings, Quicktime achieves slightly better quality. (these numbers are made-up and for example only, but they're ballpark realistic). If you are only willing to tolerate a 30-hour long encode from Quicktime, you can change some settings that will speed it up to this level, but you will also end up with worse quality than x264 achieved, and Quicktime is still 15 times slower. And as long as we're talking about Apple and H.264, I'd like to point out that the H.264 trailers Apple's serving now are really a poor example of what you can do with H.264. The trailers are designed NOT with high quality and efficiency in mind, but rather they're encoded in such a way that the average user's desktop machine has some remote chance of decoding them in realtime. In particular the trailers do not use CABAC or multiref. Unfortunately this sacrifices so much quality that they'd probably be much better off overall using a good ASP codec such as XviD.
Now, on to the decoder. Quicktime's H.264 decoder is a bit of a mixed bag. The good thing about it is that it does a good job of taking advantage of multiple CPUs. The bad thing about it is that it has arbitrary constraints that prevent it from decoding plenty of perfectly legal H.264 streams. These constrains conform to no standard level or profile, and overall it is less capable than ffmpeg's decoder. Also, I've heard it's really slow on win32 systems. Snacky 21:09, 25 February 2006 (UTC)
Or does Quicktime not use CABAC, multirefs etc because either the format or the player doesn't support those features? I think that Quicktime's ASP encoder also did not use some of the advanced features of ASP that could give it a good boost.
x264 can also take 30 hours, just turn on exhaustive search, trellis, RDO, turn up the ME range, mixed refs, number of multirefs to 16, and do 2-pass (or 3-passes if you feel crazy). That will take a very long time to encode. How does Quicktime stack up then? Qutezuce 22:03, 25 February 2006 (UTC)
I doubt Quicktime is better than x264. When you use the same settings, x264 should slightly be better and would be still much faster. Of course when High Profile is used there is no way Quicktime could compete.
BTW exhaustive search and a big ME range (above 32) are useless.213.23.140.140 01:51, 4 March 2006 (UTC)

Where can I find a draft on the Fidelity Range Extensions?

The article says: The design work on the Fidelity Range Extensions was completed in July of 2004, and the drafting was finished in September of 2004.

Where can I find this draft? I searched ITU pages with no success. -Rafm

The version of the standard that is currently "pre-published" by the ITU (see link in main article) already includes the Fidelity Range Extensions (FRExt). For example, see the definitions of the High, High 10, High 4:2:2, and High 4:4:4 profiles. Those were part of the FRExt package. -Pangolin 03:17, 14 August 2005 (UTC)

"QuickTime 7 supports H.264"

does that picture have any buisness being linked to in the article? that looks to me like an advertisement.

and also, what would be the proper way of pointing this out, if the way I am now is not? qnaal 18:20, 17 August 2005 (UTC)

Hrm, interesting point. I would suggest that yes, this is a logo, an advertisement, for Quicktime, and isn't really relevant to a discussion about H.264, which is supposed to be a standard not tied to any one vendor or product. I would agree with removal.
And in reply to your question about pointing it out, yes, this is exactly the right place to point this out. Thanks for your comments. -- Fudoreaper 22:02:41, 2005-08-17 (UTC)
it is done.
hey, should this part of the discussion page be deleted, or somethin? qnaal 22:59, 17 August 2005 (UTC)


Difference between the profiles?

Can someone add a section about the differences between the profiles defined by the H264 standard? That is, Baseline, Main, and Enhanced? That's what I came here to check up on, but there's no mention of them except in the product listings. — Adam Conover † 00:49, 3 January 2006 (UTC)

Probably a good suggestion. Actually, I think you were shooting for Baseline, Main, and Extended. Some of the referenced papers in the external links section go into detail on this, but it might be a good idea to put it here in the article. There are three other profiles as well now. I added some info about this to the article, but didn't provide very specific feature details (yet). —Cat5nap 07:21, 3 February 2006 (UTC)

File Extension utilization?

This might be a very n00b question but I wasn't able to gleam it from the original text. Will the implementation of AVC/H.264/ISO MPEG-4 part 10 utilize current video extensions (mpg, avi, mpv, mp4, etc) and just have the program note the coding modification or will the standard show up with a specific file extension that will indicate the AVC/H.264/ISO MPEG-4 part 10 formating? i.e. ".avc" or ".264" etc? -Tripperdan99

Various file container formats can store this kind of compressed video bitstream, along with various audio streams and other kinds of data. Ordinarily it is the file format that is designed to carry various specific types of multimedia "elementary stream" types rather than the elementary stream design that mandates being stored in some particular file format. MPEG has standardized how to store it in "*.mp4" and MPEG-2 transport stream and MPEG-2 program stream formats, and also perhaps "*.avc". I believe 3GPP has specified how to store it in "*.3gp". I believe HD DVD and Blu-ray are storing it in MPEG-2 program streams. It can also be stored in other formats if appropriate file format specs have been extended to support it (for example, I'm fairly sure someone has figured out how to store it in "*.avi" and "*.asf", or that someone soon will). —Cat5nap 18:38, 4 February 2006 (UTC)

Royalty-free baseline?

Can the section on licensing make some reference as to whether the Baseline profile is in fact royalty-free? (If, in fact, anyone actually knows the answer to that question.) Some Googling reveals lots of articles from 2003 stating that the Baseline profile is intended to be royalty-free. However, I cannot find any more recent articles on the subject, either saying that yes, the Baseline profile is in fact royalty-free, or no, that was the goal in 2003 but it didn't actually turn out that way. 69.17.96.185 10:33, 14 February 2006 (UTC)

Baseline was supposed to be royalty-free, but it is not - you need two licences (MPEG-LA and one other group). Both are free below (if I remember correctly) 50K units/year, then circa $0.25/unit (each). --jesup 22:27, 27 July 2006 (UTC)
FYI the other group (Via) has shut itself down. MPEG-LA now seems to be the only pool. -Mulligatawny 18:30, 4 October 2006 (UTC)

Levels

Theres a listing of Levels, but no explanation of what Levels signify and are intended for. --Barberio 20:00, 8 March 2006 (UTC)

Indeed, I came to ask that very question. I have noticed they are present as encoding options in Super. Tzarius 20:25, 13 March 2006 (UTC)
I too came looking for an explanation on Levels. Hoping someone elaborates... Will check back after a few days... [Pramod Kaluskar]
Ditto here. I'm using ffmpeg for h264 encoding and needed a better explanation of levels. For example, I've learned by sheer trial and error and IRC that ffmpeg defaults to level 5.1 which does not work for ipods. Level 13 does, but level 13 does not work for Adobe flash player. Level 3, also referred to as "level 30" in many places, works on both. Some guide to what these levels are, and what works where would be a nice addition. Wed May 14 09:21:14 EDT 2008
"Levels," like Profiles, come from an old idea that was introduced with MPEG-2. (actually, the problem was also addressed in a different way in MPEG-1, with a spec referred to as "Constrained Parameter Bitstream.") The problem it addresses is that not every decoder is powerful enough to decode every legal stream. For instance, IIRC MPEG-2 allows any resolution less than 65536x65536. Would you want to claim a decoder is not compliant just because it can't decode this perfectly legal stream?
The industry was worried that there would be a million different decoder products, each with its own slightly different capabilities (different max resolution, max bitrate, max coded picture buffer size, etc). So they started specifying "levels," which set limits on things like resolution and bitrate. The hope is that most manufacturers will conform to one of the levels. So instead of a million different decoders each with slightly different capabilities, we have a million different decoders whose capabilities are standardized.
Just for example, it's probably expected that mobile, low-power decoders will be specced for something like Baseline Profile at Level 1.3. This might be suitable for handheld devices. A set top box designed for hi-def video might conform to High Profile @ Level 4.1, abbreviated "HP@L4.1". HP@L4.1 is what Blu-Ray players will need.
One of the handy things about levels and profiles is that once you decide which one to use, you basically know how much memory your decoder has to have, and how much throughput it has to have. Snacky 22:39, 30 March 2006 (UTC)

Would it be a good idea to add lables "NTSC quality" and "PAL quality" and "HDV quality" to the table? I would add them myself, but it's a little fuzzy on which level is roughly equivalent or better than NTSC quality, also called "Standard; MP@ML". 3 or 3.1 ?

removed a strange paragraph in "Versions": "There is a new using. The sony HDR-SR1 handycam use this codec. The resolution is 1440x1080, and the framerate is 15mbit/sec. The used level is similar to 4 (20mbit/sec -- 1920x1088)." ... ps, the levels was quite useful. thanks! Plonk420 02:28, 14 January 2007 (UTC)

Advertising

This page seems to have become a place for any company that has a H.264 related product to paste it's own little blurb about it's products and get itself some free advertising. The list of products may have added value to the article a year or more ago when there were few products supporting H.264, but now, as the length of the lists testify, there are plenty of products supporting H.264. None of the other articles on audio or video standards contains nearly as long a list of products. So I am proposing that we make some large cuts to this article. Qutezuce 07:44, 30 April 2006 (UTC)

Darn good point. The cuts so far have only made the article better. The hardware section is still a mess, and it's untenable to keep listing any piece of hardware that happens to relate to H.264. My own feeling is we should just list a few popular decoder chips; mention (without so much detail and history) that certain companies make hardware encoders for broadcast; and kill the untenable practice of listing every gadget and device that happens to have anything to do with h.264. Snacky 07:42, 7 May 2006 (UTC)
OK, I made even more cuts. I decided to keep in stuff that struck me as being sort of important. I took out chips I hadn't heard of because maybe they're not so important, and anyway, we already have plenty. I took out PSP because it strikes me as a software player; maybe the iPod is, too. I took out the broadcast-oriented realtime encoders because I felt like it. And I still wouldn't mind seeing the section lose even more entries.
IMO we should try to make the list small and simple. Put new stuff in only if you think you have a better example. Take stuff out if it seems too unimportant and obscure to be one of the few listed. Snacky 13:40, 6 June 2006 (UTC)
Just another thought. Maybe someone (sorry, I'm being lazy here) should make a List of H.264 encoder/decoder page, to divert all that kind of stuff from here. That way we can keep this article from sucking so much ;-) Snacky 02:35, 16 May 2006 (UTC)

While I agree that the page was becoming a way to advertise, now it is a way to advertise for big guys only like ST, Broadcom, etc. etc. These people have millions of dollars avaialble for marketing and they get advertised here for free whereas smaller companies, some with much better products don't. So you either leave as it was or you take advertising away alltogether. The way it is now is just discriminatory in favour of people who needs the advertising the least.

I think at least keeping the list of software encoders and decoders is worthwhile. They vary wildly in their level of completeness (high profile support, interlaced video support etc.) and people should be made aware of this. For example, some people still think Quicktime is the pinnacle of H.264 quality (it isn't).
You're right, it would be nice to have a lot more Quicktime bashing ;-) Snacky 14:18, 14 June 2006 (UTC)
Agreed, snacky ;) .. also, just thought i'd mention doom9 has a pretty comprehensive list of encoders and decoders. i guess i could work on getting it added to links... Plonk420 02:33, 14 January 2007 (UTC)

I created a separate page for it, except for the software encoder comparison. I hope you think it was the right thing to do.  :-) Daniel.Cardenas 17:13, 3 May 2007 (UTC)

So is this software encoder comparison table open to addition of ALL software encoders? Simongarrett 15:54, 21 May 2007 (UTC)

Open to all prominent encoders. For example if someone developed one for a school project, I don't know that it should be listed. If the list gets too big, I believe people will want it moved off onto another page. Perhaps a bullet listing other encoders or listed on another page for 2nd tier encoders would be an option. Daniel.Cardenas 19:42, 21 May 2007 (UTC)

Suggestions

Some hints to improve the readability of this article:

  • "Features" section is dispersive, since there are too many points in the bulleted list. IMHO, proper subsectioning could improve a lot (e.g. motion compensation-which is wlinked too many times at the beginning-, spatial transform, entropy coding, etc.).
  • "Application" section should not contain a so detailed listing of deployments in world countries TV; a link to a separate article could be nice (e.g., "Deployment of H.264/MPEG-4 in TV systems")
  • This fundamental article in image/video coding systems lacks an image or even a figure!

Anyway, it still looks great as it is now. --Cantalamessa 12:11, 1 September 2006 (UTC)

  • Where has the "Products and Implementations" section gone? Why is there now a section on 6 chosen software codecs (QuickTime, Nero, x264 etc) and not others? Sounds a bit like selective advertising to me. Whoops! found it - I've added comment added under "Advertising" Simongarrett 15:14, 21 May 2007 (UTC)
  • The information here is specific, technical, and well written. However, from a practical perspective, I am sure a lot of traffic to this article is (like me) people wondering how to tune their h264 encoding, i.e. using ffmpeg. Some specifics, even if it's specific cases of actual ffmpeg arguments (for example) would be helpful. —Preceding unsigned comment added by Jefight (talk • contribs) 13:24, 14 May 2008 (UTC)

Micronas DeCypher 8100

Is anyone familiar with this chip? Is it anywhere near as popular as the other (ST, Sigma 863x, and BCM) chips? Can someone name some products that use it? If not, I'm thinking about maybe deleting it eventually.

It seems to me like the company that makes it might pass WP:CORP but the product itself probably doesn't deserve coverage. Some of the other decoder chips actually deserve their very own articles, but I'm not inclined to make them. Snacky 02:02, 28 September 2006 (UTC)

Yep I have been working with this chip for 18 months. Linux & WinCE 5.0. This chip is the one to watch, Micronas are pouring alot into this A1 > B1 > B2 3 silicon revisions in like 5 months. IT truly does do 1080p H264 + cabac, Wmv9 , VC1 1080p decode with HW DRM , Mpeg2. You have 5 graphical planes, dual decode, 2 transport streams in, 3 MIPS CPUs to play with. I think ST, BCM etc. better watch out Micronas are quietly getting the silicon & SW mix just right, ready for a summer surprise. Here is some link to the stuff I have designed http://www.reel-multimedia.de/shop/index.php?cPath=39 : http://www.technisat.com/en/presse/pressemitteilungen.php?j=2007&id=501 http://www.simplyglobal.tv/www/what.php JS:UK

Bloated Applications section

OK, we get the idea, H.264 is widely adopted. Is it really necessary to list every organization that has adopted it? Does anyone else agree that this could be cut down to about 25% of its current size, without losing anything particularly important?

Unless there are objections, I'll give this section about a month to live. Then, I'll make extreme cuts. Of course, anyone else who makes cuts before then would have my thanks. Snacky 22:21, 1 October 2006 (UTC)

I personally find that section very useful and not excessively lengthy. Although adoptions are becoming more widespread, I still consider them "newsworthy" and am paying attention to the adoption status. Can you be specific about what you're thinking of removing or replacing with higher-level summaries? -Mulligatawny 18:27, 4 October 2006 (UTC)

OK, how about some examples.
  • The list of Japanese broadcasters using h.264 is inherently crufty, and just an all-round bad idea. I propose cutting out this list, at a minimum. At a maximum, summarize the list by saying "countries a, b, c, [...] employ h.264 in their digital broadcasts."
  • The fact that some standards bureaucracy in the DOD endorses h.264 isn't even worthy of mention. (again, it's widely adopted, we get the idea)
  • Ditto for NATO.
  • The sentence about RTP is, IMVHO, totally out of place, as h.264-in-rtp isn't, in and of itself, an application per se. But, again, we get the idea that h.264 is widely adopted, which could surely be conveyed without listing every single example...
  • ISMA: who cares.
  • MPEG: what's funny is, I actually think I know what this is referring to (specifically amendment 3 to iso 13818-1), and a) I find this sentence to be almost laughably dry and uninformative, and b) this is also not an application per se. Again, we get the idea, h.264 is widely adopted and stuff is being adjusted to account for that fact...
  • ITU/h.323 stuff: overly bulky sentence conveying that h.264 is becoming widely used, and by the way, it is widely used. oh, and a lot of people use it.
  • ITU-R stuff: not exactly sure what to make of this, but I suspect this isn't really an application either, and moreover I doubt it is informative to most readers when the section begins to read like a summary of minutes of MPEG and the ITU...
  • itunes: ok, I don't mind this, but the last sentence is totally out of place and I'm deleting it.
  • Anyway, I suppose I'll hold off on my "threat" to slash away at the section next month if you indicate that you're not in favor of it. But I frankly do not see what's so informative about the section. I think that most readers would be able to get the same basic idea in far, far, far fewer words. Tell me what you think. Snacky 00:52, 5 October 2006 (UTC)

It looks like you already cleaned up the iTunes aspect. Let's next remove the list of individual Japanese broadcasters. -Mulligatawny 19:02, 5 October 2006 (UTC)

OK, done. Ultimately I might consider eliminating ALL (or nearly all) specific broadcaster mentions and replacing them with something like:
Terrestrial broadcasters in many countries in Europe, Asia, and the Americas have widely deployed H.264 for digital television broadcasts.
I also added some text summarizing the fact that standards bodies have been busy in responding to new codecs. Ideally I think we would keep this summary, and remove most or all of the specific examples. Note that I don't believe my summary is exceptionally well-written (I'm not exactly a poet), but it falls in line with my plans for making the section more informative and readable. Right now it's more like an information dump... not the best kind of material to learn from. Sort of reminds me of the crappy edits I used to make when I was new to WP :-( Snacky 01:04, 6 October 2006 (UTC)
The paragraph that you added looks good to me, although I think the swipe at MPEG-4 part 2 is not really necessary and should be removed. My impression is that the deployment process for H.264 is still unfolding and is really still in initial stages. In many cases the real usage is not quite yet there. It's true that the section is kind of an information dump, but it seems like a useful information dump. I don't know where else to get such a comprehensive and up-to-date listing. It all still fits on one screen, more or less, so it's not super hugely bloated. For the next step, I suggest merging the DoD and NATO adoptions into one sentence. Perhaps we could make the terrestrial broadcast comments about France, Brazil, Estonia, and Lithuania more coherent too (although there are some interesting details and newsworthiness there -- for example, I think the Brazil announcement was recent, and Brazil is a big place). -Mulligatawny 01:38, 6 October 2006 (UTC)
I went ahead and did the things I suggested above as next steps. -Mulligatawny 01:58, 6 October 2006 (UTC)
I also cut MPEG from the application section and trimmed the videoconferencing discussion. I guess I'm OK with your suggestion to drop ISMA, but I didn't do that yet. -Mulligatawny 02:10, 6 October 2006 (UTC)
I didn't intend to make a swipe at mpeg-4 part 2. It's just a fact (which is fairly well dissected on its article page) that it never had, and probably never will have, anything remotely approaching the adoption level that h.264 has already achieved. I also don't think this can be primarily explained by the technical merits.
How about this crazy, half-baked proposal - maybe there should be a timeline history section. Many of the entries in the applications section don't serve very well for summarizing how h.264 is used in the real world, but they do provide a picture of the history of its development and adoption. As a happy side-effect, the timeline would provide a place for people to focus their tendency to stuff lots of random news tidbits into the article. Which tends to obfuscate and clutter the section they're added to. But the timeline section won't easily suffer from that. I haven't put much thought into this, but I've long suspected that something along these lines would end up improving the quality of the article, particularly for people who are not already familiar with the subject matter. Snacky 02:17, 6 October 2006 (UTC)
Please consider shrinking font size in the tables down to 90-95%: they will fit better on the screen. --Cantalamessa 23:17, 8 October 2006 (UTC)

I think the section is very useful and perhaps not big enough as there are now a number of media organizations that are building business, technical and creative infrastructure around Part 10 (H.264). Even looking at the proliferation of new H.264 jobs [1] from Interactive, TV Networks and Aggregators you'll see that multiple platforms are adopting the technology quickly. H.264 is a catalyst that can drive new revenue streams for creative content and electronic equipment producers based on many advantages offered by the codec associated with quality and reduced bandwidth requirements. Some legacy media platforms could now find entry into digital distribution more palatable as CAPEX is relatively small compared to terrestrial distribution of similar content. As the assimilation of H.264 broadens the ROI of those disseminating will be substantial. Tony Filson —Preceding unsigned comment added by 70.18.199.90 (talk • contribs) 18:29, 5 October 2007

Xbox 360

Does anyone know if the Xbox 360 supports h.264? Given that they plan to support HD-DVD with an add on drive I would assume so. Of course they could add a chip to the drive but this seems unlikely since their Xenon should be more than capable. I would even suspect it might be supported by the 'OS' for games but maybe not given Microsoft will be trying to push WMV9. Nil Einne 17:37, 26 October 2006 (UTC)

Yes, it does (since it supports HD DVD). –Pangolin 04:01, 16 March 2007 (UTC)

4:4:4

The timeline in the Version section says High 4:4:4 profile was removed in view of developing a better replacement - is there any progress on that? Also, it mentions Enhanced 4:4:4 and Intra-only profiles - what are those and can they be added to the feature table in the Profiles section as well?

Since these changes happened no earlier than June 2006 and I've found no mention of the new profiles, I'm changing their status to "planned" . Feel free to clarify.

That work was finished (final design established in January 2007). The JVT document JVT-V204 is the completed new design. I just added a description of the new status including the 5 new profiles defined in that amendment. –Pangolin 04:00, 16 March 2007 (UTC)

PAFF and MBAFF

PAFF and MBAFF are mentioned in the article but without any definition. Such definitions should be added as the concepts seem important, and may already be defined but without their acronym. A Google search turned up the following:

  • MBAFF - MacroBlock-Adaptive Frame/Field coding
This sounds like it corresponds to the following item in the 'Features' section:

A macroblock pair structure (not supported in all profiles), allowing 16x16 macroblocks in field mode (vs. 16x8 half-macroblocks in MPEG-2) for effective handling of interlaced video.

  • PAFF - Picture-Adaptive Frame/Field coding
I don't know if this feature is already mentionned somewhere (I didn't recognize it if it is).

Please, whoever is knowledgeable about H.264 add these to the article.

Fgouget 11:23, 12 December 2006 (UTC)

I just added a description of them. –Pangolin 03:57, 16 March 2007 (UTC)

Copyvio?

Large sections seem to be taken verbatim from here... 213.143.18.224 11:35, 11 January 2007 (UTC)

At the bottom of the page, it says this: * The above text is quoted from Wikipedia. I think that answers it... The chicken came before the egg. — jesup 16:53, 11 January 2007 (UTC)
Fair enough, should have read further :o) 213.143.18.224 15:02, 16 January 2007 (UTC)

Jury Rules That H.264 is Not Patented

The seccion related with H.264 patent could be updated with this information [2] --80.174.14.90 18:58, 27 January 2007 (UTC)

Note that the court has not issued any ruling on the jury's verdict (as of 2/15/2007), which was advisory only as to patent validity. The court has not "acted," i.e. there has been no decision, until the judge has ruled. —Preceding unsigned comment added by 64.157.7.133 (talk • contribs)

Also to further clarify, the jury didn't say that H.264 isn't patented. They just said that they thought some particular patent didn't apply to it (or at least didn't apply to Broadcom's implementation of it). –Pangolin 04:29, 16 March 2007 (UTC)

I believe there is too much junk in the external links. What do you think? Does someone want to take a stab at categorizing the links into subsections? That would make it easier to see what meets with wp:el. Daniel.Cardenas 16:38, 26 April 2007 (UTC)

Slice

Would be nice if someone created a page describing slice. What do you think? Daniel.Cardenas 17:50, 11 May 2007 (UTC)

Excessive hardware requirements?

http://www.hardwired.hu/bigdl/2/9/trailer_order_of_the_phoenix_hd_720p.mov http://www.hardwired.hu/bigdl/2/9/trailer_order_of_the_phoenix_hd_480p.mov

These are two Harry Potter 5 movie trailes in Apple MOV.264 format (108MB and 45MB) and it appears any PentiumIII machines is unable to play them fluidly, at least the 720 version still skips even on the toppest-notch Tualatin core Pentium IIIS-1400MHz CPU with 512kB onboard cache in a rare P3-class but DDR200 memory powered motherboard with 768MB of RAM and an ATI9800Pro VGA card in an AGP4x slot, WinXP SP2, latest Quicktime 7.16.200 player. That is crazy, such computing burden cannot be expected!

What do you need, a Core2Quadro with 4GB RAM and dual ATI-X1950X VGA? The IBM compatible PC hardware requirements for viewing and creating H264 content should be mentioned in the article. 82.131.210.162 13:09, 15 May 2007 (UTC)

Unfortunately there is no such thing as one set of hardware requirements - it depends on too many things (video card speed and type, exact drivers being used, which OS, CPU type and speed, and what software is used to play it back). And we haven't even started talking about what resolution or frame rate the video might be. Perhaps you could add a sentence or two which describes in the generic sense that it requires considerable processing power, with some streams dropping frames even on some of the state-of-the-art Core 2 Duo processors. Mrand 15:03, 15 May 2007 (UTC)
The amount of RAM is certainly fairly irrelevant, 64 MiB or even less should be sufficient. Well, maybe Windows doesn't even boot with that little nowadays but that's a different story. When the MP3 codec was released, PCs were barely fast enough to play it back in real-time. In order to play the newest games PC owners have to upgrade at least once per year, so it's anything but surprising that a new and highly improved video codec would be a burden for older systems for a few years. That's why you'll almost always find a lo-fi version as well for now. --217.87.114.140 09:16, 26 July 2007 (UTC)

Pronunciation?

How do people pronounce H.264? "aitch dot two sixty four"? "aitch two six four"? Some other way? Any sources on this? TomTheHand 17:32, 24 July 2007 (UTC)

I've always heard "aitch two six four". --Cantalamessa 14:46, 25 July 2007 (UTC)
Not specifically for H.264, but for voice standards and lots of other telecom standards, I think I've heard it said both ways. Personally, I say "dot", but never say "dash" (as in GR-1244). —Mrand T-C 15:47, 25 July 2007 (UTC)
So would you say "two six four" or "two sixty four"? TomTheHand 15:50, 25 July 2007 (UTC)
Sorry - I missed that part of the question! Most people I know say "two sixty four". For G.707, I believe I've heard both "gee dot seven oh seven" and "gee seven zero seven". —Mrand T-C 13:46, 26 July 2007 (UTC)
Thanks! There are a lot of technical terms that I've only read and never discussed with people face-to-face; I've often wondered how others say them. TomTheHand 14:30, 26 July 2007 (UTC)
I believe the way I have mostly heard it is "aitch dot two six four". In casual contexts where people know what you're talking about, I've sometimes heard the "dot" omitted and sometimes I've even just heard "two six four" all by itself. As for "six" versus "sixty", I think I've heard both, but I think usually "six". —SudoMonas 16:07, 26 July 2007 (UTC)
The more prevalent is without the dot, "aitch two six four", "gee seven two nine" (G.729), etc Simaocampos (talk) 15:30, 4 June 2008 (UTC)

lossless?

i'm trying to figure out whether or not the video is lossless. if you have h.264 on your computer and you render it, is there ANY quality loss? --AlexOvShaolin 18:55, 13 October 2007 (UTC)

I guess it isn't very clear from the article, is it? The AVC High Profile has an optional lossless mode. Maybe you'd like to make it clearer?—Mrand T-C 21:11, 13 October 2007 (UTC)
that would be great, i was able to find the answer on doom9 though. --AlexOvShaolin 22:23, 18 October 2007 (UTC)
Actually all profiles support some form of lossless macroblock representation (called the I_PCM macroblock type). Additionally, three of the "professional" profiles support a more efficient (i.e. fewer bits needed for the representation) lossless macroblock mode (qpprime_y_zero_transform_bypass_flag equal to 1). Those profiles are the "High 4:4:4 Predictive", "High 4:4:4 Intra" and "CAVLC 4:4:4 Intra" profiles. The lossless modes are not ordinarily intended for coding the entire video sequence that way. See the "features" section of the article where some of this is mentioned (with less detail). Typical usage is not "mathematically lossless". As a word of warning, note that some people use a concept of "visually lossless" when they say "lossless", rather than the more strict idea of "mathematically lossless". The term "visually lossless" just means that most people won't see a significant visual difference. Pangolin (talk) 20:12, 14 December 2007 (UTC)

Removed a link to a blog that consists entirely of material ripped off from my website (www.vcodex.com). Vcodex 15:08, 2 December 2007 (UTC) Iain Richardson.

Shameful! I wonder how we can blacklist that site. Daniel.Cardenas 18:00, 2 December 2007 (UTC)
Archive 1Archive 2Archive 3
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Advanced_Video_Coding/Archive_1&oldid=1136499471"