Jump to content

Talk:Advanced Video Coding

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Wikifier (talk | contribs) at 23:15, 9 February 2010 (Putting the geekspeak at the bottom). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Apple iPod?

The Apple iPod and iTouch/iPhone all support a version of the H.264 codec called "low-complexity" baseline. Even though this is not an approved profile, it would seem documenting this is pretty important given the ubiquitos nature of the Apple products. —Preceding unsigned comment added by 131.107.0.101 (talk) 18:04, 11 September 2008 (UTC)[reply]

Reply: However, this is a wiki about the standard of h.264. The standard does not define a low-complexity baseline profile. It may still be worth mentioning. ALSO there is now the Constrained Baseline Profile (CBP) listed as profile, which is as well not a part of the specifications. AFAIK. If someone could point me to the ITU-T h.264 document and page where the CBP is described? —Preceding unsigned comment added by Oliver.stampfli (talkcontribs) 02:17, 9 December 2008 (UTC)[reply]

Regarding the "Constrained Baseline Profile", please see JVT-AC204. —Mulligatawny (talk) 20:37, 9 December 2008 (UTC)[reply]

See M4V for details. ToxicWasteGrounds (talk) 17:39, 18 January 2010 (UTC)[reply]

CopyVio?

http://mediacoder.sourceforge.net/wiki/index.php/H.264 seems very similar —Preceding unsigned comment added by 98.207.199.32 (talk) 17:51, 1 April 2008 (UTC)[reply]

QuickTime H.264 capabilities are out of date

As of QuickTime 7.2 and later, additional H.264 features such as 8x8dct and other aspects of High Profile are now supported. I've added a couple of these myself, but a review would be good - there may be other H.264 features QuickTime now supports. - 209.91.141.250 (brad) 7 February 2008 EDIT: Now it's horrendously outdated; Quicktime is version 7.4. I did another update on Quicktime capabilities, but we need an expert here. June 28, 2009

Much too technical

There is such a thing as too much information. I'm sure videophiles would be thoroughly interested in reading about logarithmic step size control and macroblock-adaptive frame-field coding, but the average wikipedia user would leave this article feeling like they've learnt nothing more about H264. This article needs to be more like the WMV article, so that the user's most common questions (i.e. what is the quality like, how do I use it, where can I play it) can be answered. This article doesn't even have anything on subjective quality. —Preceding unsigned comment added by 58.107.140.52 (talk) 03:55, 18 December 2007 (UTC)[reply]

Seconded. I added a {{technical}} tag to the article. Could an knowledgeable individual please generalize it a bit for the mass audience? -Clueless (talk) 02:49, 15 April 2008 (UTC)[reply]
Wrong. It is a great article. You guys just need to learn more about this area to be able to understand it.-anon —Preceding unsigned comment added by 71.131.8.26 (talk) 19:56, 18 July 2008 (UTC)[reply]
I agree with anon. I think it's a darn good article, and I fear what an "improvement" might look like. —Pawnbroker (talk) 18:27, 19 August 2008 (UTC)[reply]
"You guys just need to learn more about this area to be able to understand it." Isn't that what Wikipedia is for? Isn't your argument a little circular? This article is far too technical for a mass audience. —Preceding unsigned comment added by 198.147.10.56 (talk) 20:55, 9 October 2009 (UTC)[reply]
The article really needs to stripped and summarized. MahangaTalk 19:18, 21 January 2010 (UTC)[reply]

ProSieben

ProSieben stopped broadcasting HDTV this year in february. —Preceding unsigned comment added by 82.83.90.225 (talk) 11:51, 24 February 2008 (UTC)[reply]

Hardware Requirement?

If your computer doesn't have at least a Pentium 4, the video will not play, or play right. Why is this not mentioned? —Preceding unsigned comment added by 75.185.14.219 (talk) 23:33, 12 March 2008 (UTC)[reply]

  • Because such a statement is completely incorrect, given that H.264 video can range in bitrate and resolution nearly arbitrarily. In terms of CPU requirement for playback, H.264 is probably not even 50% more than that of MPEG-4 ASP at the same bitrate. —Dark•Shikari[T] 02:23, 14 March 2008 (UTC)[reply]

codec's don't work that way, as u could easily decode it on any decent GPU regardless of your cpu. i've seen someone decode it on a Ati AGP GPU with a 733mhz Pentium3 @1080P~25mbps. video decoding can be completely done without a fast CPU, as long as there is some form of co-processor. Markthemac (talk) 06:38, 19 January 2009 (UTC)[reply]

Availability of the codec

The article doesn't answer the question where the codec is actually used. In fact, I think it is deliberately avoided as an issue, because the public isn't supposed to be able to get it from free sources, outside formal markets. It seems that the only consumer source is the commercial Quicktime Pro, but that isn't mentioned either. All other users are big corporations who have obviously bought hefty rights to use it. Someone fix this. EDIT: I found that the open source community's free Avidemux is able to save x264 files, which is somehow different from H.264, but still the same quality. Teemu Ruskeepää (talk) 07:35, 6 July 2008 (UTC)[reply]

Actually there's a lot of information in the article about where the codec is used. For example, see the "Applications" section of the article. There used to be more such information in the article, but people complained that there was too much of it, so a new article was created that's listed in the "See also" section: H.264/MPEG-4 AVC Products and Implementations. The remark about Quicktime Pro being the only consumer use of the standard is completely wrong. I believe the remark about x264 being substantially something different than H.264 is also wrong -- as far as I know, x264 is an implementation of H.264. The topic of how the standard is used by consumers isn't avoided - it's just that the purpose of the article is to provide information about the standard itself, not to list a bunch of implementations, to discuss the role of big corporations in modern society, or to promote some kind of open source agenda. —Pawnbroker (talk) 18:16, 19 August 2008 (UTC)[reply]

Chart on decoder

There is a chart on encoders, but not one on decoders. Can somebody start or add one. Decoders are of more interest to most people watching content. —Preceding unsigned comment added by 71.131.8.26 (talk) 23:07, 18 July 2008 (UTC)[reply]

All the variety is in the the encoders, the only place where decoders could differ would be decoding performance or platform support, not much scope there for a chart - Xedaf (talk) 21:43, 27 August 2008 (UTC)[reply]
That's actually not correct. Each "Profile" of the standard corresponds to a separate defined set of decoding features, as well as being a set of defined syntax that an encoder can use. See the chart of features supported for each Profile. In practice, there is also somewhat more variation in the decoding capabilities of various products than what is reflected in the profile/level structure that is specified in the standard. I suspect that the chart of encoder product capabilities is actually (at least partly) a chart of decoder capabilities. Pawnbroker (talk) 17:07, 2 September 2008 (UTC)[reply]

Infobox

There should be an info box about this codec to summarize it, and it should contain information about licensing and patents, so that this information as well as other things are available with a quick glance (the point of an infobox). Yfrwlf (talk) 20:07, 23 July 2008 (UTC)[reply]

Further ther is no mention of frame accuracy or use in editorial pipelines. I believe it is not frame accurate as it is a streaming codec. 09:15, 13 October 2009 —Preceding unsigned comment added by Bbeard78 (talkcontribs)

Penetration or Market Share

It would be great if this page, and others about codecs, either linked to or contained some information about how widely used the codec is. It would help in trying to figure out what codec to use to preserve a video. Granted, there are other factors involved, but one way to avoid digirot (by which I mean loss of information due to unavailability of software to decode it) is to select a widely-used codec. Szetlan (talk) 02:50, 11 December 2008 (UTC)[reply]

Software encoder feature comparison - multithreads ?

I suggest adding a new row into the table "Software encoder feature comparison". That is whether the codec can run in multiple threads. In todays world (2009 januar) most consumer CPUs (desktop PCs) are multicore. --Xerces8 (talk) 22:02, 26 January 2009 (UTC)[reply]

Streaming license

Is it true that they will be able to cash in from streaming websites starting 2011? I read this article but am none the wiser. --87.162.37.135 (talk) 16:02, 27 April 2009 (UTC)[reply]

I'm not sure what's special about 2011, but the patent holders of the technology used in H.264 encoders and decoders can "cash in" any time they want if the software (or hardware) hasn't been licensed by them. Just like Visto "cashed in" (to the tune of 3.6 million) by suing the makers of BlackBerry devices (RIM). Now whether a patent infringement claim is actionable and whether any action will ever be taken are two different things. I'd wager that if the holders of the H.264 patents ever believe that their bottom line is being harmed more than they would gain from litigation over unlicensed use of their technology, we would see litigation pretty quickly. I don't think there are any specific patents that cover simply hosting / distributing H.264 content though, so websites should be safe (unless they are encoding uploaded videos to H.264 using unlicensed software). INAL, just my personal understanding. 64.234.67.2 (talk) 11:38, 24 May 2009 (UTC)[reply]
They've decided to charge fees starting from 2016. Initially, the cut date was the end of 2010. See http://yro.slashdot.org/story/10/02/03/1528242/MPEG-LA-Extends-H264-Royalty-Free-Period?art_pos=1 and http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/226/n-10-02-02.pdf (pdf file) Mariushm (talk) 16:29, 3 February 2010 (UTC)[reply]

RapiHD

RapiHD doesn't seem to be a software-only encoder. It should be listed under hardware assisted encoders. - xpclient Talk 06:23, 2 August 2009 (UTC)[reply]

Update to the "Levels" section of the main page

Regarding the "Levels" section, it doesn't inform anyone on how to figure the maximum reference frames of an arbitrary resolution in conjunction with a chosen BP/MP/HP Level. I'd like to propose the following formula and include a reference to the h.264 standard for Chart A-1 which is necessary to calculate the equation. While technical, it isn't explained in the most technical detail, only the parts that are necessary to do the math. I often see the question asked "How many Reference Frames Can I use?" and there hasn't been a definitive answer; at least not on Wikipedia.

Formula to determine Maximum Reference Frames:

(min (1024 * maxDPB / (PicWidthInMBS * FrameHeightInMBS * 384), 16)

A more practical, and fool-proof way to interpret this would be:

ROUNDDOWN (MIN (1024 * maxDPB/(((Width * Height) / 256) * 384), 16), 0)

Example1: Level 4.1, 720x480 video:

ROUNDDOWN (MIN (1024 * 12288/(((720 * 480) / 256) * 384), 16), 0) = 16 Reference Frames Max

Example 2: Level 3, 720x480 video:

ROUNDDOWN (MIN (1024 * 3037.5/(((720 * 480) / 256) * 384), 16), 0) = 6 Reference Frames Max

Below is a table of appropriate maxDPB values:

Level
1
1b
1.1
1.2
1.3
2
2.1
2.2
MaxDPB
148.5
148.5
337.5
891
891
891
1782
3037.5
Level
3
3.1
3.2
4
4.1
4.2
5
5.1
MaxDPB
3037.5
6750
7680
12288
12288
13056
41400
69120

References:
[h.264 Spec] Ttmcmurry (talk) 19:14, 27 October 2009 (UTC)[reply]

Constrained baseline profile

The text refering to constrained baseline profile "widely used" is incorrect. That profile was introduced as part of the March 2009 version of the H.264 standard, which would be way too recent for widespread adoption considering H.264 has been part of many video conferencing systems since about 2005. -- 64.254.110.34 (talk) 23:22, 5 January 2010 (UTC)[reply]

I removed that statement, although it may not have been completely incorrect. Although the formal profile definition for the "constrained baseline profile" within this standard is relatively recent, its definition consists of a subset of the tools features supported in the existing "baseline profile". In fact all "constrained baseline profile" bitstreams are also "baseline profile" bitstreams. This is actually discussed in the standard (in a note in the section defining the "constrained baseline profile"). Both profiles use the same profile identification code number (profile_idc = 66). The usage of the tool subset that is now defined as "constrained baseline profile" actually did exist before that subset was officially recognized as a profile of the standard. I clarified this in the article. -Mulligatawny (talk) 02:30, 6 January 2010 (UTC)[reply]


Putting the geekspeak at the bottom

What do you all think about putting all the tech stuff at the bottom and move patents, success and applications to the top? Seems more logical. I came here to read about the patent and had to scroll through a bunch of tech stuff. --Wikifier (talk) 23:15, 9 February 2010 (UTC)[reply]