Talk:Advanced Video Coding/Archive 3

Archive 1

Archive 2

Archive 3

Usage in CCTV

I've added this to get people's opinions on the text which is repeatedly added and removed.

According to the MPEG group: “Generally speaking it is an unsafe policy to use these codecs for highly sensitive applications. For example, when taking a recording of an event and requiring a high resolution single frame (as might be the requirement in many circumstances) the possibility of achieving this with MPEG/H264 is unlikely – street scenes, shopping mall and anywhere single frame close identification is required should NOT be recorded using MPEG/H264 codecs. It should be noted that the MPEG committee is mainly concerned with video and audio for entertainment”.

With the following assertion made by Ravana 999 "The quote is from 2004 and the tests were done in 2002 long before H.264 existed, this is simply not true today."

My opinion is that it may have been true at the time but the quality of encoders have greatly improved since then. So it should either be added with a statement to the effect of "This study from 2002 lead to this statement from 2004". J Darnley (talk) 14:02, 10 June 2011 (UTC)

References

My problem with this added text is that I believe there is a conflict-of-interest issue involved. The user continually re-adding it is a Single Purpose Account, and in my opinion they are adding the statement so that the existence of the text in this article reinforces their own company's sales pitch. Now that I know that the study is also outdated and likely incorrect, I see no reason for the statement to remain. --| Uncle Milty | talk | 14:52, 10 June 2011 (UTC)

I agree, there is a possible conflict, just look at the link used as source form the "ipsurveillance" user. Cantalamessa (talk) 22:43, 10 June 2011 (UTC)

I strongly suspect that the MPEG group never actually said what the referenced document claims that they said. The document does not provide a link to where the statement can be found on MPEG's web page, or a reference to any particular MPEG committee document number in which the statement can be found. In a web search for the quoted statement, all I find is a few things all apparently published by that same CCTV company/person. —Mulligatawny (talk) 23:18, 20 June 2011 (UTC)

I am the author of the paper quoted here, the statement came as a response to a number of questions raised by the UK IP User Group to the MPEG committee. I have no axe to grind we do not supply recording systems, we simply provide interconnectivity. I am not sure why anyone would think we as a group would make that up? — Preceding unsigned comment added by Polarismd (talk • contribs) 21:06, 22 May 2014 (UTC)

ALL-INTRA

Please someone elaborate in the article what ALL-INTRA USE means. 82.80.117.203 (talk) 10:32, 8 September 2011 (UTC)

It means only intra frames are allowed. J Darnley (talk) 09:49, 9 September 2011 (UTC)

Since no other comments have been added, I'm going to change the wording in that section. J Darnley (talk) 10:55, 1 October 2011 (UTC)

Hi10P

There is a redirect from Hi10P but nothing on Hi10P in the Artikle. — Preceding unsigned comment added by 95.112.155.148 (talk) 10:35, 28 September 2011 (UTC)

Yes there is, the High 10 profile: H.264/MPEG-4_AVC#Profiles. Whether this warrants the redirect is another matter. Is there anything else that "Hi10P" is used with/for? — Preceding unsigned comment added by J Darnley (talk • contribs) 17:47, 28 September 2011 (UTC)

If it's any bearing, none of the textual profile "codes" are mentioned in the 04/2013 version of the H.264 spec. I nearly removed them but saw they were used in the table and assumed they were just references in this article. --Dee Earley (talk) 11:08, 26 September 2014 (UTC)

"Profiles" section begins as gibberish, then deteriorates

The "Constrained Baseline Profile (CBP)... corresponds to the subset of features that are in common between the Baseline, Main, and High Profiles" and the "Baseline Profile... includes all features that are supported in the Constrained Baseline Profile, plus three additional features..." Sheesh! Could someone who actually knows something about H.264 please replace the "facts" in this section with some facts? Yappy2bhere (talk) 06:44, 28 November 2011 (UTC)

Heavy hardware requirements

I think something more should be mentioned about hardware requirements. My laptop has a Pentium 3 CPU and it can not decode H.264. Fewer and fewer Youtube videos is working, the majority is now only playing sound without motion pictures. A Pentium 3 CPU does not meet the hardware requirements and the article could mention the high demand on CPU resources, perhaps mention what the minimum requirements are. Urbanus Secundus (talk) 23:19, 20 December 2011 (UTC)

In a nutshell?

It would be useful if there was an "in a nutshell" of what the basic specs are for H.264/MPEG-AVC, or the possible defaults. So when someone comes to look at their settings, they can know what it would/could be. — billinghurst sDrewth 13:12, 20 January 2013 (UTC)

User experience

So often these types of articles focus on esoteric details, and this becomes the norm on Wikipedia. I think it is appropriate to have a section for ordinary users in ordinary language. For example, what browsers and media players presently accommodate this format, is the format supported natively or does it require add-ons, what is the timeline, will there be changes in image quality, is this format backwards compatible with older formats, or to put it another way, what formats will be unplayable or obsolete. I also like the suggestion by Urbanus Secundus to discuss the hardware implications. 3dimen (talk) 03:35, 21 January 2013 (UTC)

Yeah, and also, how we'll does the format compress? Not a mention anywhere of compression ratios. Incredible. — Preceding unsigned comment added by 75.156.118.183 (talk) 20:08, 23 March 2013 (UTC)

Controversies

Some Wikipedia editors, such as myself, prefer not to have a section titled "controversies", "criticisms", etc. -- see the WP:CSECTION essay. We recommend moving all the information currently in the "Controversies" section and to some other appropriate section of the article. --DavidCary (talk) 05:52, 18 January 2014 (UTC)

One possibility would be to change the heading from "Controversies" to "Usage in HTML5 and web browsers", and slightly adjust the content of the section to fit that topic. That's basically what is discussed in the section currently. —Mulligatawny (talk) 19:05, 12 June 2014 (UTC)

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was to keep both articles—J. M. (talk) 00:19, 24 June 2014 (UTC)

---

I propose that MPEG-4 be merged into H.264/MPEG-4 AVC. I think that the content in the MPEG-4 article is already covered by the H.264/MPEG-4 article, and the H.264/MPEG-4 article is more developed.Keithicus (talk) 15:01, 11 June 2014 (UTC)

• Oppose - AVC is only a subset of MPEG-4, which includes other video and audio compression standards, container format and more (see the MPEG-4 Parts). These things are not and cannot be covered by the AVC article. I find this merger proposal nonsensical.—J. M. (talk) 01:37, 12 June 2014 (UTC)
• Oppose - MPEG-4 covers the full suite of audio, video, and container formats developed under MPEG-4 umbrella, while this article only covers one specific part of the suite, that is MPEG-4 Part 10 "Advanced Video Coding". It makes no sense to merge them, no matter which article is more developed, they should remain separate entities. --95.25.221.124 (talk) 19:22, 17 June 2014 (UTC)

• Oppose - My reason for opposition is the same, MPEG-4 is a superset to AVC/H.264. MPEG-4 is a FAMILY of AV standards, where as AVC/H.264 is a standard of video "V" coding. Pardon my word I'm so damned seeing this merger suggestion, I think you should take more time researching the topic before suggest something like this. Dannyniu (talk) 11:48, 23 June 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Reference for edit ([2])

For correcting the two max stored frames values in table "Levels with maximum property values" I referred to "Table A-7 – Maximum DPB size (frames) for some example frame sizes" in . Seeing that specified values in the article are already largely sourced from this specification, and that inline citations only for the two changed values would have stood out, I didn't add any in the article. I trust this is in order, but please feel free to let me know if anything else is needed. Thanks. Fvisagie (talk) 16:01, 11 September 2014 (UTC)

References

I confirmed that your edit matches the spec. That error seems to have been there ever since the maximum DPB size examples were added to the article (July 2006). At the time, that editor said "need to double-check". One or two errors in that edit were fixed soon after that, but I guess those two were overlooked for more than eight years! —Mulligatawny (talk) 21:09, 11 September 2014 (UTC)

Thanks for the confirmation, much appreciated. —Fvisagie (talk) 13:02, 12 September 2014 (UTC)

Corrections to errors inherited from Rec. H.264

In the table "Levels with maximum property values" this article has inherited from Recommendation H.264 the errors listed below. I have reported the Recommendation errors to the ITU who have confirmed them, and I'd like for the corrections to be transferred to this article. Wikipedia would require me not to use my own findings, but a reviewed and published source instead. The corrected Rec. H.264 would of course be the obvious candidate. However, the ITU has indicated that completing and publishing the current prepublished edition "may take a while".

In light of that, what would be the recommended approach here? Is there some other acceptable way of establishing verifiability in the interim - in this case perhaps presenting the findings for review on the x264 discussion board?

Thanks in advance, François

Errors confirmed by ITU

(Table names refer to the Rec. H.264 document)

The errors include but are not necessarily limited to:
1. In Table A-6 the maximum frame rates for the following formats are too high by one decimal value for the given level. This possibly resulted from rounding up calculated maximum frame rate values before publishing. Since I did not recalculate all maximum frame rate values there may be more such errors than those listed here:
1.1. Maximum frame rate for CIF 352 288 to conform to level 1.2 should be 15.1
1.2. Maximum frame rate for 525 HHR 352 480 to conform to level 2.2 should be 30.6
1.3. Maximum frame rate for 625 HHR 352 576 to conform to level 2.2 should be 25.5
1.4. Maximum frame rate for 525 HHR 352 480 to conform to level 3 should be 61.3
1.5. Maximum frame rate for 625 SD 720 576 to conform to level 3.1 should be 66.6
1.6. Maximum frame rate for SXGA 1280 1024 to conform to level 3.2 should be 42.1
1.7. Maximum frame rate for 720p HD 1280 720 to conform to level 4 should be 68.2
1.8. Maximum frame rate for 720p HD 1280 720 to conform to level 4.1 should be 68.2
1.9. Maximum frame rate for 720p HD 1280 720 to conform to level 4.2 should be 145.0
1.10. Maximum frame rate for 1080 HD 1920 1088 to conform to level 5 should be 72.2
1.11. Maximum frame rate for 2Kx1080 2048 1088 to conform to level 5 should be 67.7
1.12. Maximum frame rate for 1080 HD 1920 1088 to conform to level 5.1 should be 120.4
1.13. Maximum frame rate for 4096x2160 4096 2160 to conform to level 5.1 should be 28.4
1.14. Maximum frame rate for 4096x2304 (16:9) 4096 2304 to conform to level 5.1 should be 26.6
1.15. Maximum frame rate for 4Kx2K 4096 2048 to conform to level 5.2 should be 63.2
1.16. Maximum frame rate for 4096x2304 (16:9) 4096 2304 to conform to level 5.2 should be 56.2
2. In Table A-6 the MBs Total and Luma Samples values for the following format is incorrect. This also gives rise to secondary errors with the maximum frame rate values for the format at the various levels. Since I did not recalculate all MBs Total, Luma Samples and maximum frame rate values there may be more such errors than those listed here:
2.1. For 3840x2160 3840 2160, instead of 31 035 and 7 948 800, MBs Total and Luma Samples should be 32 400 and 8 294 400, respectively.
2.1.1. Maximum frame rate for 3840x2160 3840 2160 to conform to level 5.1 should be 30.3
2.1.2. Maximum frame rate for 3840x2160 3840 2160 to conform to level 5.2 should be 64.0
—Fvisagie (talk) 15:39, 12 September 2014 (UTC)

What is block-oriented?

I can't find any explanation of what this means and it wasn't something I could easily google. Perhaps this is explained on another page with a different name that could be linked to? — Preceding unsigned comment added by 212.105.160.109 (talk) 10:06, 8 July 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on H.264/MPEG-4 AVC. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20100307022217/http://www.apple.com:80/quicktime/technologies/h264/faq.html to http://www.apple.com/quicktime/technologies/h264/faq.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 13:39, 17 October 2015 (UTC)

CPU Usage

Try as I might, NOBODY seems to have compared video-codecs in terms of quality (error-rate from original, uncompressed video) and of CPU power. NOWHERE gives a core-mark or Dhrystones value for this and all of the other codecs — Preceding unsigned comment added by 213.106.56.145 (talk) 16:51, 21 October 2015 (UTC)

The main issue with that is you have two metrics you can use to measure quality: subjective comparison (which will vary per viewer based on eyes, display tech, etc), or a calculation like PSNR and SSIM which don't indicate visual quality well.Plonk420 (talk) 18:37, 15 December 2017 (UTC)

Maximum Number of Reference Frames

My earlier edit regarding the maximum number of reference frames had an error in it. I investigated more carefully and chose the following wording, which I will justify.

In profiles that support non-IDR pictures, most levels specify that sufficient buffering should be available to allow for at least 4 or 5 reference pictures at maximum resolution.

I believe this is accurate, and useful. But if not, please feel free to fix or revert it.

My evidence is that the official MPEG4 Part 10 document for H.264 (i.e. ISO 14496-10) says the following in section 7.4.2.1.1 (Sequence parameter set data semantics):

The value of max_num_ref_frames shall be in the range of 0 to MaxDpbFrames (as specified in subclause A.3.1 or A.3.2), inclusive.

A.3.1 (Level limits common to the Baseline, Constrained Baseline, Main, and Extended profiles) gives MaxDpbFrames as:

Min( MaxDpbMbs / ( PicWidthInMbs * FrameHeightInMbs ), 16 ) and MaxDpbMbs is given in Table A-1

A.3.2 (Level limits common to the High, Progressive High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra, and CAVLC 4:4:4 Intra profiles) gives the same wording for MaxDpbFrames, although in the case of intra, one may suppose that is relevant only to buffering, since there is no inter-frame prediction.

Table A-1 notes that for level 1, MaxDpbMbs is 396. Thus, even for level 1's max frame size of 99 macroblocks (176x144), this would allow for 4 reference frames, as opposed to 1 (or 16 as I had incorrectly concluded), assuming I understand the spec correctly. The other levels all seem to allow for 4 or 5 frames (except, inexplicably 1b).

JMCorey (talk) 23:48, 13 January 2016 (UTC)

Update: I just discovered I was looking at an outdated copy of the spec. A later version says:

MaxDpb Size is equal to Min( 1024 * MaxDPB / ( PicWidthInMbs * FrameHeightInMbs * 384 ), 16 ) and MaxDPB is given in Table A-1 in units of 1024 bytes.

Redoing the calculations, the result is similar:

• Level 1 min 4.0 frames
• Level 1b min 4.0 frames
• Level 1.1 min 2.3 frames
• Level 1.2 min 6.0 frames
• Level 1.3 min 6.0 frames
• Level 2 min 6.0 frames
• Level 2.1 min 6.0 frames
• Level 2.2 min 5.0 frames
• Level 3 min 5.0 frames
• Level 3.1 min 5.0 frames
• Level 3.2 min 4.0 frames
• Level 4 min 4.0 frames
• Level 4.1 min 4.0 frames
• Level 4.2 min 4.0 frames
• Level 5 min 5.0 frames
• Level 5.1 min 5.0 frames

JMCorey (talk) 02:31, 14 January 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on H.264/MPEG-4 AVC. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20110807103348/http://www.atsc.org/cms/standards/a_72_part_1.pdf to http://www.atsc.org/cms/standards/a_72_part_1.pdf
• Added archive https://web.archive.org/web/20110726151422/http://atsc.org/cms/standards/a153/a_153-Part-7-2009.pdf to http://atsc.org/cms/standards/a153/a_153-Part-7-2009.pdf
• Added {{dead link}} tag to http://www.xavc-info.org/resource/1351573070000/xavcsite/share/data/XAVC_30-Oct-2012_NewsRelease.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:41, 27 October 2017 (UTC)

H.264+

Suggest include information about H.264+. BoldLuis (talk) 20:35, 3 July 2018 (UTC)

What does that mean? Perhaps you are thinking of H.263+? That's a different topic – something that was done earlier. Mulligatawny (talk) 22:58, 3 August 2019 (UTC)

Requested move 3 August 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: consensus to move to Advanced Video Coding. There is unanimous consensus that the title should be changed. Only the nominator and one other commenter expressed a preference for H.264, and neither of them has responded to the newer proposal. (non-admin closure) KSFT ^(t|c) 20:16, 25 August 2019 (UTC)

---

H.264/MPEG-4 AVC → H.264 – WP does not put alternative names/titles, after a slash or other punctuation, into the article title. Such other terms are created as redirects instead. This article should be at the most common name for the subject, which is H.264. The MPEG-4 AVC string isn't even really a name, anyway, but an abbreviation of one. 66.167.126.10 (talk) 16:08, 3 August 2019 (UTC) --Relisting. Dicklyon (talk) 23:51, 11 August 2019 (UTC)

• Support Rreagan007 (talk) 17:30, 3 August 2019 (UTC)
• Comment: As can be seen in the list of cited sources, it is actually common to use the slash format as the name of this standard – either "H.264/MPEG-4 AVC" or "H.264/AVC" or "MPEG-4 AVC/H.264" or "AVC/H.264" or similar – e.g., see this, this, this, this, this, this, this, this, this, this. The naming is a somewhat sensitive topic for some people, since the standard was a joint project of two organizations. Mulligatawny (talk) 22:54, 3 August 2019 (UTC)
• Support. Unlike with HEVC, the name Advanced Video Coding or the shorthand AVC aren't how the video format is most widely known for. H.264 is by far the most common name. The more "human-readable" version has only gained a little bit more popularity since H.265 has become more widely known, probably to distinguish it better from its successor with which it shares a very similar technical name starting with H.26. But still, even when the name AVC is used, more often than not in the same context it's also referred to as H.264. And basically nobody uses the full human-readable name Advanced Video Coding. --Veikk0.ma 11:43, 13 August 2019 (UTC)
• Oppose: I strongly oppose changing the title to H.264. However I would support changing the title to the formal name Advanced Video Coding which is similar to what the article High Efficiency Video Coding is using.DavidDelaune (talk) 02:19, 5 August 2019 (UTC)

• I would also support a move to Advanced Video Coding. Rreagan007 (talk) 18:47, 6 August 2019 (UTC)
• I also support a move to Advanced Video Coding. That would be more in-line with the Advanced Audio Coding and High Efficiency Video Coding articles. Maestro2016 (talk) 05:10, 8 August 2019 (UTC)
• Support move to Advanced Video Coding. Recognisable, common, consistent. By far the best suggestion. Andrewa (talk) 11:44, 19 August 2019 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.