Talk:Comparison of video codecs

message: I have some information on Forbidden Technologies Blackbird video codec, which I helped develop. I am working on this article which mentions it. What level of reliable source do people on this comparison expect for codec information? And what do people here count as reliable sources?
: The FORscene article is now live. Stephen B Streater 17:44, 11 June 2006 (UTC)
thread_title:  Reliable sources 

message: A lot of codecs are very similar. The article would benefit from new columns to show the differences. I suggest
* The problem the codec is designed to solve
* How the codec degrades when datarate is reduced
* How the codec degrades when available CPU for playback is reduced
::It's impossible to include that kind of information in a table-based page like this. You would need to include graphs, screenshots, etc. That's not encyclopedic (or Wikipedic), that's something for a website about digital video. MrTroy 12:27, 5 July 2006 (UTC)
replies: text:  I agree that a detailed analysis of whether one version was better than another in different circumstances should be in your website review. The idea here would be to say whether frame rate or image quality are reduced, for example. This wouldn't need a graph. See MPEG/Blackbird example below. Stephen B Streater 14:12, 5 July 2006 (UTC)

text: I agree only about the first one, it's actually an useful information. The rest though, would sound like weasel words in favor of Blackbird. --ren 06:34, 19 September 2006 (UTC)

text: I find the choice of features odd. Under what circumstances would someone want to know the 'highest supported bitrate'? Whether a codec contains patented techniques might be useful for an article about algorithms or specifications, but why for codecs? In order for other contributors to have an incentive to add to this article, it needs to be structured to provide an overview information of general interest to readers, rather than just a few random features of a few random codecs. AndreasWittenstein 02:16, 29 March 2007 (UTC)
thread_title:  More features in comparison 

message: While I am personally against software patents, many people aren't.  The use of "but yes" and "but no" here is obviously biased.  In respect of WP:NPOV, I propose discontinuing the use of those templates on this page (whatever the outcome of the template deletion). --Karnesky 01:44, 13 March 2007 (UTC)
thread_title: Bias in patents

message: i'd expect a list like this would compare the size of the same movie(s) compressed by the different codecs (maybe i'll do it myself) --193.136.128.14 13:26, 17 May 2007 (UTC)
replies: text: It's not so simple. Every codec I know allows you to set a target bitrate. There's no single best bitrate for a given resolution. Using the same codec you would want to set a much higher bitrate/quantizer for something you're going to edit than for something you're going to stream over the web. So it's hard to give a typical compression ratio for a codec. If what you mean is compressed size at same quality, well, quality is quite subjective, and codecs have a number of settings depending on what you want to optimize for (quality, encoding/decoding CPU/time, device compatibility) so it would have to be a series of graphs instead of a single number. OK, roughly speaking, typical MPEG2:ASP:AVC compression rates relate as about 1:3:6, but what use are these numbers?--87.162.6.190 (talk) 18:41, 5 August 2009 (UTC)
replies: text: Perhaps it's not possible, but I would also very much like to see something like this.  — Preceding unsigned comment added by Torr3 (talk • contribs) 14:04, 6 April 2014 (UTC)
thread_title:  This isn't very useful 

message: What does the "Patented" column mean? Does it mean the particular codec (software implemetation) is patented or the encoding method (specification, compression format) it uses? I would naturally expect the latter, as that's what's relevant and important in most cases. But then Xvid, FFmpeg and x264 should be marked as patented, too, because they use the patented MPEG-4 compression formats. Anyway, this whole patent section is as confusing as the rest of the article. —J. M. 00:39, 25 May 2007 (UTC)
replies: text: No reply, so I changed the descriptions—what matters for users (and also for example for Linux distribution makers) is whether the compression standard the codecs use is patented or not. Xvid, FFmpeg and x264 use patented MPEG-4 (and other, in the case of FFmpeg) compression formats, that's why patents apply to them in the countries where software patents apply. —J. M. 03:40, 26 May 2007 (UTC)
thread_title:  Patented 

message: I'm trying to find a nice, simple resource that compares MPEG2 versus VC1 (aka wmv) codecs.  I found pages that compare audio codecs, for example, saying that an AAC+ file can be compressed to half the size of a MP3 file, and yet still score the same in listener tests.  -----  Doesn't wikipedia have a similar comparison for video?  -  Theaveng 16:00, 14 September 2007 (UTC)
replies: text: There are already several useful links in the article. Bear in mind anything too simple is misleading and anyone who tells you AAC+ can be compressed to half the size of an MP3 file yet still score the same in listener tests is probably talking bullshit since tests tend to vary a lot based on sample type. VC1 can usually achieve roughly equivalent quality to MPEG2 at a lower bitrate. But MPEG4 AVC/h.264 is usually better still.  for some comparisons include several different codecs in 2006  and quite a few comparisons of AVC codecs (usually throwing in one MPEG4 ASP sample as well I believe). They don't have VC1 unfortunately this isn't their fault. They rely on the support of vendors/codec developers but MS didn't want to participate . In any case I would also recommend the doom9 forums in general, there are a lot of people there who actually know what they're talking about Nil Einne (talk) 17:26, 19 December 2007 (UTC)
replies: text: If you review the wiki article about Audio Codecs, there are several tests there (not just one), and they do indeed reveal that an AAC+ codec (which includes SBR to preserve high frequencies) can encode at half the bitrate of MP3, and still score equal quality ratings by the listeners.  -  Theaveng (talk) 18:33, 20 December 2007 (UTC)
thread_title:  QUALITY comparison of codecs?   

message: As mentioned on its  talk page, there is no reason for "Differences between mp4 & 3gpp file format" to be a stand-alone article -- the information therein should be merged here. --Ean5533 ( View! /  Talk!) 04:30, 16 February 2008 (UTC)
thread_title:  MERGEFROM: "Differences between mp4 & 3gpp file formats" 

message: * I agree on merging this article with Comparison of video codecs. --Mahmudmasri (talk) 01:29, 19 July 2009 (UTC)
replies: text: If you mean merge the Differences between mp4 & 3gpp file formats with this one, then that's utter nonsense. I explained it on the other article talk page (this article discusses software products that produce video bitstreams, while the other article compares container formats, so the two articles compare completely unrelated things in every way). So I suggest removing the merge template from both articles, as it was obviously put there by someone who did not understand what he/she was doing (first, he/she does not understand the difference between a video format and a container format, second, he/she does not understand the difference between a format and a software product).—J. M. (talk) 02:21, 19 July 2009 (UTC)
replies: text: Any objections to removing the merge template?—J. M. (talk) 00:00, 8 August 2009 (UTC)
replies: text: No objections, plus agreement with the template removal on the other article talk page, so I'm removing it.—J. M. (talk) 04:58, 13 August 2009 (UTC)
thread_title:  Agree on Merging 

message: Is the 2005 Doom9 shootout really the latest independent test for the major codecs? That's a shame. Google just acquired On2 and claim VP7/VP8 is much better than H.264, Theora claims to be comparable to H.264 (wishful thinking IMO)... blurb everywhere, where are the objective data to support it?--87.162.6.190 (talk) 18:59, 5 August 2009 (UTC)
thread_title:  No recent shootout? 

message: A comparison of compression ratios would be most usefull.(Fractalhints (talk) 18:50, 18 March 2010 (UTC)
replies: text: This has been touched on before. One reason it hasn't been added is that the compression ratios can often be improved by sacrifices in other areas, such as video quality and compression speed. It makes most sense in the case of lossless compression, but even there the nature of the input can make a big difference. Stephen B Streater (talk) 07:34, 19 March 2010 (UTC)
thread_title:  Compression Ratios. 

message: This article can't seem to decide whether it's documenting codecs (encoder/decoder specifications) or encoders (implementations). For example, the same table lists both VP6 (codec) and Windows Media Encoder (an encoder product). That doesn't make sense.
I strongly recommend that the table be appropriately split into 2 tables.  —Preceding unsigned comment added by 174.21.199.110 (talk) 19:54, 9 November 2010 (UTC)
replies: text: Codecs are not encoder/decoder specifications. A codec is an encoder/decoder (or compressor/decompressor)—that's the definition of the word codec. "A video codec is a device or software" that encodes and decodes video. A video codec is not a specification, a video codec is an implementation. And that's what this article compares. And it also makes it perfectly clear. Even the first sentence of the article explains what a video codec is, and therefore what the article is about, and the following sections clearly explain that the article is about software products (price, version, OS support, license etc.), not about specifications (e.g. "A codec is not a format"). I don't think the article could make it any more clear than that.—J. M. (talk) 20:15, 9 November 2010 (UTC)
thread_title:  Codecs or encoders? Specifications or implementations? 

message: Hello,
I am not an expert wikipedia editor, but it seems that you have 3 columns in that chart that do not contain any information for all but one codec.  —Preceding unsigned comment added by 129.179.32.1 (talk) 21:24, 14 February 2011 (UTC)
thread_title:  General video codec information — creator/company, license/price, etc. 

message: The YULS codec needs adding Lmatt (talk) 22:39, 15 April 2011 (UTC)
thread_title:  YULS 

message: This seems like important/basic information. I have a ~2GB mkv file on network storage. I want to skip to the middle of the video with VLC but VLC wants to play thru the entire video (internally/quickly) to get to that point in the video. Doing this takes about half the time it would take to watch the video up to that point. So either VLC is inferior or the codec (I am not sure which it is, assuming mkv is a container) cannot do random positioning. 
In short. It seems like a table of what codecs can be opened midstream and how gracefully and to what precision they are able to do so would be good to have here. --12.213.80.36 (talk) 08:56, 5 December 2011 (UTC)
replies: text: This has nothing to do with codecs. First, the ability to seek in the file depends on things such as container format, the way the container was created, the audio and video stream format and their properties, the player and the way it handles seeking, whether the file is read from the disc or streamed over a network, the transport protocol etc. Second, this article is about codecs, and codecs are software products (as the "open-source" attribute in the title suggests), not formats. Software products are tools that create/read files or streams in some format, so generally it does not matter which particular software product (tool) you use, what matters is the format you choose. You do not "open codecs midstream", because codecs are software libraries, and you do not open libraries midstream (at least when you play back a video).—J. M. (talk) 16:41, 5 December 2011 (UTC)
thread_title:  Which codecs allow for random positioning? 

message: As many, many complaints on this talkpage show, the most essential aspect about video codecs is their efficiency, that is the file size (or data rate)/quality ratio. Now you're gonna say again "But maaaaan, there's so many different settings you can make!" Well Sherlock, that's why most professional comparisons go by industry standards!
In other words, Wikipedia is still lacking a comparison of digital video format and broadcast standards (DVD MPEG-2, DV, DVB, BD MPEG-4 AVC...) based upon efficiency, giving file size and/or data rate for a variety of industry standards at a number of resolutions, profiles, etc (per second, per minute, per hour, per 2-hour standard movie running time).
For instance, did you know that at the same length and SD resolution, a video will be less than half in file size as DVD MPEG-2 video than as more recent BD MPEG-4 AVC? As DVD MPEG-2, a 2-hour SD rez movie can be 4GB small, whereas as MPEG4 AVC@SD rez, it's 9-11 GB (Main Profile, aka DVB, vs. High Profile, for storage media, such as BD)? Which means that the newer standard is less efficient than the old one, even at the same resolution. --79.193.41.170 (talk) 13:55, 27 May 2012 (UTC)
replies: text: This is exactly the reason why this article exists, and why there are always comparisons of codecs, not comparison of formats everywhere on the web. We can only meaningfully compare encoders, because the quality depends on the encoder, on the software or hardware implementation. In other words, a bad MPEG-4 encoder can give (much) worse quality for the same file size than an excellent MPEG-2 encoder. And even the best MPEG-4 encoder can give worse quality than a bad MPEG-2 encoder if "bad" encoding options are selected, because, yes, there are many ways to configure the encoder. The term "industry standards" really does not apply here, because an industry standard means a format or a subset of a format, but there are still many different encoders available for that format or its subset (such as the MPEG-4 AVC profiles), and many ways to configure them. A video format does not "perform", only the encoder does. And there can be (and are) are wild differences in quality among various encoders for the same format, even though, of course, encoders for newer, more modern formats typically tend to give better results than encoders for older, more simple formats, as the newer formats are more advanced. But it's not a hard rule.—J. M. (talk) 23:00, 27 May 2012 (UTC)
thread_title:  Efficiency 

message: See http://xiph.org/daala/  — Preceding unsigned comment added by 128.70.197.164 (talk) 14:09, 15 May 2016 (UTC)
thread_title:  Daala is missing 

message: Hello fellow Wikipedians,
I have just modified 7 external links on Comparison of video codecs. 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/20081107213150/http://diracvideo.org/ to http://www.diracvideo.org/
*Added archive https://web.archive.org/web/20091216173026/http://www.ffavs.net/ to http://www.ffavs.net/
*Added archive https://web.archive.org/web/20040804142359/http://www.realnetworks.com/products/codecs/realvideo.html to http://www.realnetworks.com/products/codecs/realvideo.html
*Added archive https://web.archive.org/web/20070205154511/http://www.csse.monash.edu.au/~timf/videocodec/cinepak.txt to http://www.csse.monash.edu.au/~timf/videocodec/cinepak.txt
*Added archive https://web.archive.org/web/20080223010804/http://www.doom9.org/codec-comparisons.htm to http://www.doom9.org/codec-comparisons.htm
*Added archive https://web.archive.org/web/20070823063012/http://people.csail.mit.edu/tbuehler/video/codecs/ to http://people.csail.mit.edu/tbuehler/video/codecs/
*Added archive https://web.archive.org/web/20090620051634/http://etill.net/projects/dirac_theora_evaluation/ to http://etill.net/projects/dirac_theora_evaluation/
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 17:59, 11 August 2017 (UTC)
thread_title:  External links modified