summaryrefslogtreecommitdiffstats
path: root/video
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-11-02 15:10:28 +0100
committerwm4 <wm4@nowhere>2013-11-02 15:14:12 +0100
commit4d903127ad799e84cc19f8ff4f5c5abf0d35a9a8 (patch)
tree64fcf21f27827229c5c493f370045e9bc528d0ff /video
parent7b52ba87a3d1ca23df677f7a681839d821b21375 (diff)
downloadmpv-4d903127ad799e84cc19f8ff4f5c5abf0d35a9a8.tar.bz2
mpv-4d903127ad799e84cc19f8ff4f5c5abf0d35a9a8.tar.xz
demux: rename Windows symbols
There are some Microsoft Windows symbols which are traditionally used by the mplayer core, because it used to be convenient (avi was the big format, using binary windows decoders made sense...). So these symbols have the exact same definition as the Windows one, and if mplayer is compiled on Windows, the symbols from windows.h are used. This broke recently just because some files were shuffled around, and the symbols defined in ms_hdr.h collided with windows.h ones. Since we don't have windows binary decoders anymore, there's not the slightest reason our symbols should have the same names. Rename them to reduce the risk for collision, and to fix the recent regression. Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines its own version if the windows headers don't define it, and ao_wasapi is not available on systems where this symbol is missing. Also reindent ms_hdr.h.
Diffstat (limited to 'video')
-rw-r--r--video/decode/vd_lavc.c20
1 files changed, 10 insertions, 10 deletions
diff --git a/video/decode/vd_lavc.c b/video/decode/vd_lavc.c
index 309d5dbcfd..ebfd986a95 100644
--- a/video/decode/vd_lavc.c
+++ b/video/decode/vd_lavc.c
@@ -310,13 +310,13 @@ static int init(sh_video_t *sh, const char *decoder)
}
static void set_from_bih(AVCodecContext *avctx, uint32_t format,
- BITMAPINFOHEADER *bih)
+ MP_BITMAPINFOHEADER *bih)
{
switch (format) {
- case mmioFOURCC('S','V','Q','3'):
- case mmioFOURCC('A','V','R','n'):
- case mmioFOURCC('M','J','P','G'):
+ case MP_FOURCC('S','V','Q','3'):
+ case MP_FOURCC('A','V','R','n'):
+ case MP_FOURCC('M','J','P','G'):
/* AVRn stores huffman table in AVI header */
/* Pegasus MJPEG stores it also in AVI header, but it uses the common
* MJPG fourcc :( */
@@ -329,11 +329,11 @@ static void set_from_bih(AVCodecContext *avctx, uint32_t format,
memcpy(avctx->extradata, bih + 1, avctx->extradata_size);
break;
- case mmioFOURCC('R','V','1','0'):
- case mmioFOURCC('R','V','1','3'):
- case mmioFOURCC('R','V','2','0'):
- case mmioFOURCC('R','V','3','0'):
- case mmioFOURCC('R','V','4','0'):
+ case MP_FOURCC('R','V','1','0'):
+ case MP_FOURCC('R','V','1','3'):
+ case MP_FOURCC('R','V','2','0'):
+ case MP_FOURCC('R','V','3','0'):
+ case MP_FOURCC('R','V','4','0'):
if (bih->biSize < sizeof(*bih) + 8) {
// only 1 packet per frame & sub_id from fourcc
avctx->extradata_size = 8;
@@ -341,7 +341,7 @@ static void set_from_bih(AVCodecContext *avctx, uint32_t format,
FF_INPUT_BUFFER_PADDING_SIZE);
((uint32_t *)avctx->extradata)[0] = 0;
((uint32_t *)avctx->extradata)[1] =
- format == mmioFOURCC('R','V','1','3') ?
+ format == MP_FOURCC('R','V','1','3') ?
0x10003001 : 0x10000000;
} else {
// has extra slice header (demux_rm or rm->avi streamcopy)