pixfmt: remove misleading and broken documentation
This was probably broken some time ago. The breakage is now part of the ABI. For example, we have: AV_PIX_FMT_XYZ12BE AV_PIX_FMT_NV16 AV_PIX_FMT_NV20LE AV_PIX_FMT_NV20LE is wrong. It has the value 113, but as little-endian format it should be even. This must have been quite obvious when these formats were added (because of the AV_PIX_FMT_XYZ12BE entry), but nobody cared or knew about this. The future libavutil major bump will also break this additionally, because disabling FF_API_VDPAU will remove an odd number of entries from the middle of the enum. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This commit is contained in:
parent
e4610300de
commit
a64a5773ea
@ -54,11 +54,6 @@
|
||||
* For all the 8bit per pixel formats, an RGB32 palette is in data[1] like
|
||||
* for pal8. This palette is filled in automatically by the function
|
||||
* allocating the picture.
|
||||
*
|
||||
* @note
|
||||
* Make sure that all newly added big-endian formats have pix_fmt & 1 == 1
|
||||
* and that all newly added little-endian formats have pix_fmt & 1 == 0.
|
||||
* This allows simpler detection of big vs little-endian.
|
||||
*/
|
||||
enum AVPixelFormat {
|
||||
AV_PIX_FMT_NONE = -1,
|
||||
|
Loading…
Reference in New Issue
Block a user