Talk:Video codec

Video Codec Benchmarking

The following discussion 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.

---

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)

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.

Spyware in links

The following discussion 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.

---

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)

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.

'Commonly used' lossless codecs links to the whole list

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

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. 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.

— Preceding unsigned comment added by ScotXW (talk • contribs) 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:ScotXW^t@lk 22:57, 30 June 2014 (UTC)

References

"Video codec design" section would be more appropriate at video coding format

Any objections to me moving the "Video codec design" section to the video coding format article, and renaming the section to "coding format design"? Technical details such as the use of the YCbCr color space are features of the coding format, while the codec is simply an implementation following the coding format specification. There are of course design choices to make when making a codec implementing a coding format specification, but the technical details in the current "Video codec design" section are design choices made by the specification, not the codec. Thue (talk) 11:58, 23 April 2015 (UTC)

No objection but I'm having a hard time distinguishing the scope of the two articles. Perhaps a merge is in order. ~Kvng (talk) 21:15, 13 November 2018 (UTC)