Remove the duplication of image format name lists from codec-cfg.c
and img_format.c. Remove the list of "long" image format names from
img_format.c.
One user visible change is that now mplayer won't print "long" format
names anymore: e.g. instead of "Planar 420P 10-bit little-endian",
the name "420p10le" is used. This is consistent with the names used
by the option parser, and also less noisy.
Partially based on mplayer2 commit f98e47574de15, with some differences.
For some reason only 9-bit 422 wasn't added before.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34524 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
mplayer had three ways of enabling CPU specific assembler routines:
a) Enable them at compile time; crash if the CPU can't handle it.
b) Enable them at compile time, but let the configure script detect
your CPU. Your binary will only crash if you try to run it on a
different system that has less features than yours.
This was the default, I think.
c) Runtime detection.
The implementation of b) and c) suck. a) is not really feasible (it
sucks for users). Remove all code related to this, and use libav's CPU
detection instead. Now the configure script will always enable CPU
specific features, and disable them at runtime if libav reports them
not as available.
One implication is that now the compiler is always expected to handle
SSE (etc.) inline assembly at runtime, unless it's explicitly disabled.
Only checks for x86 CPU specific features are kept, the rest is either
unused or barely used.
Get rid of all the dump -mpcu, -march etc. flags. Trust the compiler
to select decent settings.
Get rid of support for the following operating systems:
- BSD/OS (some ancient BSD fork)
- QNX (don't care)
- BeOS (dead, Haiku support is still welcome)
- AIX (don't care)
- HP-UX (don't care)
- OS/2 (dead, actual support has been removed a while ago)
Remove the configure code for detecting the endianness. Instead, use
the standard header <endian.h>, which can be used if _GNU_SOURCE or
_BSD_SOURCE is defined. (Maybe these changes should have been in a
separate commit.)
Since this is a quite violent code removal orgy, and I'm testing only
on x86 32 bit Linux, expect regressions.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34245 b3059339-0415-0410-9bf9-f77b7e298cf2
Note: ffmpeg first introduced PIX_FMT_GBR24P, which was used in this
commit. Later, it was renamed to PIX_FMT_GBRP in ffmpeg and libav. This
was updated in revision 34492 in mplayer, but the mplayer specific
names (such as IMGFMT_GBR24) were left unchanged.
Commit aba8a1838a which added 9- and 10-bit formats failed to change
the definition of the IMGFMT_IS_YUVP16() macro (which is misnamed btw,
it matches 9, 10 and 16 bits). This prevented vo_gl from accepting
input in supported 9 and 10 bit colorspaces. Fix.
Make mp_get_chroma_shift() simpler/more generic and add an argument
to get the per-component bit depth.
Use this to check more properly for supported formats in
gl and gl2 vos (only 8 and 16 bit are supported, 9 and 10 are not).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33452 b3059339-0415-0410-9bf9-f77b7e298cf2
Add new internal 9/10-bit IMGFMT values and mappings to the
corresponding libav* PIX_FMT_* values.
Partially based on a patch from Arne Bochem <[email protected]>.
wm4