Jump to content

Talk:Advanced Video Coding: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Fgouget (talk | contribs)
PAFF and MBAFF
No edit summary
Line 398: Line 398:


[[User:Fgouget|Fgouget]] 11:23, 12 December 2006 (UTC)
[[User:Fgouget|Fgouget]] 11:23, 12 December 2006 (UTC)

==Copyvio?==

Large sections seem to be taken verbatim from [http://mediacoder.sourceforge.net/glossary/H264.htm here]... [[User:213.143.18.224|213.143.18.224]] 11:35, 11 January 2007 (UTC)

Revision as of 11:35, 11 January 2007

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)

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

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)[reply]

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)[reply]
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)[reply]

"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)[reply]
"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)[reply]
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)[reply]
"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)[reply]
"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)[reply]
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)[reply]

"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)[reply]

"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)[reply]
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)[reply]
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)[reply]

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)[reply]

"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)[reply]

"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)[reply]

"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)[reply]

"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)[reply]

"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)[reply]

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)[reply]

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)[reply]

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. Tnikkel

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)[reply]
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? Tnikkel 22:03, 25 February 2006 (UTC)[reply]
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)[reply]

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)[reply]

"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)[reply]

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)[reply]


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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

Levels

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

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)[reply]
I too came looking for an explanation on Levels. Hoping someone elaborates... Will check back after a few days... [Pramod Kaluskar]
"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)[reply]

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 ?

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. Tnikkel 07:44, 30 April 2006 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
I went ahead and did the things I suggested above as next steps. -Mulligatawny 01:58, 6 October 2006 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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.

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)[reply]

Copyvio?

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