fast_memcpy, defined in fastmemcpy.h, used to be mplayer's "optimized"
memcpy. It has been removed from this fork, and fast_memcpy has been
reduced to an alias for memcpy. Replace all remaining uses of the
fast_memcpy macro alias.
Code from libavformat's demuxer.
Merged by wm4. It looks like the byte stream writer API is private in
newer ffmpeg, so use the macros from <libavutil/intreadwrite.h>
instead.
It's not really known how to correctly set the field that is used by
the decoder to calculate the length of the last frame. The original
patch used:
put_le32(&b, (demuxer->movi_end - demuxer->movi_start) * sh_a->samplerate);
This doesn't seem to be correct. Write 0 instead. This is also
incorrect, but better than writing an essentially random value.
ebml_read_length() could return a negative value (as uint64_t though)
at EOF, and this would then make ebml_read_skip() seek backwards. This
could lead to an infinite loop at EOF with corrupt files. Add an extra
check to make ebml_read_length() return EBML_UINT_INVALID instead if
EOF is hit in the middle of parsing.
If block_align was 0, demux_lavf changed it to 1. This breaks at least
decoding of IMA ADPCM in LVF. Pass it through without changing instead.
(nBlockAlign as set in demux_lavf is put back into lavc's block_align
in ad_ffmpeg.)
This reverts 296f360f82. This commit gives no explanation why it does
things the way it does. But since nothing in mpv uses nBlockAlign
anymore except ad_ffmpeg, this is probably safe.
mplayer (and all forks) use a single FourCC field to map codecs. This is
what sh_video->format and sh_audio->format is used for. Basically it's a
key into the codecs.conf table to find out what decoder to use. (There's
only one video codec and one major audio codec left - both libavcodec.
But we still have to deal with mapping coming from non-libavformat
demuxers.)
It seems this causes some video codecs to fail, such as WV1F in AVI [1].
demux_lavf generally throws away the codec_tag from libavformat if the
codec is MPEG-in-AVI. There are probably other cases like this. Add a
hack to enforce passing the correct codec tag when only ffmpeg demuxers
and decoders involved.
Note: the sample [1] needs to be flipped. With --demuxer=avi, this is
done correctly, because unlike demux_lavf, the demuxer uses the FourCC
directly for the sh_video->format tag, and finds the correct codecs.conf
entry (which contains the flip flag). We could just add a "whitelist" of
codec tags which can be passed through to sh_video->format, but I don't
want to do that just for such an obscure format as the sample at hand.
Note 2: when demux_lavf is used, the AVCodecContext could be passed
directly to vd_ffmpeg/ad_ffmpeg. The code to convert to/from the
internal mplayer stream headers is probably still needed, as there are
non-ffmpeg demuxers and audio decoders.
[1] http://samples.mplayerhq.hu/V-codecs/WV1F/AVI/title2.avi
The -ni option does something with the AVI demuxer only.
Also fix misleading error messages when the packet queue overflows (it
suggests using -ni, which in the typical case of playing NI AVI files
will not work, as demux_lavf is used by default).
Fix reading language from teletext descriptor when it is not
the first descriptor in the block.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35198 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove "inline" from functions that are definitely not
absolutely critical for performance.
The compiler should be able to make a more intelligent
decision on its own.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35197 b3059339-0415-0410-9bf9-f77b7e298cf2
Support subrip format subtitles.
Patch by Philip Langdale [philipl overt org].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35118 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demux_lavf.c
When switching programs select subtitle stream regardless of
whether the format is text, ASS, bitmap or whatever.
There probably was some good reason for the condition but
it got lost in time and special-casing CODEC_ID_TEXT over other
test-based subtitles doesn't seem to make much sense.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35117 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demux_lavf.c
Make stream_ffmpeg handle rtsp:// URLs by default, without requiring
ffmpeg://rtsp://. Previously (after removal of other rtsp
implementations) rtsp:// fell back to using HTTP, which was unlikely
to work.
Also add lavf:// as an alternative to ffmpeg:// to force the stream
implementation. Since libavformat can come from Libav rather than
FFmpeg, using the ffmpeg name in the prefix is misleading.
This changes the name of this project to mpv. Most user-visible mentions
of "MPlayer" and "mplayer" are changed to "mpv". The binary name and the
default config file location are changed as well.
The new default config file location is: ~/.mpv/
Remove etc/mplayer.desktop. Apparently this was for the MPlayer GUI,
which has been removed from mplayer2 ages ago.
We don't have a logo, and the MS Windows resource files sort-of require
one, so leave etc/mplayer.ico/.xpm as-is.
Remove the debian and rpm packaging scripts. These contained outdated
dependencies and likely were more harmful than useful. (Patches which
add working and well-tested packaging are welcome.)
rawvideo is a rather primitive demuxer that doesn't implement track
switching. The problem was that during track switching the demuxer
implementations normally set the stream IDs in order to do the switch,
and since rawvideo obviously didn't do that, so the current stream in
ds->sh / demuxer->video->sh was set to NULL. (The frontend always
assumes track switching is successful, which is a reasonable
assumption - failing due to missing video codecs etc. is in separate
codepaths.) Later, demux_rawvideo_fill_buffer() in demux_rawvideo.c
tried to dereference the NULL stream and crashed.
Other trivial single-stream demuxers worked fine, because they didn't
try to access ds->sh.
Someone wanted this. Apparently both libavformat's TS demuxer and
demux_ts are crap, and work/fail in different cases.
This demuxer has been removed in 1fde09db6f. All code added comes
from the revision before that. Some required bits have been added in
the commit before this one (re-adding demux_mpg), in particular the
changes to video.c.
stream_dvb will use this demuxer by default, otherwise demux_lavf is
preferred (as it has been before).
Some TS related command line options are not re-added.
Closed captions might not work.
Apparently this was needed for good DVD playback.
This demuxer has been removed in 1fde09db6f. All code added comes
from the revision before that. Some other bits have been removed in
later commits, and are added back as well.
Usage of memalign() is replaced by av_malloc(). As far as I can tell,
this memory is never free'd or reallocated, so no calls to av_free()
have been added.
The code re-added to video.c is plain horrible, full of code
duplication, full of demuxer/codecs specifics, but apparently needed.
Unrelated to re-adding the demuxer, re-add one codepath for
DEMUXER_TYPE_TV, which was accidentally removed in the same commit
demux_mpg was removed.
The closed captions decoder is not re-added.
The rawaudio demuxer had a rather hard to use way to set the audio
format with the --rawaudio=format=value option. The user had to pass a
numeric value, which then was set as wFormatTag member in the
WAVEFORMATEX header.
Make it use the mplayer audio format (the same as --af=format=value).
Add a new internal pseudo audio codec tag, which is hopefully unused,
which makes ad_pcm use the value in wFormatTag as internal mplayer
audio format.
Playing non-PCM formats is disabled. (At least AC3 can be played
directly.)
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 all subtitle tracks as reported by libdvdread at playback start.
Display language for subtitle and audio tracks. This commit restores
these features to the state when demux_mpg was default for DVD playback,
and makes them work with demux_lavf and the recent changes to subtitle
selection in the frontend.
demux_mpg, which was the default demuxer for DVD playback, reordered
the subtitle streams according to the "logical" subtitle track number,
which conforms to the track layout reported by libdvdread, and is what
stream_dvd expects for the STREAM_CTRL_GET_LANG call. demux_lavf, on
the other hand, adds the streams in the order it encounters them in
the MPEG stream. It seems this order is essentially random, and can't
be mapped easily to what stream_dvd expects.
Solve this by making demux_lavf hand out the MPEG stream IDs (using the
demuxer_id field). The MPEG IDs are mapped by mplayer.c by special
casing DVD playback (map_id_from/to_demuxer() functions). This mapping
is essentially the same what demux_mpg did. Making demux_lavf reorder
the streams is out of the question, because its stream handling is
already messy enough.
(Note that demux_lavf doesn't export stream IDs for other formats,
because most time libavformat demuxers do not set AVStream.id, and we
don't know which demuxers do. But we know that MPEG is safe.)
Another major complication is that subtitle tracks are added lazily, as
soon as the demuxer encounters the first subtitle packet for a given
subtitle stream. Add the streams in advance. If a yet non-existent
stream is selected, demux_lavf must be made to auto-select that subtitle
stream as soon as it is added. Otherwise, the first subtitle packet
would be lost. This is done by DEMUXER_CTRL_PRESELECT_SUBTITLE.
demux_mpg didn't need this: the frontend code could just set ds->id to
the desired stream number. But demux_lavf's stream IDs don't map
directly to the stream number as used by libdvdread, which is why this
hack is needed.
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.
Introduce a general track struct for every audio/video/subtitle track
known to the frontend. External files (subtitles) are now represented
as tracks too. This mainly serves to clean up the subtitle selection
code: now every subtitle is simply a track, instead of using a messy
numbering that goes by subtitle type (as it was stored in the
global_sub_pos field). The mplayer fontend will list external subtitle
files as additional tracks.
The timeline code now tries to match the exact demuxer IDs of all
tracks. This may cause problems when Matroska files with different
track numberings are used with EDL timelines. Change demux_lavf not
to set demuxer IDs, since most time they are not set.
af_format.h declares some symbols which are defined in format.c. The
fact that af_format.c is a completely unrelated file is rather
confusing. Having the header and implementation file use the same base
name is more uniform. (af_format.c is the audio conversion filter, while
af_format.h and format.c are about audio formats and their properties.)
Also fix all source files which include this file.
If either of them is not defined, the old behavior is used:
- the colormatrix is guessed based on resolution.
- the color range is assumed to be tv aka limited range.
The only decoder which could handle demux_gif's output was vd_raw,
which has been removed recently. Instead of re-adding vd_raw, make it
work with vd_ffmpeg.
By coincidence, the FourCC "raw " fits our needs and it understood by
the ffmpeg raw decoder (apparently used in mov files going by
libavcodec/rawdec.c). Since there doesn't seem to be any good way to
transport the palette in mplayer dmuxer packets, create an AVPacket for
this purpose. (struct sh_video provides a "global" palette. Rather than
hacking vd_ffmpeg to use it, it seems cleaner to make demux_gif use
AVPacket, which supports a per-frame palette.)
Change vd_ffmpeg such that if sh_video->format is a mplayer pixel
format, and there's no other codec information, try to play it as raw
video. (The case of no codec information happens if the "generic" ffmpeg
decoder is instantiated, which is tried last. This means clashes with
actual existing formats are less likely.)
demux_mng did not initialize all fields of the bih, which made vd_ffmpeg
do invalid memory accesses when trying to copy the extradata. Also, use
IMGFMT_RGB32 instead of creating the FourCC directly. (They should be
the same, but what if mplayer changes the IMGFMT_* values.)
This also fixes demux_rawvideo.
Probably all of these are supported by libavcodec. Missing things can
be added back.
Also remove qtpalette.h. It was used by demux_mov.c, and should have
been deleted with commit 1fde09db6f.
The main excuse for removing this is that LIVE555 deprecated the API
the mplayer implementation was using. The old API still seems to be
somewhat supported, but must be explicitly enabled at LIVE555
compilation, so mplayer won't always work on any user installation.
The implementation was also very messy, in C++, and FFmpeg support is
available as alternative.
Remove it completely.
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.
When the internal mplayer MPEG demuxer was removed (commit 1fde09db),
the default demuxer when using dvdnav was set to libavformat. Now it
turns out that this doesn't work with libavformat. It will terminate
playback right after the audio runs out (instead of looping it like the
video, or whatever it's supposed to do). I'm not sure what exactly the
problem is, but since 1. even mplayer-svn can't handle DVD menus
directly (missing highlights), 2. DVD menus are essentially worthless,
and 3. I don't directly watch DVDs, don't bother with it and remove it.
For basic playback, there's still libdvdread support.
Also, use pkg-config for libdvdread, and drop support for in-tree
libdvdread. Remove support for in-tree libdvdcss as well.
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.
Libavformat does not distinguish between "no codec_tag given" and
"codec_tag given, value is 0". 0 can be a valid value. Change
demux_lavf to assume that 0 always means unset for audio. This
prevents incorrect selection of the PCM decoder, which includes
"format 0x0" in its codecs.conf entry. The video case accepts 0 iff
codec_id is RAWVIDEO, but there's no obvious similar check possible
for audio. Thus this could possibly cause issues if a file really uses
0 to mean uncompressed audio.
Commit 9c02ae7e95 set the sh variable (see diff) to the struct of
type sh_sub instead the one of sh_stream. Unfortunately this didn't
crash, and merely made the OSD show "unknown" for the language.
Commit 804bf91570 accidentally removed the display of the track
title. Add it back.
The removed VO and AO took MPEG data and decoded it with V4L2. I'm not
exactly sure what's the use of this today, but get rid of it.
As far as feeding video data to V4L2 is concerned, there are other
ways. For example, there is this script, that feeds yuv4mpeg formatted
raw video data to V4L2:
https://raw.github.com/umlaeute/v4l2loopback/master/examples/yuv4mpeg_to_v4l2.c
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.
Generally enable parsing for audio streams.
The formats I know of that do not need it (e.g. raw audio) do
not have a parser anyway.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35050 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Return a spf value even when srate is NULL.
Based on patch by Benoît Thébaudeau [benoit thebaudeau advansee com]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34916 b3059339-0415-0410-9bf9-f77b7e298cf2
Make some tables const.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34917 b3059339-0415-0410-9bf9-f77b7e298cf2
Use more appropriate types.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34918 b3059339-0415-0410-9bf9-f77b7e298cf2
Some minor simplifications.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34919 b3059339-0415-0410-9bf9-f77b7e298cf2
Cosmetics: fix up indentations, get rid of a few lost tabs.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34920 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove unused code from mp_get_mp3_header.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34923 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Take start offset into account when calculating amount of audio data.
Patch by Benoît Thébaudeau [benoit thebaudeau advansee com]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34915 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Add some additional checks to ensure subtractions do not overflow.
Patch by Benoît Thébaudeau [benoit thebaudeau advansee com].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34914 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
wm4
Kovensky
Stefano Pigozzi
Uoti Urpala
reimar
cehoyos
cantabile
mplayer-svn