diff options
author | wm4 <wm4@nowhere> | 2017-06-03 22:41:45 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2017-06-03 22:49:15 +0200 |
commit | eae693fc46cc6d108b434cbd33d97243ec97282e (patch) | |
tree | f9f6cd762905f954e61951a8c81b60cc9b1a0480 /video/out/x11_common.c | |
parent | 7424651b9637082f71deab9fcc87111e2d9df13f (diff) | |
download | mpv-eae693fc46cc6d108b434cbd33d97243ec97282e.tar.bz2 mpv-eae693fc46cc6d108b434cbd33d97243ec97282e.tar.xz |
demux_mkv: support FFmpeg A_MS/ACM extensions
Indeed, FFmpeg found a way to maximize the misery around VfW/AVI-style
muxing. It appears it can mux a number of random codecs by using random
format tags. To make this even more stranger, it has a probably custom
GUID for signaling them, although for unknown reasons this is done only
"sometimes" (judging from FFmpeg's riffenc.c).
Whatever, it's not too hard to support it. Also apparently fix the
incorrect interpretation of extended formats - there's absolutely no
reason to assume they're always PCM. Instead, check for the correct
GUIDs. Also while we're at it, move the channel mask handling also to
codec_tag.c, so all WAVEFORMATEXTENSIBLE handling is in one place. (With
the normal wav header handling strangely still in demux_mkv.c.)
The case I was looking at (aac_latm muxing) decodes now. While I'm not
entirely sure about its correctness (libavformat has a weird
special-case for SBR), it certainly doesn't try to play it as PCM,
which is much of an improvement.
The extradata mess in the demux_mkv.c A_MS/ACM code path is unfortunate
and ugly, but has less impact than refactoring all the code to make
this specific case nicer.
Did I mention yet that I hate VfW-style mkv muxing?
Diffstat (limited to 'video/out/x11_common.c')
0 files changed, 0 insertions, 0 deletions