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.
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.)
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.
clang printed warnings like:
stream/stream.c:692:65: warning: if statement has empty body [-Wempty-body]
GET_UTF16(c, src < end - 1 ? get_le16_inc(&src) : 0,;
This macro expands to "if(cond) ;". Replace it with an empty statement
that doesn't lead to a clang warning.
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 allowed to move the input stream layer across the network, allowing
the user to play anything that mplayer could play remotely. For example,
playing a DVD related on a remote server (say, with the host name
"remotehost1") could be done by starting the netstream server on that
remote server, and then running:
mplayer mpst://remotehost1/dvd://
This would open the DVD on the remote host, and transfer the raw DVD
sector reads over network. It works the same for other protocols, and
all accesses to the stream layer are marshaled over network. It's
comparable to the way the cache layer (--cache) works.
It has questionable use and most likely was barely used at all. There's
lots of potential for breakage, because it doesn't translate the stream
CTRLs to network packets. Just get rid of it.
The server used to be in TOOLS/netstream.c, and was accidentally removed
earlier.
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
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.
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.)
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.
open_stream() and open_output_stream() checked for filename==NULL, and
if true, printed an error message asking to report this as bug.
Internal logic errors should just crash. Use assert() instead.
Clean up handling of libquvi (which resolves URLs of streaming sites
into URLs to the actual media playable by mpv). Move the code out of
open.c to quvi.c, and invoke it explicitly from mplayer.c, instead of
trying to resolve every filename passed to open_stream().
This allows easily passing metadata from the quvi context to the
frontend. Expose QUVIPROP_PAGETITLE as "media-title" property, and use
that instead of "filename" for the mplayer window title. (For YouTube,
this is the video title.) It's cleaner too.
Handle a potential reliability issue: check quvi_getprop return values.
Since open.c contains barely anything but the open_stream() stub, move
that to stream.c and delete open.c.
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.
Options parsing used to be ambiguous, as in the splitting into option
and values pairs was ambiguous. Example:
-option -something
It wasn't clear whether -option actually takes an argument or not. The
string "-something" could either be a separate option, or an argument
to "-option". The code had to call the option specific parser function
to resolve this.
This made everything complicated and didn't even have a real use. There
was only one case where this was actually used: string lists
(m_option_type_string_list) and options based on it. That is because
this option type actually turns a single option into a proxy for several
real arguments, e.g. "vf*" can handle "-vf-add" and "-vf-clr". Options
suffixed with "-clr" are the only options of this group which take no
arguments.
This is ambiguous only with the "old syntax" (as shown above). The "new"
option syntax always puts option name and value into same argument.
(E.g. "--option=--something" or "--option" "--something".)
Simplify the code by making it statically known whether an option takes
a parameter or not with the flag M_OPT_TYPE_OLD_SYNTAX_NO_PARAM. If it's
set, the option parser assumes the option takes no argument.
The only real ambiguity left, string list options that end on "-clr",
are special cased in the parser.
Remove some duplication of the logic in the command line parser by
moving all argument splitting logic into split_opt(). (It's arguable
whether that can be considered code duplication, but now the code is a
bit simpler anyway. This might be subjective.)
Remove the "ambiguous" parameter from all option parsing related code.
Make m_config unaware of the pre-parsing concept.
Make most CONF_NOCFG options also CONF_GLOBAL (except those explicitly
usable as per-file options.)
Detect prematurely closed connection.
Then we get a streaming_stopped status but we have
a end_pos and have not reached it yet, do not accept
it as EOF but instead try reconnection.
For example a forced restart of a webserver will usually
result in the connection being closed before EOF.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34873 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Retry reconnecting several times.
Also add a delay, otherwise a server closing any incoming
connection immediately would make MPlayer stop even if it happens
only for 1 second or so.
With this change, no server/network outage of any kind shorter
than 5 seconds should cause MPlayer to give up anymore.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34871 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
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.
stream_cue, which provided the cue:// protocol handler, was extremely
hacky and didn't even manage to play some samples I tried.
Remove it, because it's plain unneeded. There is much better support
for .cue files elsewhere:
- libcdio can play pairs of .cue/.bin files:
mplayer cdda:// --cdrom-device=your_cue_file.cue
Note that if the .cue file is not accompanied by a .cue file, but
an encoded file for example, this most likely won't work.
- mplayer can play .cue files directly:
mplayer your_cue_file.cue
This works, even if the .cue file comes with encoded files that are
not .bin . Note that if you play .bin files, mplayer will assume a
specific raw audio format. If the format doesn't match, mplayer will
play noise and destroy your speakers. Note that format mismatches are
extremely common, because the endianness seems to be essentially
random. (libcdio uses a clever algorithm to detect the endian, and
doesn't have this problem.)
There are still various other RTSP implementations available, such as
libnemesi, live555, and libav. The mplayer native version was a huge
chunk of old unmaintained code.
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.
Command line options like "-foo xyz" are ambiguous: "xyz" may be a
parameter to the option "foo" or an unrelated argument. Instead of
relying on the struct m_config mode field (commandline/file) pass
parameters to specify ambiguous mode explicitly. Meant for "--foo"
options which are never ambiguous on command line either.
Improve checks for when to try reconnecting to be more thorough and
readable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33809 b3059339-0415-0410-9bf9-f77b7e298cf2
Reindent, add empty lines.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33810 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes a possible endless loop with HTTP files where seeking to
the very end returns the full file again instead of e.g. an error.
Apache/2.2.4 seems to show this behaviour.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33808 b3059339-0415-0410-9bf9-f77b7e298cf2
When reading from a stream fails, try one more time after a reset.
This should re-establish for example timed-out network connections.
Fixes bug #1841.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32954 b3059339-0415-0410-9bf9-f77b7e298cf2
100l, fix incorrect len when retrying read.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32957 b3059339-0415-0410-9bf9-f77b7e298cf2
Improve stream reset on read error, should now fix bug #1841 in more
cases, e.g. also with -cache.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32977 b3059339-0415-0410-9bf9-f77b7e298cf2
Add ugly hack to compensate DVDNAV's ugly hacks and fix seeking.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33122 b3059339-0415-0410-9bf9-f77b7e298cf2
None of the calling sites to stream_write_buffer were checking the
return value to see if all bytes got written (nothing in current code
actually calls it any more after MEncoder was removed).
This was causing (very occasionally) problems with mencoder when using
output pipes AND running under a sandbox or when being straced (ptrace
is the culprit). Theoretically this problem can happen without pipes
or ptrace.
Only stream_file, stream_smb and stream_ffmpeg implement
write_buffer and ffmpeg already handles this internally.
Original patch by Sang-Uok Kum.
Signed-off-by: Tobias Diedrich <ranma@google.com>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32881 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
Enable all of libavcodec, libavformat, libswscale, and libpostproc
together (libavutil is always required).
based on svn commit by diego:
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32226 b3059339-0415-0410-9bf9-f77b7e298cf2
Make sure we return an "empty" line on eof, to make sure we get
no buffer overflows in case some code fails to check the return value.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31999 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
and use this to support reading UTF-16 encoded subtitle files in subreader.c
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30799 b3059339-0415-0410-9bf9-f77b7e298cf2
it is not speed critical and the function call overhead is not
relevant for its overall speed anyway.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30796 b3059339-0415-0410-9bf9-f77b7e298cf2
format autodetection with -nocache and non-seekable streams.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30668 b3059339-0415-0410-9bf9-f77b7e298cf2
Reset stream 'eof' flag when a seek succeeds, and allow seeking to a
position at or past EOF (in the sense that the seek succeeds and
stream_tell() then returns that position).
This fixes at least some demuxer problems where an attempt to read
the index from the end of an incomplete file would set the 'eof' flag
and cause subsequent reads to fail, even if failure to read the index
would otherwise be nonfatal and demuxing could continue after seeking
back.
Partially based on a patch from Laurent <laurent.aml@gmail.com>.
name clashes, in particular with Windows headers (which define STREAM_SEEK as an enum type).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29962 b3059339-0415-0410-9bf9-f77b7e298cf2
enabled.
Enabling network support should not have side-effects on code not really
related to networking.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29926 b3059339-0415-0410-9bf9-f77b7e298cf2
and put it under the proper '#ifndef HAVE_CLOSESOCKET' condition.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27505 b3059339-0415-0410-9bf9-f77b7e298cf2
This caused lots of trouble on MinGW, we need a different solution.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27504 b3059339-0415-0410-9bf9-f77b7e298cf2
This is what it is called in FFmpeg and more consistent with other
names for similar conditionals. This fixes a potential compilation
failure on MinGW, as described in Bugzilla #1262.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27493 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace all USE_ prefixes by CONFIG_ prefixes to indicate
options which are configurable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27373 b3059339-0415-0410-9bf9-f77b7e298cf2
when stream cache is disabled.
noticed by Andrea Palmatè, andrea amigasoft net
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27210 b3059339-0415-0410-9bf9-f77b7e298cf2
Start moving static variables to a context struct. Only autorepeat
state is moved to the struct in this commit.
mp_input_check_interrupt now requires the context variable. Change
stream functions to pass it. It's still stored in a static variable in
stream/.
The stream code does not access many option variables directly, but it
does access some such as audio_id and network_bandwidth (and does that
without including proper headers for them). Add option pointer to the
stream struct to allow access to those variables. Remove the unused
(always NULL) and clumsy-looking char** options parameter in the
open_stream call and replace it with the option pointer. The parameter
is currently only set in the main open_stream() call in MPlayer.c and
not in any other locations that can open a stream.
In the long term it might be better to pass a more limited set of
values somehow, but this should do for now.
These functions aren't used outside their file and have no prototype
in any header. Based on a forgotten patch from 2006 by Stefan Huehner,
(stefan huehner org).
function. It also removes the compile-time dependency on input.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26358 b3059339-0415-0410-9bf9-f77b7e298cf2
directory and start dvd:// stream instead of file://.
If VTS_<N>_*.IFO is opened, open stream as dvd://<N>
As Nico Sabbi said:
There is no no guarantie that title N is in titleset N,
but there are at least good chances.
The main purpose of this patch is ability to load DVDs, stored on HDD,
using OSD menu.
Modified patch from Benjamin Zores ben at geexbox dot org
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25238 b3059339-0415-0410-9bf9-f77b7e298cf2
