This was needed by the now-removed mov demuxer for QuickTime video, or
to be more specific, the Sorenson 3 video codec. QuickTime can
(probably) still decoded by libavcodec, but this field is not needed
for this.
The reference in demux_mkv was apparently for decoding QuickTime in
Matroska, using binary QuickTime codecs (QTX stuff). It's possible that
this has been broken with the binary codecs removal (see commit
aebfbbf2bd), because it removed related code from demux_mkv. On the
other hand, the code section in question was enabled only if binary
win32 codecs were enabled. The win32 codec loader worked on 32 bit x86
only. This means QuickTime-in-Matroska was broken on all other
architectures, including 64 bit x86. Despite being possibly broken on a
major platform, nobody has complained about it yet, and since I couldn't
find a sample of such a mkv file, so don't bother with it.
demux_lavf and demux_mkv, which both support demuxing subtitles, set
the global variable sub_utf8. This variable is connected with the -utf8
option, and should not be reset by code. Since demuxer subtitles are not
influenced by this option (anymore?), this is unnecessary. Remove the
code setting this variable from the demuxers.
Add a new slave property which switches the current Matroska edition.
Since each edition can define an entirely new timeline, switching the
edition will simply restart playback at the beginning of the file with
the new edition selected.
Add 'E' as new keybinding to step the edition property.
DVD titles are still separate. Apparently they work similarly, but I
don't have any multi-title DVDs for testing. Also, cdda (for audio CDs)
uses the same mechanism as DVDs to report a number of titles, so there
seems to be confusion what exactly this mechanism is supposed to do.
That's why the edition code is completely separate for now.
Remove demuxer.num_titles. It was just a rather useless cache for the
return value of the DVD titles related STREAM_CTRL.
One rather obscure corner case isn't taken care of: if the ordered
chapters file has file local options set, they are reset on playback
restart. This is unexpected, because edition switching is meant to
behave like seeking back to the beginning of the file.
libavformat replaces demux_audio completely. I don't know/care what
vivo (demux_viv) is. libavformat has a Real demuxer; it seems it works
slightly better, with a different set of bugs.
Remove the win32 loader - the win32 emulation layer, as well as the
code for using DirectShow/DMO/VFW codecs. Remove loading of xanim,
QuickTime, and RealMedia codecs.
The win32 emulation layer is based on a very old version of wine.
Apparently, wine code was copied and hacked until it was somehow able
to load a limited collection of binary codecs. It poked around in the
code segment of some known binary codecs to disable unsupported win32
API calls to make them work. Example from module.c:
for (i=0;i<5;i++) RVA(0x19e842)[i]=0x90; // make_new_region ?
for (i=0;i<28;i++) RVA(0x19e86d)[i]=0x90; // call__call_CreateCompatibleDC ?
for (i=0;i<5;i++) RVA(0x19e898)[i]=0x90; // jmp_to_call_loadbitmap ?
for (i=0;i<9;i++) RVA(0x19e8ac)[i]=0x90; // call__calls_OLE_shit ?
for (i=0;i<106;i++) RVA(0x261b10)[i]=0x90; // disable threads
Just to show how utterly insane this code is. You wouldn't want even
your worst enemy to have to maintain this. In fact, it seems nobody
made major changes to this code ever since it was committed.
Most formats can be decoded by libavcodecs these days, and the loader
couldn't be used on 64 bit platforms anyway. The same is (probably)
true for the other binary codecs.
General note about how support for win32 codecs could be added back:
It's not possible to replace the win32 loader code by using wine as
library, because modern wine can not be linked with native Linux
programs for certain reasons. It would be possible to to move DirectShow
video decoding into a separate process linked with wine, like the
CoreAVC-for-Linux patches do. There is also the mplayer-ww fork, which
uses the dshownative library to use DirectShow codecs on Windows.
There are different C types for each stream type: sh_video for video,
sh_audio for audio, sh_sub for sub. There is no type that handles all
stream types in a generic way. Instead, there's a macro SH_COMMON, that
is used to define common fields for all 3 stream structs. Accessing
the common fields is hard if you want to be independent from the stream
type.
Introduce an actual generic stream struct (struct sh_stream), which is
supposed to unify all 3 stream types one day. Once all fields defined
by SH_COMMON have been moved into sh_stream, the transition is complete.
Move some fields into sh_stream, and rewrite osd_show_tracks to use
them.
When playing a file, users (i.e. me) expect mplayer to print a list of
video/audio/subtitle streams. Currently, this is done in each demuxer
separately. This also means the output is formatted differently
depending which demuxer is active.
Add code to print an uniformly formatted streams list in the player
front end. Extend the streams headers to export additional information
about the streams. Change the lavf and mkv demuxers to follow this new
scheme, and raise the log level for the "old" printing functions.
The intention is to make every demuxer behave like this eventually.
The stream list output attempts to provide codec information. It's a
bit hacky and doesn't always provide useful output, and I'm not sure
how to do it better.
There was some confusion about the "flags" field in demuxer packets.
Demuxers set it to either 1 or 0x10 to indicate a keyframe (and the
field was not used to indicate anything else). This didn't cause
visible problems because nothing read the value. Replace the "flags"
field with a boolean "keyframe" field. Set AV_PKT_FLAG_KEY based on
this field in packets fed to libavcodec video decoders (looks like PNG
and ZeroCodec are the only ones which depend on values from demuxer;
previously this was hardcoded to true for PNG).
Make demux_mf set the keyframe field in every packet. This matters for
PNG files now that the demuxer flag is forwarded to libavcodec.
Fix logic setting the field in demux_mkv. It had probably not been
updated when adding SimpleBlock support. This probably makes no
difference for any current practical use.
Remove the private bswap and intreadwrite.h implementations and use
libavutil headers instead.
Originally these headers weren't publicly installed by libavutil at
all. That already changed in 2010, but the pure C bswap version in
installed headers was very inefficient. That was recently (2011-12)
improved and now using the public bswap version probably shouldn't
cause noticeable performance problems, at least if using a new enough
compiler.
After 0ece360eea ("demux_mkv: skip files faster in ordered chapter
file search") some Matroska files failed to open. The problem was that
demux_mkv_read_info() returned 0 on success, but the opening code
interpreted this as a value to stop parsing further headers. Fix this
and also modify some of the other return value handling.
Export the codec private data field for WavPack and TrueHD audio
tracks. At least for WavPack this is necessary to make some samples
work.
Also change some other cases to use the same data-copying code.
When switching audio or video tracks, demux_mkv only checked that the
new index fell in the range corresponding to tracks existing in the
file being played. However, if the demuxer can not recognize the
format of a track or detects an error, some of those tracks in the
file may not be exported from the demuxer and are not visible to the
rest of the player. Selecting such a track would cause a crash. Add
checks skip such tracks when cycling to next track and switch to
nosound instead if given an explicit track number corresponding to
such a track.
demuxer.c calls demuxer->close() even if opening failed. Thus the
mkv_free() call added in 0ece360eea ("demux_mkv: skip files faster
in ordered chapter file search") was wrong, and could cause a crash
from a double free if some data structures were allocated before the
opening attempt was aborted.
Ordered chapter code tries opening files to find those matching the
SegmentUID values specified in the timeline. Previously this scan did
a full initialization of the Matroska demuxer for each file, then
checked whether the UID value in the demuxer was a match. Make the
scan code instead provide a list of searched-for UIDs to the demuxer
open code, and make that do a comparison against the list as soon as
it sees the UID in the file, aborting if there is no match.
Also fix units used in "Merging timeline part" verbose message.
Rename the BSTR() function to bstr(). The former caused a conflict
with some Windows OS name, and it's no longer a macro so uppercase
naming is less appropriate.
If the played file has per-track titles for audio and subtitles show
those on the OSD when switching tracks. This changes the OSD message
from 'Audio: (2) eng' to 'Audio: (2) eng ("Director's commentary")'.
Remove code that tries to select audio track during demuxer
initialization from demux_mkv and demux_lavf. Just leave audio
disabled at that point; the higher-level select_audio() function will
call the demuxer to switch track later anyway.
Removing this unneeded code also fixes use of these demuxers as the
main demuxer with -audiofile. Before the automatic track selection
would have enabled an audio track (if the file had any); as the main
demuxer was not used for audio the unused packets from this enabled
track would accumulate until they reached queue size limits.
Commit de42015a97 ("demux_mkv: read tags") added code that
failed to initialize a loop variable. Fix. No visible problems caused
by the bug have been reported.
Duration may now be set for packet types other than subtitles; as far
as I can tell nothing should care. A check requiring valid duration
values for subtitles is removed, because duration may not be properly
set for all bitmap subtitle types; hopefully this doesn't make the
behavior with (already broken) subtitles without duration worse.
demux_mkv kept various integer timestamps in millisecond units.
Matroska timestamp arithmetic is however specified in nanoseconds
(even though files typically use 1 ms precision), and using ms units
instead of that only made things more complex. Based on the demux_mkv
example the general demuxer-level chapter structure also used ms
units. Change the demux_mkv arithmetic and demuxer chapter structures
to use nanoseconds instead. This also fixes a seeking problem in
demux_mkv with files using a TimecodeScale other than the usual
1000000 (confusion between ms and TimecodeScale*ns units).
Make seeks backward from a time before the first index entry go to the
first entry instead of failing completely. This change doesn't affect
behavior for most files, because seeks are clamped to 0 from below and
normally files have the first index entry at 0.
Use the value of the OutputSamplingFrequency element instead of the
SamplingFrequency element as the "container samplerate". In most cases
this only removes a warning, as those typically differ for SBR AAC
files and there was already a special case detecting this in
ad_ffmpeg.
The implementation adds a new "container_out_samplerate" field to the
sh_audio struct. Reusing the existing "samplerate" field and the
equivalent inside the 'wf' struct and just setting those to the new
value instead would probably work (at least I'm not aware of any codec
that would need the original SamplingFrequency for initialization).
However using a separate field also avoids some ugliness: the 'wf'
struct may not exist (though most demuxers create it), and the
'samplerate' field is overwritten to reflect the final value decided
by codec when decoding is first initialized.
Due to a bug created back in 2006 when SimpleBlock support was added,
demux_mkv demuxed one audio packet from the initial file position
after a seek, then skipped the following ones until a video keyframe
was found. This wasn't very noticeable earlier, but it had bad effects
after the recently added -initial-audio-sync code as the extra packet
with an earlier timestamp confused timing calculations and resulted in
desync after seeking. Fix.
Commit fc66c94360 ("demux_mkv: seek: with no track-specific index
entries use any") used uint64_t for a variable that should have been
int64_t. Fix. The practical effects of this error were minor; mainly
it made the player unnecessarily read the file contents between the
previous index entry and the correct one when seeking.
The Cue entries in typical Matroska files have information for the
video track only. This caused seeks to fail when playing with
-novideo, as demux_mkv tried to use audio track index entries then.
Add a fallback case that uses any index entries without caring what
track they're for if there are no entries specific to the track we're
interested in.
Relative seeks didn't add the current position as they should. Fix.
Note that this had no effect in normal playback case even if the file
had no index, because the "accurate_seek" logic at higher level would
convert all commands to absolute seeks before calling demuxer level.
Add some checks to prevent bad files from creating arbitrarily large
buffer blocks (which could result in integer overflows and memory
corruption). Remove a test with little use from demux_mkv_decode(); it
compared an int with size_t, and was useless on 64-bit platforms at
least.
Replace malloc+memset by calloc
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32181 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32182 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32183 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace some sizeof(type) by sizeof(*pointer)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32184 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32186 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32187 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32188 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace sizoef(type) by sizeof(*ptrvar).
Besides being consistent with FFmpeg style,
this reduces the size of a patch to rename these
types to not conflict with the windows.h definitions.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32189 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32191 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32192 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace sizeof(type) by sizeof(*ptrvar)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32193 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove a useless cast.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32194 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace sizeof(type)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32195 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove a useless cast.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32196 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace several sizeof(WAVEFORMATEX)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32197 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace one more instance of sizeof(WAVEFORMATEX); fix compilation.
patch by Clément Bœsch, ubitux gmail com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32199 b3059339-0415-0410-9bf9-f77b7e298cf2
Avoid some pointless uses of sizeof() and one related cast.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32200 b3059339-0415-0410-9bf9-f77b7e298cf2
Merge one malloc() + memset() invocation into calloc().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32202 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32203 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace sizeof(WAVEFORMATEX) occurrences.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32205 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32206 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace sizeof(BITMAPINFOHEADER)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32207 b3059339-0415-0410-9bf9-f77b7e298cf2
Assume files which start with an EBML header but have no DocType
element in that header have type "matroska", and attempt to play
them. Reportedly some mkvmerge versions create such files.
Change demux_mkv to behave by default as it did with -idx before. The
index generation code in demux_mkv linearly scans the file up to the
seek timestamp (it doesn't read the whole file up front like some
other demuxers do). Doing that is probably a better default for files
with no index than rejecting the seek request and asking user to
specify -idx.
Commit fc39d48465 ("demux_mkv: store streams sequentially in
demuxer->[avs]_streams") had a copy-paste error causing it to look up
a video ID where it should have been an audio one. The most likely
visible symptom was a segfault when seeking while playing a
high-numbered audio track. Looks like I was careless with that
original commit, second bug in the same one...
Change 'struct vf_instance' pointer arguments to more standard style
as in the subject. Also some other minor formatting fixes.
Patch by Diego Biurrun.
