demux_lavf probes up to 2 MB of data in the worst case. When the ffmpeg
demuxer is actually opened, the stream is seeked back to 0, and the
previously read data is thrown away.
This wasn't a problem for playback of local files, but it's less than
ideal for playing from slow media (like web streams), and breaks
completely if the media is not seekable (pipes, some web streams).
This new function is intended to allow fixing this. demux_lavf will use
it to put the read probe data back into the buffer.
The simplest way of implementing this function is by making it
transparently extend the normal stream buffer. This makes sure no
existing code is broken by new weird special cases. For simplicity
and to avoid possible performance loss due to extra dereferencing
when accessing the buffer, we just extend the static buffer from
8 KB to 2 MB. Normally, most of these 2 MB will stay uncommitted, so
there's no associated waste of memory. If demux_lavf really reads all
2 MB, the memory will be committed and stay unused, though.
Before this commit, the cache was franken-hacked on top of the stream
API. You had to use special functions (like cache_stream_fill_buffer()
instead of stream_fill_buffer()), which would access the stream in a
cached manner.
The whole idea about the previous design was that the cache runs in a
thread or in a forked process, while the cache awa functions made sure
the stream instance looked consistent to the user. If you used the
normal functions instead of the special ones while the cache was
running, you were out of luck.
Make it a bit more reasonable by turning the cache into a stream on its
own. This makes it behave exactly like a normal stream. The stream
callbacks call into the original (uncached) stream to do work. No
special cache functions or redirections are needed. The only different
thing about cache streams is that they are created by special functions,
instead of being part of the auto_open_streams[] array.
To make things simpler, remove the threading implementation, which was
messed into the code. The threading code could perhaps be kept, but I
don't really want to have to worry about this special case. A proper
threaded implementation will be added later.
Remove the cache enabling code from stream_radio.c. Since enabling the
cache involves replacing the old stream with a new one, the code as-is
can't be kept. It would be easily possible to enable the cache by
requesting a cache size (which is also much simpler). But nobody uses
stream_radio.c and I can't even test this thing, and the cache is
probably not really important for it either.
Some code in mplayer.c did stuff like accessing (dvd_priv_t *)st->priv.
Do this indirectly by introducing STREAM_CTRL_GET_DVD_INFO. This is
extremely specific to DVD, so it's not worth abstracting this further.
This is a preparation for turning the cache into an actual stream, which
simply wraps the cached stream. There are other streams which are
accessed in the way DVD was, at least TV/radio/DVB. We assume these
can't be used with the cache. The code doesn't look thread-safe or fork
aware.
Tests with demux_mkv show that the speed doesn't change (or actually,
it seems to be faster after this change). In any case, there is not
the slightest reason why these should be inline. Functions for which
this will (probably) actually matter, like stream_read_char, are
still left inline.
This was tested with demux_mkv's indexing. For broken files without
index, demux_mkv creates an on-the-fly index. If you seek to a later
part of the file, all data has to be read and parsed until the wanted
position is found. This means demux_mkv will do mostly I/O, calling
stream_read_char() and stream_read(). This should be the most I/O
intensive non-deprecated part of mpv that uses the stream interface.
(demux_lavf has its own buffering.)
Allow the stream layer to report chapter times. Extend stream_dvd to do
this. I'm not 100% sure whether the re-used code is bug-free (because it
was used for slave-mode and/or debugging only).
MAke the frontend do time-based seeks when switching DVD chapters. I'm
not sure if there's a real reason STREAM_CTRL_SEEK_TO_CHAPTER exists
(maybe/hopefully not), but we will see.
Note that querying chapter times in demuxer_chapter_time() with the new
STREAM_CTRL_GET_CHAPTER_TIME could be excessively slow, especially with
the cache enabled. The frontend likes to query chapter times very often.
Additionally, stream_dvd uses some sort of quadratic algorithm to list
times for all chapters. For this reason, we try to query all chapters on
start (after the demuxer is opened), and add the chapters to the demuxer
chapter list. demuxer_chapter_time() will get the time from that list,
instead of asking the stream layer over and over again.
This assumes stream_dvd knows the list of chapters at the start, and
also that the list of chapters never changes during playback. This
seems to be true, and the only exception, switching DVD titles, is not
supported at runtime (and doesn't need to be supported).
Will be needed to override the demuxer's start time reporting. We could
be lazy and special-case it since the result is always 0 for the streams
that care, but doing it properly is better.
DVD playback uses a demuxer that signals to the frontend that timestamp
resets are possible. This made the frontend calculate the OSD playback
position based on the byte position and the total size of the stream.
This actually broke DVD playback position display. Since DVD reports a
a linear playback position, we don't have to rely on the demuxer
reported position, so disable this functionality in case of DVD
playback. This reverts the OSD behavior with DVD to the old behavior.
This didn't work properly for HTTP with libavformat. The builtin HTTP
implementation reconnects automatically on its own, while libavformat
doesn't. Fix this by adding explicit reconnection support to
stream_lavf.c, which simply destroys and recreates the AVIO context.
It mostly works, though sometimes it mysteriously fails, spamming crap
all over the terminal and feeding broken data to the decoders. This is
probably due to itneractions with the cache. Also, reconnecting to
unseekable HTTP streams will make it read the entire stream until the
previous playback position is reached again.
It's not known whether this change makes behavior with "strange"
protocols like RTP better or worse.
This is a fix for web radio streams that send raw AAC [1]. libavformat's
AAC demuxer probe is picky enough to request hundreds of KBs data, which
makes for a slow startup. To speed up stream startup, try use the HTTP
MIME type to identify the format. The webstream in question sends an AAC
specific MIME type, for which demux_lavf will force the AAC demuxer,
without probing anything.
ffmpeg/ffplay do the same thing. Note that as of ffmpeg commit 76d851b,
av_probe_input_buffer() does the mapping from MIME type to demuxer. The
actual mapping is not publicly accessible, and can only be used by
calling that function. This will hopefully be rectified, and ideally
ffmpeg would provide a function like find_demuxer_from_mime_type().
[1] http://lr2mp0.latvijasradio.lv:8000
Use ffmpeg (stream_lavf) instead of internal mms support (asf_streaming.c)
for mms://, mmsh://, mmst:// URLs.
The old implementation is available under mp_mms:// etc.
There are some caveats with this:
- mms:// now always maps to mmsh://. It won't try mmst://. (I'm not sure
if mms:// URLs really can use the mmst protocol, though.)
- MMS streams under the http:// prefix are not handled. (ffmpeg ticket
#2001.) (Was already broken in mpv since c02f25.)
- It downloads all video streams now. MMS streams often have redundant
video streams, which encode the main stream at different quality. The
client is supposed to select one according to its bandwidth
requirements. (Explicit MMS stream selection has been broken in mpv
for a while, because MPOpts.vid maps to the stream number, not the
demuxer's stream ID - but the old logic doesn't work anyway when
using demuxer_lavf as opposed to demux_asf.)
When the cache fill status goes below a certain threshold, automatically
pause the player. When the cache is filled again, unpause again.
This is intended to help with streaming from http. It's better to pause
a while, rather than exposing extremely crappy behavior when packet
reads during decoding block the entire player.
In theory, we should try to increase the cache if underruns happen too
often. Unfortunately, changing the cache implementation would be very
hard, because it's insane code (forks, uses shared memory and "volatile"
etc.). So for now, this just reduces the frequency of the stuttering if
the network is absolutely too slow to play the stream in realtime.
This commit is separate from the previous one to separate our own
changes from changes merged from mplayer2 (as far as that was possible).
Make it easier for stream implementations to request being cached. Set
a default cache size in stream.c, and remove them from various stream
implementations. Only MS streaming support sets a meaningful cache size.
Make querying cache size saner. This reduces the amount of #ifdefs
needed.
Code enabling the cache by default for network streams did that by
modifying the value of the "cache" option. This wasn't sane, as
multiple streams may be created and all share the same options. Change
the code to not modify options but store data in the stream instance
instead.
Conflicts:
core/mplayer.c
demux/demux.c
stream/cache2.c
stream/network.c
stream/network.h
stream/pnm.c
stream/stream.c
stream/stream_rtp.c
Merged from mplayer2 commit e26070. Note that this doesn't solve any
actual bug, as the playlist crashing bug has been fixed before.
Since the global cache size option value is not overwritten anymore, the
option doesn't need to be restored on end of playback (M_OPT_LOCAL).
libavdevice supports various "special" video and audio inputs, such
as screen-capture or libavfilter filter graphs.
libavdevice inputs are implemented as demuxers. They don't use the
custom stream callbacks (in AVFormatContext.pb). Instead, input
parameters are passed as filename. This means the mpv stream layer has
to be disabled. Do this by adding the pseudo stream handler avdevice://,
whose only purpose is passing the filename to demux_lavf, without
actually doing anything.
Change the logic how the filename is passed to libavformat. Remove
handling of the filename from demux_open_lavf() and move it to
lavf_check_file(). (This also fixes a possible bug when skipping the
"lavf://" prefix.)
libavdevice now can be invoked by specifying demuxer and args as in:
mpv avdevice://demuxer:args
The args are passed as filename to libavformat. When using libavdevice
demuxers, their actual meaning is highly implementation specific. They
don't refer to actual filenames.
Note:
libavdevice is disabled by default. There is one problem: libavdevice
pulls in libavfilter, which in turn causes symbol clashes with mpv
internals. The problem is that libavfilter includes a mplayer filter
bridge, which is used to interface with a set of nearly unmodified
mplayer filters copied into libavfilter. This filter bridge uses the
same symbol names as mplayer/mpv's filter chain, which results in symbol
clashes at link-time.
This can be prevented by building ffmpeg with --disable-filter=mp, but
unfortunately this is not the default.
This means linking to libavdevice (which in turn forces linking with
libavfilter by default) must be disabled. We try doing this by compiling
a test file that defines one of the clashing symbols (vf_mpi_clear).
To enable libavdevice input, ffmpeg should be built with the options:
--disable-filter=mp
and mpv with:
--enable-libavdevice
Originally, I tried to auto-detect it. But the resulting complications
in configure did't seem worth the trouble.
The language string was dynamically allocated, which completely fails
if the cache is forked (which it usually is). Change it back to a fixed
length string, like the original code had it.
Finish renaming directories and moving files. Adjust all include
statements to make the previous commit compile.
The two commits are separate, because git is bad at tracking renames
and content changes at the same time.
Also take this as an opportunity to remove the separation between
"common" and "mplayer" sources in the Makefile. ("common" used to be
shared between mplayer and mencoder.)
Add new stream control command STREAM_CTRL_GET_CURRENT_TITLE for DVDs.
This provides the current title (aka track) number of a DVD.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35263 b3059339-0415-0410-9bf9-f77b7e298cf2
Previously, Matroska source files other than the initially opened one
were always accessed without caching. Enable cache for extra files
too. A separate cache process/thread is started for each file, which
is less than optimal but probably better than no caching if the user
explicitly enabled cache. This commit only implements caching for
Matroska ordered chapters (not for EDL timeline).
To build the timeline we need to demux the files in the current
directory to look for segments with matching uuid. This first demux is
done with no cache since we don't need to read a lot of the stream. If
the file is recognized as one of the needed sources it's reopened with
cache enabled.
Also move the stream_cache_size global variable to the options struct.
Conflicts:
cfg-mplayer.h
mplayer.c
stream/stream.h
timeline/tl_matroska.c
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.
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.
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.
Code cleanup: Use a stream_control instead of global functions to
get the language associate with a audio or subtitle stream from
the streaming layer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34736 b3059339-0415-0410-9bf9-f77b7e298cf2
Support showing the stream language with br:// playback.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34737 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix DVDs showing the subtitle language as "unknown"
for a long time.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34777 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Note: heavily modified by wm4 for this fork of mplayer.
Remove variable that is only assigned but never used.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34791 b3059339-0415-0410-9bf9-f77b7e298cf2
Allow using a cache size of up to 4 TB.
Obviously anything close to 4 GB will always fail
on 32 bit systems.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34792 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace off_t by int64_t in cache code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34793 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove casts that are no longer necessary.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34794 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix header file after r34793.
Patch by Stephen Sheldon, sfsheldo gmail com.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34802 b3059339-0415-0410-9bf9-f77b7e298cf2
Put #include <inttypes.h> into the header file where it should be.
Reported by Stephen Sheldon, sfsheldo gmail com.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34798 b3059339-0415-0410-9bf9-f77b7e298cf2
Correct r34798.
The header only needs stdint.h while the C file needs inttypes.h.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34799 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
This provides the total number of titles (aka tracks) of CDs / VCDs / DVDs.
Additionally, add a titles property to the get_property slave command.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34474 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: ib
'q' is just a deprecated synonym of 'll' that should no longer be used.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34224 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: diego
While this was an interesting idea, it wasn't actually useful.
Basically it dumped the raw data (as requested by the demuxer) into a
file. The result is only useful if the file format was raw or maybe
some MPEG packet stream, but not with most modern file formats.
Make "Invalid seek to negative position" message more useful by
printing the actual value.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33556 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove some unused lines from demuxer.h. Make some demuxer.c functions
static. Move new_ds_stream() declaration from demuxer.h to stream.h
(the function is defined in stream.c). Clean up some code in mplayer.c
that had commented-out free_demuxer_stream() calls.
Add validity check for stream_seek argument to avoid a integer
overflow for huge negative values that would break the internal state
of the stream buffer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32702 b3059339-0415-0410-9bf9-f77b7e298cf2
Make the file protocol read up to 64 KiB at once when the cache is used,
assuming that files will generally be readable with high bandwidth.
This should improve performance when playing e.g. from high-latency
network shares.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32616 b3059339-0415-0410-9bf9-f77b7e298cf2
Add a stream_read_internal() function that reads directly into a given
buffer instead of the stream's internal one. Use this to read directly
into cache memory, avoiding a memcpy(). This requires also adding a
stream_seek_internal() as the normal seek function reads into the
stream's buffer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32559 b3059339-0415-0410-9bf9-f77b7e298cf2
If a specified key is pressed during playback, the current stream is
captured to a file, similar to what -dumpstream achieves.
original patch by Pásztor Szilárd, don tricon hu
Taken from the following svn commits, but with several fixes and
modifications (one obvious user-visible difference is that the default
key binding is 'C', not 'c'):
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32524 b3059339-0415-0410-9bf9-f77b7e298cf2
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32529 b3059339-0415-0410-9bf9-f77b7e298cf2
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32530 b3059339-0415-0410-9bf9-f77b7e298cf2
Add sanity-check for sector size to avoid strange crashes if it is
too large.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31914 b3059339-0415-0410-9bf9-f77b7e298cf2
This avoids conflicts with the FFmpeg variable of the same name.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31749 b3059339-0415-0410-9bf9-f77b7e298cf2
Support for unencrypted Blu-ray playback through libbluray.
Use it through: mplayer br:////path/to/disc
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31631 b3059339-0415-0410-9bf9-f77b7e298cf2
Never just ignore a backwards skip, even if the stream is not seekable
it might still be in a buffer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31465 b3059339-0415-0410-9bf9-f77b7e298cf2
wm4
reimar
Uoti Urpala
ib
Stefano Pigozzi
mplayer-svn
Clément Bœsch
Uoti Urpala
diego
ben