![]() | This article is rated List-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
I find it moderately disturbing that DSD/SACD are listed under "Pulse Density Modulation". This is incorrect, DSD is, was, and has always been an advanced form of Candy/Condon Sigma-Delta (or Delta-Sigma) if you choose, which means that it is a form of PCM with oversampling and noise shaping. There are many forms of PDM that do not have the characteristics of Sigma-Delta, and it seems misleading to call it PDM, when in fact is is a very well known use of a very early technique, namely Sigma-Delta, which is, at its core, nothing more than PCM with noise shaping. — Preceding unsigned comment added by Woodinville ( talk • contribs) 01:39, 8 July 2014 (UTC)
Where does AVS go? —Preceding unsigned comment added by 129.215.101.110 ( talk) 14:37, 20 June 2008 (UTC)
I removed FORlive and FORtune from the list because this looked like a blatant product advertisement. This is not the first time the issue of Forbidden Technologies advertising on Wikipedia has come up. See Wikipedia:Articles_for_deletion/FORscene.
When I click on the FORlive link I see an ad for streaming video software that says nothing about codecs whatsoever. And when I click on the FORtune link I get a page that doesn't even mention FORtune at all. Thus this information is unverifiable, unrelated to the subject matter of the article, and a blatant product advertisement.
I looked for independant confirmation that these codecs exist and found none. Neither was listed at multimedia.cx, hydrogenaudio, or doom9. The only thing I found with a search engine were links to Forbidden Technologies press releases. See WP:Notability.
Below is Stephen B Streater's description of FORlive and FORtune. I have to ask why this is here instead of on forbidden.co.uk? This could be the start of an article, but would need some independant sources (see WP:Cite, Wikipedia:Verifiability, Wikipedia:No original research) -- Mcoder 00:29, 22 May 2006 (UTC)
PS Given the number of people who have seen FORlive from this page and not proposed deletion, I'd prefer at least one other person to express an opinion before we establish a consensus to delete. Does this seem reasonable? Stephen B Streater 09:06, 22 May 2006 (UTC)
Someone asked for some details of FORlive, so I've written some down below. Stephen B Streater 22:30, 20 May 2006 (UTC)
FORlive is a real time video codec. It is designed to compress live video for playback on remote computers, near-live, over the web - without requiring any software upgrades on the watching PCs or the web server. The real time player runs on typical PCs and Macs at up to 384x288 pixels, 25 fps for PAL, or 320x240 pixels, 30fps for NTSC.
FORlive was launched at IBC in September 2004 by Forbidden Technologies plc. It is notable for being the first widely viewed live streaming Java player, with the example page below alone receiving around 1,000,000 hits per month since 2004.
All fetches are simple HTTP requests, so the video can be served from a standard webserver. The player is implemented in Java to ensure that Windows, MacOS and Linux computers can play back the latest version of the player without installation. Although not all computers have Java installed, for several years it has been installed as standard by major manufacturers, and the latest versions have been available as free downloads from Sun. The datarate is set at compression time and three simultaneous bitstreams are produced: "modem", "midband" and "broadband" - the average datarates and image sizes are set on the compression machines, which run Debian Linux. The "modem" and "midband" bitstreams are dynamically interchangeable by the player, which senses the datarate as it reads in files and adjusts the fetches to accommodate available bandwidth.
The compressor is easy to install: it can be plugged into a camera, the mains electricity and an ethernet port connected to the internet, and then automatically uploads live video to a webserver where it can be viewed from almost any computer in the world with internet access.
The requirements for a real time software compressor / Java player combination covering a wide range of bandwidths and player CPU speeds place some contraints on the computational complexity available to the codec. It operates on the YUV levels directly, and does not use transforms such as DCT or wavelets, to ensure computational efficiency. The compression has two stages - a filter stage to remove noise from the source data (particularly required for cheap cameras with composite outputs) followed by a data compression / bitstream output stage.
The image is split into 2x2 blocks, and each block is treated as a single unit. Uniform blocks are encoded at 6 bits Y, and bilinearly interpolated to 8bpp on playback to give a smooth result. Non-uniform blocks are quantised and encoded using 5bpp. Colour is compressed as UV components, also quantised, but unlike Y values, these are quantised in a non-linear way to reflect the human visual system.
Apart form an initial key frame at the start of each block, only deltas are encoded.
2x2 block deltas are effectively Huffman encoded, though significant improvements over a naïve Huffman encoding are achieved by, instead of using one static Huffman table, using thousands of Huffman tables to allow the most relevant one to be chosen when each codeword is encoded/decoded, and re-evaluating the Huffman tables thousands of times per second. To allow this rapid dynamic reappraisal of the data environment, exact Huffman tables are not used, but close approximations are used instead.
The FORlive codec is covered by several patents in the UK, US, Japan and Europe.
You can see an example of the FORlive codec here. This demo runs off a $100 PAL composite security camera, and has been running round the clock since 2004, except for brief intermissions for upgrades. As of May 2006, the current version has run non-stop for 14205010 seconds (see Java console) ie 164 days.
Stephen B Streater 22:30, 20 May 2006 (UTC)
Someone asked for some details of FORtune, so I've written some down below. Stephen B Streater 22:36, 20 May 2006 (UTC)
FORtune is a real time audio codec. It is designed to compress live audio for playback on remote computers, near-live, over the web - without requiring any software upgrades on the watching PCs or the web server. The audio datarate can be varied from 8kb/s to 80kb/s per channel.
All fetches are simple HTTP requests, so the audio can be served from a standard webserver. The player is implemented in Java to ensure that Windows, MacOS and Linux computers can play back the latest version of the player without installation. FORtune can be run in conjunction with FORlive, where the video and the audio play back in sync.
You can see an example of the FORtune audio codec here.
Codec details to follow. Stephen B Streater 22:36, 20 May 2006 (UTC)
The FORtune audio codec splits the audio into sections of around 10ms. These are then converted into frequency space and quantised. The FORtune codec takes into account how loud the sound is at any point to give a constant signal:noise ratio. The audio is compressed using a similar dynamic Huffman-like compression to the FORlive video, to take into account the type of sound at any point.
The player can play back on integer only CPUs such as the ARM widely used in mobile phones. A freely downloaded mobile phone application, FORmobile [1] (currently being used by the British Army [2]), is available for playing back video/audio using an integer-only ARM implementation of the audio player (and an integer-only video player).
If the audio is being played in conjunction with video, for example with the FORlive streaming video codec or the FORscene [3] video editing codec, it is seamlessly resynched every frame to ensure the video and audio can play over any period of time without slipping out of sync.
The Java implementation of the FORtune audio codec takes a few percent of the available CPU time on typical PCs, and is negligible compared with the CPU taken to play full frame rate video on the same machine. Stephen B Streater 15:10, 21 May 2006 (UTC)
FORscene has its own article now, and I'm wondering what sort of places count as reliable sources for codec information. There's quite a lot which could be said. FORscene has two codecs, Blackbird and Impala, for video and audio (see above) but the trade publications in FORscene's market are more interested in workflow in the professional post-production industry than in technical details of compression. What publications do the other codecs draw from? Stephen B Streater 09:12, 19 June 2006 (UTC)
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:48, 21 March 2010 (UTC)
Makes no sense, isn't claimed to be lossless by the company that makes it - citation was to a forum where people discuss how lossless RGB changes the chroma subsampling - not the same thing as having a lossless codec. Not even sure why it said FFMPEG decoder, this doesn't just apply to just FRAPs codec either, why is it important what FFMPEG can or can't decode, what's that got to do with whether or not FRAPs (or other codecs) are lossless or not?
Maybe we'd have it as a lossless codec if the company's website said, FRAPs is a lossless codec. I mean, if it were, surely it would be part of the advertised feature-set? 86.135.238.18 ( talk) 18:48, 23 June 2012 (UTC)
I've marked an unsourced claim that a codec is "very fast" with {{ cn}}. Not sure whether it should be mentioned at all, since most codecs listed here have no information about speed or quality. — Frungi ( talk) 19:56, 8 January 2013 (UTC)
The article appears to be a list of data formats (the first sentence even says so), not codecs ("device or computer program capable of encoding or decoding"), so should be renamed accordingly. 203.176.108.99 ( talk) 00:03, 20 February 2013 (UTC)
Should this be added to the list?
New lossless audio codec launched Dec 2014.
Company site
3rd party news article covering launch
Also mentioned in BBC Click episode 17-Jan-15 - iPlayer link
— Preceding
unsigned comment added by
82.37.220.173 (
talk) 12:02, 18 January 2015 (UTC)
How about a traditional list with required articles (no red links) and no references? – Be..anyone ( talk) 21:40, 11 April 2016 (UTC)
That list has highlighted that "open" is a multi-factored thing - like having an open-source encoder, open-source decoder, and being free of patents. The status of each of those things could be indicated in this list if it were turned into a simple table. -- Beland ( talk) 04:38, 20 May 2016 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on List of 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:
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).
Cheers.— InternetArchiveBot ( Report bug) 10:32, 29 December 2017 (UTC)
tl;dr: Should GIF be added to the lossless video list?
I'm wondering if (animated) GIF should be added to the list of lossless video codecs. The pros are that it is very much a video format, it is lossless in that there is no generational loss, and for those videos for which it is well-suited (e.g. a limited color input where few pixels change between frames) it outperforms h264 lossless, h265 lossless, FFV1, MSU lossless, YULS, VP9-losless, and others by orders of magnitude, and does not require a x2, x4, or x8 size constraint.
The cons are that there is a first-time loss (colors reduced to a maximum 256 color palette per frame - although GIFs can switch palettes throughout their run, this is rarely used), few video players support GIF files, and those that do rarely support seeking the timeline - even if the GIF is constructed so that there are full frames available. In terms of the first-time loss, this is true for most formats considered lossless, as they often convert color spaces from regular RGB or even 10bit RGB for their encoders to work well.
Due to the extremely high compression ratio that can be reached for those specific cases for which other codecs are abysmally ill-suited, I would suggest that GIF be considered - but wanted to write my reasoning and seek feedback. Kmqz ( talk) 22:48, 12 May 2018 (UTC)
LiberatorG reverted my attempt to move unnecessary detail from Video codec to this list. I know that this move created some overlap here and I hoped we could iron that out over time. I don't feel it would be a good idea to restore this material to Video codec so I'll reproduce it below. ~ Kvng ( talk) 18:33, 19 March 2019 (UTC)
See the Audio full list and Video full list.
This Article is a List of Software called: CODECs it is not Article containing list of dead mere Codecs Specification / Standard, it is list of Codecs, and that is software: Decoder and Encoder.
" Computer program" == is software!
FFmpeg is mentioned next to almost every codec standard.
And some user change statement from true to false, by Writing that MPEG-5 codecs are under-development,
It is false, as Those 2 codecs are NOW fully developed.
Only Consumer Hardware is steel under development, or additional implementation in Software.— Preceding unsigned comment added by 46.187.199.166 ( talk • contribs)
![]() | This article is rated List-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
I find it moderately disturbing that DSD/SACD are listed under "Pulse Density Modulation". This is incorrect, DSD is, was, and has always been an advanced form of Candy/Condon Sigma-Delta (or Delta-Sigma) if you choose, which means that it is a form of PCM with oversampling and noise shaping. There are many forms of PDM that do not have the characteristics of Sigma-Delta, and it seems misleading to call it PDM, when in fact is is a very well known use of a very early technique, namely Sigma-Delta, which is, at its core, nothing more than PCM with noise shaping. — Preceding unsigned comment added by Woodinville ( talk • contribs) 01:39, 8 July 2014 (UTC)
Where does AVS go? —Preceding unsigned comment added by 129.215.101.110 ( talk) 14:37, 20 June 2008 (UTC)
I removed FORlive and FORtune from the list because this looked like a blatant product advertisement. This is not the first time the issue of Forbidden Technologies advertising on Wikipedia has come up. See Wikipedia:Articles_for_deletion/FORscene.
When I click on the FORlive link I see an ad for streaming video software that says nothing about codecs whatsoever. And when I click on the FORtune link I get a page that doesn't even mention FORtune at all. Thus this information is unverifiable, unrelated to the subject matter of the article, and a blatant product advertisement.
I looked for independant confirmation that these codecs exist and found none. Neither was listed at multimedia.cx, hydrogenaudio, or doom9. The only thing I found with a search engine were links to Forbidden Technologies press releases. See WP:Notability.
Below is Stephen B Streater's description of FORlive and FORtune. I have to ask why this is here instead of on forbidden.co.uk? This could be the start of an article, but would need some independant sources (see WP:Cite, Wikipedia:Verifiability, Wikipedia:No original research) -- Mcoder 00:29, 22 May 2006 (UTC)
PS Given the number of people who have seen FORlive from this page and not proposed deletion, I'd prefer at least one other person to express an opinion before we establish a consensus to delete. Does this seem reasonable? Stephen B Streater 09:06, 22 May 2006 (UTC)
Someone asked for some details of FORlive, so I've written some down below. Stephen B Streater 22:30, 20 May 2006 (UTC)
FORlive is a real time video codec. It is designed to compress live video for playback on remote computers, near-live, over the web - without requiring any software upgrades on the watching PCs or the web server. The real time player runs on typical PCs and Macs at up to 384x288 pixels, 25 fps for PAL, or 320x240 pixels, 30fps for NTSC.
FORlive was launched at IBC in September 2004 by Forbidden Technologies plc. It is notable for being the first widely viewed live streaming Java player, with the example page below alone receiving around 1,000,000 hits per month since 2004.
All fetches are simple HTTP requests, so the video can be served from a standard webserver. The player is implemented in Java to ensure that Windows, MacOS and Linux computers can play back the latest version of the player without installation. Although not all computers have Java installed, for several years it has been installed as standard by major manufacturers, and the latest versions have been available as free downloads from Sun. The datarate is set at compression time and three simultaneous bitstreams are produced: "modem", "midband" and "broadband" - the average datarates and image sizes are set on the compression machines, which run Debian Linux. The "modem" and "midband" bitstreams are dynamically interchangeable by the player, which senses the datarate as it reads in files and adjusts the fetches to accommodate available bandwidth.
The compressor is easy to install: it can be plugged into a camera, the mains electricity and an ethernet port connected to the internet, and then automatically uploads live video to a webserver where it can be viewed from almost any computer in the world with internet access.
The requirements for a real time software compressor / Java player combination covering a wide range of bandwidths and player CPU speeds place some contraints on the computational complexity available to the codec. It operates on the YUV levels directly, and does not use transforms such as DCT or wavelets, to ensure computational efficiency. The compression has two stages - a filter stage to remove noise from the source data (particularly required for cheap cameras with composite outputs) followed by a data compression / bitstream output stage.
The image is split into 2x2 blocks, and each block is treated as a single unit. Uniform blocks are encoded at 6 bits Y, and bilinearly interpolated to 8bpp on playback to give a smooth result. Non-uniform blocks are quantised and encoded using 5bpp. Colour is compressed as UV components, also quantised, but unlike Y values, these are quantised in a non-linear way to reflect the human visual system.
Apart form an initial key frame at the start of each block, only deltas are encoded.
2x2 block deltas are effectively Huffman encoded, though significant improvements over a naïve Huffman encoding are achieved by, instead of using one static Huffman table, using thousands of Huffman tables to allow the most relevant one to be chosen when each codeword is encoded/decoded, and re-evaluating the Huffman tables thousands of times per second. To allow this rapid dynamic reappraisal of the data environment, exact Huffman tables are not used, but close approximations are used instead.
The FORlive codec is covered by several patents in the UK, US, Japan and Europe.
You can see an example of the FORlive codec here. This demo runs off a $100 PAL composite security camera, and has been running round the clock since 2004, except for brief intermissions for upgrades. As of May 2006, the current version has run non-stop for 14205010 seconds (see Java console) ie 164 days.
Stephen B Streater 22:30, 20 May 2006 (UTC)
Someone asked for some details of FORtune, so I've written some down below. Stephen B Streater 22:36, 20 May 2006 (UTC)
FORtune is a real time audio codec. It is designed to compress live audio for playback on remote computers, near-live, over the web - without requiring any software upgrades on the watching PCs or the web server. The audio datarate can be varied from 8kb/s to 80kb/s per channel.
All fetches are simple HTTP requests, so the audio can be served from a standard webserver. The player is implemented in Java to ensure that Windows, MacOS and Linux computers can play back the latest version of the player without installation. FORtune can be run in conjunction with FORlive, where the video and the audio play back in sync.
You can see an example of the FORtune audio codec here.
Codec details to follow. Stephen B Streater 22:36, 20 May 2006 (UTC)
The FORtune audio codec splits the audio into sections of around 10ms. These are then converted into frequency space and quantised. The FORtune codec takes into account how loud the sound is at any point to give a constant signal:noise ratio. The audio is compressed using a similar dynamic Huffman-like compression to the FORlive video, to take into account the type of sound at any point.
The player can play back on integer only CPUs such as the ARM widely used in mobile phones. A freely downloaded mobile phone application, FORmobile [1] (currently being used by the British Army [2]), is available for playing back video/audio using an integer-only ARM implementation of the audio player (and an integer-only video player).
If the audio is being played in conjunction with video, for example with the FORlive streaming video codec or the FORscene [3] video editing codec, it is seamlessly resynched every frame to ensure the video and audio can play over any period of time without slipping out of sync.
The Java implementation of the FORtune audio codec takes a few percent of the available CPU time on typical PCs, and is negligible compared with the CPU taken to play full frame rate video on the same machine. Stephen B Streater 15:10, 21 May 2006 (UTC)
FORscene has its own article now, and I'm wondering what sort of places count as reliable sources for codec information. There's quite a lot which could be said. FORscene has two codecs, Blackbird and Impala, for video and audio (see above) but the trade publications in FORscene's market are more interested in workflow in the professional post-production industry than in technical details of compression. What publications do the other codecs draw from? Stephen B Streater 09:12, 19 June 2006 (UTC)
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:48, 21 March 2010 (UTC)
Makes no sense, isn't claimed to be lossless by the company that makes it - citation was to a forum where people discuss how lossless RGB changes the chroma subsampling - not the same thing as having a lossless codec. Not even sure why it said FFMPEG decoder, this doesn't just apply to just FRAPs codec either, why is it important what FFMPEG can or can't decode, what's that got to do with whether or not FRAPs (or other codecs) are lossless or not?
Maybe we'd have it as a lossless codec if the company's website said, FRAPs is a lossless codec. I mean, if it were, surely it would be part of the advertised feature-set? 86.135.238.18 ( talk) 18:48, 23 June 2012 (UTC)
I've marked an unsourced claim that a codec is "very fast" with {{ cn}}. Not sure whether it should be mentioned at all, since most codecs listed here have no information about speed or quality. — Frungi ( talk) 19:56, 8 January 2013 (UTC)
The article appears to be a list of data formats (the first sentence even says so), not codecs ("device or computer program capable of encoding or decoding"), so should be renamed accordingly. 203.176.108.99 ( talk) 00:03, 20 February 2013 (UTC)
Should this be added to the list?
New lossless audio codec launched Dec 2014.
Company site
3rd party news article covering launch
Also mentioned in BBC Click episode 17-Jan-15 - iPlayer link
— Preceding
unsigned comment added by
82.37.220.173 (
talk) 12:02, 18 January 2015 (UTC)
How about a traditional list with required articles (no red links) and no references? – Be..anyone ( talk) 21:40, 11 April 2016 (UTC)
That list has highlighted that "open" is a multi-factored thing - like having an open-source encoder, open-source decoder, and being free of patents. The status of each of those things could be indicated in this list if it were turned into a simple table. -- Beland ( talk) 04:38, 20 May 2016 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on List of 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:
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).
Cheers.— InternetArchiveBot ( Report bug) 10:32, 29 December 2017 (UTC)
tl;dr: Should GIF be added to the lossless video list?
I'm wondering if (animated) GIF should be added to the list of lossless video codecs. The pros are that it is very much a video format, it is lossless in that there is no generational loss, and for those videos for which it is well-suited (e.g. a limited color input where few pixels change between frames) it outperforms h264 lossless, h265 lossless, FFV1, MSU lossless, YULS, VP9-losless, and others by orders of magnitude, and does not require a x2, x4, or x8 size constraint.
The cons are that there is a first-time loss (colors reduced to a maximum 256 color palette per frame - although GIFs can switch palettes throughout their run, this is rarely used), few video players support GIF files, and those that do rarely support seeking the timeline - even if the GIF is constructed so that there are full frames available. In terms of the first-time loss, this is true for most formats considered lossless, as they often convert color spaces from regular RGB or even 10bit RGB for their encoders to work well.
Due to the extremely high compression ratio that can be reached for those specific cases for which other codecs are abysmally ill-suited, I would suggest that GIF be considered - but wanted to write my reasoning and seek feedback. Kmqz ( talk) 22:48, 12 May 2018 (UTC)
LiberatorG reverted my attempt to move unnecessary detail from Video codec to this list. I know that this move created some overlap here and I hoped we could iron that out over time. I don't feel it would be a good idea to restore this material to Video codec so I'll reproduce it below. ~ Kvng ( talk) 18:33, 19 March 2019 (UTC)
See the Audio full list and Video full list.
This Article is a List of Software called: CODECs it is not Article containing list of dead mere Codecs Specification / Standard, it is list of Codecs, and that is software: Decoder and Encoder.
" Computer program" == is software!
FFmpeg is mentioned next to almost every codec standard.
And some user change statement from true to false, by Writing that MPEG-5 codecs are under-development,
It is false, as Those 2 codecs are NOW fully developed.
Only Consumer Hardware is steel under development, or additional implementation in Software.— Preceding unsigned comment added by 46.187.199.166 ( talk • contribs)