Talk:Video codec

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Software / Hardware (Rated Start-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as High-importance).
Taskforce icon
This article is supported by Computer hardware task force (marked as High-importance).
 

Video Codec Benchmarking[edit]

Video Codec Benchmarking is span isn't it? Shouldn't it be removed. —Preceding unsigned comment added by 84.64.1.148 (talk) 12:25, 27 January 2008 (UTC)

Various remarks by "Evan"[edit]

Hi all, while a lot of the very technical, math-heavy details that are in this article are beyond the scope of my knowledge, I am pretty familiar with video codec use in the real world, particularly in professional editing applications, and some details of the following little paragraph rang untrue to me:

A typical digital video codec design starts with conversion of camera-input video from RGB color format to YCbCr color format, and often also chroma subsampling to produce a 4:2:0 (or sometimes 4:2:2 in the case of interlaced video) sampling grid pattern. The conversion to YCbCr provides two benefits: first, it improves compressibility by providing decorrelation of the color signals; and second, it separates the luma signal, which is perceptually much more important, from the chroma signal, which is less perceptually important and which can be represented at lower resolution (hence the 4:2:0 or 4:2:2 sampling grid use).

First of all, there are to my knowledge video codecs that claim to be RGB, and not YUV or YCbCr (e.g. Kona's 10-bit RGB uncompressed codec, which I am rendering to right now, or Apple's Animation codec, which also supports an alpha channel). Are these all going back to YCbCr internally? I've never read anything to suggest this, but perhaps I'm wrong on this point? Also, the camera input as RGB strikes me as a little iffy as well but I know too little to feel OK changing that. What about the bayer-pattern data stored in RAW files/codecs? This isn't quite RGB yet, is it?

However what really rang strange to me was the statement about 4:2:0 and 4:2:2. While it's true that these are common, I feel the language to be misleading; these are simply two out of many choices of chroma sampling algorithms, right? While I have tried to make this less misleading, I also acknowledge that my knowledge of how the x:y:z figures for different video compression schemes are produced is not entirely accurate and that there is more here to be done by someone like Grame Nattress who actually writes these things. What are billed as 4:2:2 HD video codecs, for example, I think are supposed to be like 22:11:11, not 4:2:2, I think due to the numbers being related to data rates?

Anyway, here's what I left it with:

Video codecs seek to represent a fundamentally analog data set in a digital way. Because of the design of analog video signals, which represent luma and color information seperately, a common first step in image compression in codec design is to represent and store the image in a YCbCr color space. The conversion to YCbCr provides two benefits: first, it improves compressibility by providing decorrelation of the color signals; and second, it separates the luma signal, which is perceptually much more important, from the chroma signal, which is less perceptually important and which can be represented at lower resolution to achieve more efficent data compression. It is common to represent the ratios of information stored in these different channels in the following way Y:Cb:Cr. Refer to the following article for more information about Chroma subsampling.

Different codecs will use different ratios as appropriate to their compression needs. Video compression schemes for Web and DVD use make use of a 4:2:0 color sampling pattern, and the DV standard uses 4:1:1 sampling ratios. Professional video codecs designed to function at much higher bitrates and to record a greater amount of color information for post-production manipulation sample in 3:1:1 (uncommon), 4:2:2 and 4:4:4 ratios. Examples of these codecs include Panasonic's DVCPRO50 and DVCPROHD codecs (4:2:2), and then Sony's HDCAM-SR (4:4:4) or Panasonic's D5 (4:4:4). Apple's new Prores HQ 422 codec also samples in 4:2:2 color space. More codecs that sample in 4:4:4 patterns exist as well, but are less common, and tend to be used internally in post-production houses. It is also worth noting that video codecs can operate in RGB space as well. These codecs tend not to sample the red, green, and blue channels in different ratios, since there is no perceptual motivation for doing so.

I also added a little bit about wavelet transforms since I know Cineform uses that and I think it's what REDcode is too, so it's worth mentioning I think.

-Evan


thank you —Preceding unsigned comment added by 192.197.166.162 (talk) 14:13, 6 September 2007 (UTC)

Spyware in links[edit]

I am concerned that some spyware makers are intentionally putting links to their wares by making it seem that they are legitimate programs. I tried to download and install VideoInspector and I was warned about some spyware (Spyware.Marketscore) in my system.

I do not know how to take the link out, but if there are some editors out there who can, it will be a benefit to everyone.Gryphon Hall (talk) 00:51, 28 October 2008 (UTC)

Pictogram resolved.svgResolved: MPEG-1, MPEG-2 and MPEG-4 as codecs[edit]

Greetings, everyone. I have recently undone a recent edit by J.M. for which I feel obliged to give a description. J.M.'s edit summary reads:

Unfortunately, J.M., although your description is flawless, your edits are not. For example, you had changed to the following sentence:

Into:

Unfortunately, the original sentence, plus the paragraph in which it resides, is talking about implementation not codec itself. Your new sentence, J.M., is grammatically correct but factually misleading as has an entirely different meaning.

Your other edits, J.M., such as:

... would have been correct has it not been for the fact that nearly all codecs that are implemented based on MPEG-1 and MPEG-2 are also called MPEG-1 Codec and MPEG-2 Codec. The situation is almost the same about MPEG-4 Part 2 and H.264/MPEG-4 Part 10, except for the fact that, this time, there are some codecs based on H.264/MPEG-4 Part 10 standard that are not simply called MPEG-4 Codec, but rather they are called DivX, Xvid, etc. But indeed, there are codecs that are called MPEG-4 Codec or H.264 Codec.

In the end, I'd like to mention that I currently assume that you have edited Wikipedia in good faith. And I too, undid your edits in good faith. Fleet Command (talk) 12:00, 14 August 2009 (UTC)

You undid my edit in good faith, but unfortunately without understanding the issue at all, and without giving any reasonable explanation. My edit was 100% correct, you even admitted that my reasoning was 100% correct[when?][need quotation to verify], yet you reverted it.
The current version simply does not make sense, for two reasons:
  1. As the article explains, a video codec is a device or a software product. MPEG-1, MPEG-2, VC-1 etc. are not devices or software products. They are only specifications that explain how to make devices or software products that are compatible with the specifications. They are standards, they are formats. The article cannot contradict itself. Which is exactly what it does in its current revision. It is logical nonsense. Wikipedia articles cannot contradict themselves, and adding nonsense to Wikipedia is against the Wikipedia rules.
  2. You do not implement codecs, that is the final (software or hardware) products, you implement specifications. Codecs are already the implementations of the specifications they implement. The whole purpose of standards, specifications, is that there can be multiple implementations of the same format. Which is exactly what's happening. There are many MPEG-4 codecs, many MPEG-2 codecs etc. There is not "the MPEG-1 codec", "the MPEG-2 codec" etc. because MPEG-1 is only a specification, and there are many MPEG-1 implementations in hardware and software, made by various people and companies. This is the most basic principle that applies to the whole world of computing: the difference between a format and a software product. The vast majority of people do not understand the difference. That's what makes them believe that for example Xvid is a format, that Internet Explorer is "the internet" or that Microsoft Windows is "the computer". This fundamental misunderstanding is also the reason why people confuse the terms codec and format so often.
Your reasons for reverting it do not make any sense at all either:
"would have been correct has it not been for the fact that nearly all codecs that are implemented based on MPEG-1 and MPEG-2 are also called MPEG-1 Codec and MPEG-2 Codec.
And what exactly are you trying to prove here? Firstly, they are not (and cannot be) called "MPEG-1 Codec" etc. Products have their names. Like libmpeg2, TMPGEnc etc., which are MPEG-2 (and MPEG-1) decoders and encoders. They are not called MPEG-2 codecs, they are "MPEG-2 codecs". A codec implementing the MPEG-2 standard is an "MPEG-2 codec". Of course. This is the most basic thing that applies to anything else. A program that allows you to edit text is not called "Text Editor" (that is, "Text Editor" is not the name of the sofware product, they all have their own names), but it is a text editor. Even if a codec does not formally have a name (for example, it can be just a hidden support library in a multimedia framework), it is still a software product made by someone, and a not "The MPEG-2 Codec". The only "MPEG-1 Codec" or "MPEG-4 Codec" can be the reference implementation made by MPEG. Anything else is just an implementation made by someone else, and therefore cannot be "The MPEG-2 Codec" etc.
"Unfortunately, the original sentence, plus the paragraph in which it resides, is talking about implementation not codec itself. Your new sentence, J.M., is grammatically correct but factually misleading as has an entirely different meaning."
No, my new sentence was factually 100% correct and the logic is very simple. When you say "A variety of formats can be implemented with relative ease on PCs and in consumer electronics equipment", it means that there are many specifications that can be easily implemented. Which is true and makes sense. When you revert it to the original "A variety of codecs can be implemented with relative ease on PCs and in consumer electronics equipment", is says "a variety of implementations can be implemented". This is circular logic, recursive nonsense. Again, this is the most basic thing you do not understand: the difference between a format and a software (or hardware) product. A format is a specification. A software product is an implementation. A software product works with some format. That is, a software product implements some format, some specification. For example, "Adobe Acrobat" is a software product that implements the PDF specification. Adobe Acrobat is not called "The PDF". Now, your reverted version is the equivalent of saying "Adobe acrobat can be implemented easily on PCs" instead of the logically and factually correct "The PDF format can be implemented on PCs" (which is true, there are many different PDF readers and writers, on many different platforms and operating systems), And since a codec is a software (or hardware) product, a codec implements some specification, too. Therefore, my version was correct, your revert is wrong.
Furthermore, your "is talking about implementation not codec itself" proves that you do not understand what you are talking about. The direct translation is "talking about implementation not implementation itself". Because a codec is a product and a product is an implementation.
"The situation is almost the same about MPEG-4 Part 2 and H.264/MPEG-4 Part 10, except for the fact that, this time, there are some codecs based on H.264/MPEG-4 Part 10 standard that are not simply called MPEG-4 Codec, but rather they are called DivX, Xvid, etc."
This again shows you don't understand what you are talking about at all. Xvid is a software product just like libmpeg2 is a software product. The only difference is that Xvid is much more famous, which leads you to the wrong conclusion that libmpeg2 (or any other MPEG-2 codec) does not exist or that it is called "The MPEG-2 Codec". The fact that a product is not famous does not imply it does not have a name. Even it the name is just something like "libmpeg2", which means MPEG-2 decoding library.
So, I am reverting your revert to my version, because my version was correct, your revert was wrong, your reasoning was confused, based on poor understanding of the whole issue.—J. M. (talk) 18:43, 14 August 2009 (UTC)
Greetings, J.M.
I realize that fair is fair, so suit yourself. However, please note that:
1. This article is about Video Codecs and not about video formats or standards. Since that section of the article is talking about formats and standard, it is now irrelevant and has no reason whatsoever to be in this article.
2. Your assertions now fail Wikipedia Notability policy as they are unverifiable. Please provide citations. (Not here of course; in the article.)
Please consider addressing these issues. To avoid edit-wars, I refrain from undoing any changes to the page on this subject.
By the way, perhaps it is the fault of the plain-text medium which we use for our communication, but somehow I feel aggression and hostility in your written answer. I hope I am wrong.
Fleet Command (talk) 05:42, 15 August 2009 (UTC)
Actually, you are right. Yes, the whole section is largely off-topic because it mainly lists specifications, standards, and also mixes them with a couple of popular implementations. Yes, the whole section is confusing (or confused), as it mixes two completely different things together: specifications, and implementations. It does not matter at all whether you call specification "a codec", or whether you call the implementation "a codec" (which also addresses point 2; BTW, basically all encyclopedic definitions say that codec means encoder/decoder or compressor/decompressor, which clearly implies that a codec actually does something—encodes/decodes. Specification does not do anything, specifications do not encode or decode. The implementations do.) The problem is that the section mixes specifications and implementations (while saying that this article is only about implementations in the introduction), and that is simply not good. The solution is simple: remove the specifications, add some actual implementations. The Comparison of video codecs article (which, of course, only lists software products) may be a good start. If you want to do it, you can. If you don't, I can do it, unless anyone objects.—J. M. (talk) 00:59, 18 August 2009 (UTC)
Hi, J. M.
I can do the deleting, but the adding of valid codec entries which are also popular, I am afraid I cannot: Currently, I'm badly overburdened as I'm looking for credible sources for the new Windows Media Player article, other minor Wikipedia projects and my personal life. (I do know about Microsoft-recommended implementation of MPEG-2 for DVD Video: Cyberlink PowerDVD SE and Roxio CinePlayer SE. But are they popular?)
Therefore, if you can add some actual implementations, I'd be thankful if you did.
Fleet Command (talk) 12:32, 20 August 2009 (UTC)
Done, specifications removed. It is now much more simple (that's why I also removed the templates—there's no technical jargon or weasel words anymore). Corrections are welcome. New codecs can be added, too, if anyone feels something is missing—but please note that the section is called Commonly used video codecs, so it should only list the most popular ones, it's not a list of all codecs ever made.—J. M. (talk) 01:31, 24 August 2009 (UTC)
Well done, J. M.. All three issues are now successfully resolved. Fleet Command (talk) 11:38, 24 August 2009 (UTC)

Pictogram resolved.svgResolved: Issues of Commonly used standards and codecs section[edit]

Hello, Wikipedians

The section "Commonly used standards and codecs" suffers from multiple issues, as I described below. For ease of discussion, I have broken the issues into two separate categories below, so that we can keep our discussion well-organized. Let us review and mitigate those issues.

Fleet Command (talk) 08:08, 15 August 2009 (UTC)

Off-Topic[edit]

First and foremost, this section (Commonly used standards and codecs) is off-topic, which shouldn't be. The article title reads: Video codec. However, in this section, there are standards, specifications, formats and codecs, all mingled and listed together. Standards, specifications and formats have their own articles and should be listed in their relevant articles. Note that Wikipedia is not a collection of indiscriminate information and therefore, if these irrelevant items are listed only for the purpose of adding length to the article, they should be deleted immediately.

Of course, at first, I assumed and tried to establish that these standards, specifications and formats are in fact classes of codecs (or various codec implementations) and this section is talking about codec implementation types rather then the base spec. However, your fellow Wikipedian J. M. discredited this assumption of mine with extreme authoritative force. (See #MPEG-1, MPEG-2 and MPEG-4 as codecs discussion above.)

I suggest that either:

  • The irrelevant information be deleted or moved to appropriate articles
  • Or if this issue is the result of misleading wording, corrective action be taken.

Thanks in advance,

Fleet Command (talk) 08:08, 15 August 2009 (UTC)

This issue is resolved. Many thanks to J. M.
Fleet Command (talk) 11:38, 24 August 2009 (UTC)

Weasel words, jargons, fancruft and lack of source[edit]

This section (Commonly used standards and codecs) is full of weasel words, jargons and excessive intricate details that are only understood by a very small fraction of people who refer to this article. More importantly, this section lack sources.

Here are some examples:

This statement basically gives no information whatsoever. He who reads this statement gains no additional knowledge by reading it. However, this statement obviously gives the illusion that all codecs are important (because allegedly "comparisons are frequently published") but meanwhile not perfect (because allegedly "they have drawbacks"), but does not prove it. In addition, this statement lacks sources.

This statement too, uses weasel word to give the allusion of there being a balance between compression power, speed, and fidelity but in the meantime, it uses the word "usually" to imply that this is not the case with all codecs. In addition, it uses the word "considered" to imply that this statement is credible, without proving it. Basically, there is no difference in meaning to say "The tradeoff between compression power, speed, and fidelity is the most important figure of technical merit." Only this time, its lack of credibility and authority is exposed.

Aside from the fact that "Ultrafast" is also both a weasel word and an advertisement, this statement uses too much cryptic jargons(?) like "Y'CbCr[A]" and is written under the assumption that I, a reader with any given level knowledge, must have never heard the name of this "ultrafast" codec but definitely know the meaning of "Y'CbCr[A]"!

Please remember that Wikipedia is an encyclopedia for everyone not just a highly-technical minority. Cryptic terms like this must be avoided if at all possible or otherwise linked to an article that gives additional information.

Finally, this statement uses the words or pharses that need clarification: "Older" Older is a comparative and when one says "older" he or she specifies exactly older than what. Unsourced use of comparatives and superlative are prohibited in Wikipedia.

Taking corrective action is essential.

Thanks in advance,

Fleet Command (talk) 08:08, 15 August 2009 (UTC)

Hey FleetCommand. First I came to read about codecs. Now I've come here because I am appalled at the state you left the article in. It's unreadable. I don't know the history of editorial disputes but surely you could have had an editorial discussion without sabotaging the article with so many tags? I'm going to remove your tags, not because I disagree with them but because they are making the article unreadable and hence the editorial situation is worse than before you left the tags. If it matters so much to you please take the time to discuss the article here with whoever it is you're taking issue with and then post a new version. Or, even better, create a new section yourself and post that. Please don't go bashing editors with wikipolicy. If you look a little deeper you'll see that you actually broke several policies in leaving the article in the state you left it in. Readability is about the highest accountability standard we can hold. It's gotta be readable before we can even consider whether it is accurate or good. Thanks. 119.12.56.242 (talk) 23:54, 17 August 2009 (UTC)
Hey, 119.12.56.242. I am going to assume that your reverted those tags in good faith. Yes, readability is important but hiding the problem also wouldn't help. I don't really know what do with those appalling jargons like half-pel and Y'CbCr[A] and those sneaky weasel word. So, I did the best I could: tagging them. I am afraid, but this time WP:SEP and WP:BOLD do not apply: It is my problem, yes, but I'm not rocket-scientist enough to resolve those issues.
However, I promise I'll give readability more credit in the future. Fleet Command (talk) 12:32, 20 August 2009 (UTC)
Issue is now mostly resolved. Thanks to J. M.
Fleet Command (talk) 11:38, 24 August 2009 (UTC)

AVCHD or MTS?[edit]

Hello all. I'm a newbie searching for information on AVCHD and MTS. Should that not appear somewhere in this discussion? Is it too new? Thanks. —Preceding unsigned comment added by 75.99.77.130 (talk) 17:47, 21 March 2010 (UTC)

First, they are media container/video formats/specifications, not codecs. Second, you should probably just read the AVCHD and .mts articles directly. C xong (talk) 01:04, 27 May 2010 (UTC)

Removal of unknown codec[edit]

Hello, I removed the following text from section "Commonly used video codecs" / "Other codecs":

  • [[Securewave]]: Proprietary high end wavelett and differential video compression format and codec developed by Procysive used in remote medical diognostic imaging and by the US Government. It can be lossless or lossy.

I think, this codec is not commonly used. --89.173.67.123 (talk) 12:52, 6 August 2010 (UTC)

'Commonly used' lossless codecs links to the whole list[edit]

I think that the meaning of 'commonly used' is precisely to highlight some codecs from the more full list. (It is not very useful to just link all the lossless codecs in the more full list.)

featherbrained crap: wording, missing legal aspects[edit]

  1. Could we please call a video codec, a video codec, an algorithm for the lossy compression of video, instead of calling it "video standard", video compression format and all the other featherbrained denominations?
  2. more featherbrained stuff in the introduction: "enables"; the codec describes the steps to be taken in order; a software library, implementing the codec, can be executed to DO a compression/decompression; similarly a SIP block like Unified Video Decoder, or a distinct chip can be used, to make to do the compression/decompression
  3. a section called "Legal aspects" would be nice to have; are algorithms subject to patent or software patent law? In which countries? Are there examples of law-suits? etc.E g.

FFmpeg contains more than 100 codecs. Most codecs that compress information could be claimed by patent holders.[1] Such claims may be enforceable in countries like the United States which have implemented software patents, but are considered unenforceable or void in countries that have not implemented software patents. Furthermore, many of these codecs are only released under terms that forbid reverse engineering, even for purposes of interoperability. (This means the actual codec (=algorithm) is NOT available, only a software implementation under some proprietary license. It is this binary software that is being reverse engineered, to obtain the codec. Based on this reversed engineered codec, a new implementation can be written, and e.g. distributed under a free software license.

These terms of use are forbidden in certain countries. For example, some European Union nations have not implemented software patents and have laws expressly allowing reverse engineering for purposes of interoperability.[2]

— Preceding unsigned comment added by ScotXW (talkcontribs) 21:17, 27 June 2014‎ (UTC)

You are very confused. A codec is not an algorithm for the lossy compression of video. There are many lossless codecs, too. A codec does not "describe steps", you don't "implement codecs": a codec is already the implementation. A codec performs the steps. By definition. That's why it's called coder/decoder, which means it is a tool that actually does something—the encoding and decoding. It is not a decription. You correctly say that FFmpeg contains codecs (pieces of software that perform encoding/decoding), and then you confuse codecs with specifications. Which really does not make any sense at all. As for the patent situation, sure, a more detailed description would be welcome. But I'm not sure this is something that can be proved easily as the situation seems to be very convoluted.—J. M. (talk) 01:09, 28 June 2014 (UTC)
And as for the patent situation, actually, the most common codecs do not reverse-engineer anything, as modern codecs typically implement one of the common compression standards where the specification is available, so for the most common formats, it is not a question of copyright, but a question of patents. The codecs themselves are not covered by patents. But some of the methods in some of the specifications (typically the standards produced by MPEG) are. In countries where the patents apply, of course. But first, the methods are not limited to a single specification, as many of the modern compression formats use similar or identical methods. There is an ongoing debate whether some of the supposedly "patent-free" compression standards (e.g. VP8) actually use some of those patented methods or not (the MPEG-LA and related companies are known to have a rather radical view on that). Furthermore, there is a debate whether the patents actually apply even in countries (in the EU) where software patents do not apply. The situation is not clear at all.—J. M. (talk) 02:05, 28 June 2014 (UTC)
Is that so? I really did think to know, that the term CODEC refers to the algorithm pairs, the specifications, of the steps to be taken, to compress and decompress again and to their implementations. Where is this defined?
  • So then a: CODEC is a software library implementing a pair of algorithms describing the (lossy or lossless) compression of video or sound data and its subsequent decompression.
  • The software can target a certain instruction set or even be written to be executed on GPUs.
  • The term hardware CODEC refers to ... field-programmable gate array or a combination of firmware and some DSP/SIMD-logic
  • the patent situation is indeed convoluted (and labyrinthine), so this issues need to be taken care of; and instead of half-through all over the place, rather at one point of failure that all the others point to to increase the peer-review User:ScotXWt@lk 22:57, 30 June 2014 (UTC)