The problem with DVD/BD and playback resume is that most often, the
filename is just "dvd://", while the actual path to the DVD disk image
is given with --dvd-device. But playback resume works on the filename
only.
Add a pretty bad hack that includes the path to the disk image if the
filename starts with dvd://, and the same for BD respectively. (It's a
bad hack, but I want to go to bed, so here we go. I might revert or
improve it later, depending on user feedback.)
We have to cleanup the global variable mess around the dvd_device.
Ideally, this should go into MPOpts, but it isn't yet. Make the code
paths in mplayer.c take MPOpts anyway.
By default, libavformat uses UDP for rtsp playback. This doesn't work
very well. Apparently the reason is that the buffer sizes libavformat
chooses for UDP are way too small, and switching to TCP gets rid of this
issue entirely (thanks go to Reimar Döffinger for figuring this out).
In theory, you can set buffer sizes as libavformat options, but that
doesn't seem to help.
Add an option to select the rtsp transport, and make TCP the default.
Also remove an outdated comment from stream.c.
Mainly for debugging. Usually, we just set options for all possible
protocols, and we can't really know whether a certain protocol is used
beforehand. That's also the reason why avio_open2() takes a dictionary,
instead of letting the user set options directly with av_opt_set(). Or
in other words, we don't know whether an option that could be set is an
error or not, thus we print the messages only at verbose level.
I have a sample where some final chapters are missing. This was causing a
segmentation fault when trying to fetch chapter times for them.
This makes the code ignore those chapters.
MPlayer handles this correctly, because MPlayer still has the FourCC
codec dispatch (codecs.conf). We need to handle this case specially,
because the libavformat rawvideo decoder will of course not eat mjpeg.
mjpeg is the only supported format, though. (Even MPlayer needs to
convert between V4L2 formats and MPlayer FourCCs, and mjpeg is the only
non-raw format.)
Until now, stream_peek() read only the bare minimum it had to read from
the stream. But this could cause problems, such as being very
inefficient when peeking a lot, or conflicting with ability to seek
back. (The latter issue can be caused by peeking a few bytes, and then
doing a stream_read() with a size that is 1 byte longer: this would read
the peeked data, then call stream_fill_buffer(), which throws away the
previously peeked bytes - so you can't seek back anymore. This is
mitigated by a hack in demux_open(): it peeks a full buffer, to avoid
that peeking/reading during demuxer probing [or before that, in a stream
filter] can cause the buffer to be dropped.)
Apparently, it is popular to store large files in uncompressed rar
archives. Extracting files is not practical, and some media players
suport playing directly from uncompressed rar (at least VLC and some
DirectShow components).
Storing or accessing files this way is completely idiotic, but it is
a common practice, and the ones subjected to this practice can't do
much to change this (at least that's what I assume/hope). Also, it's
a feature request, so we say yes.
This code is mostly taken from VLC (commit f6e7240 from their git tree).
We also copy the way this is done: opening a rar file by itself yields
a playlist, which contains URLs to the actual entries in the rar file.
Compressed entries are simply skipped.
Add a stream filter concept, in which streams can be opened on top of
an underlying "source" stream. Change the open code to make this
easier, and also to account for some mechanisms that will be needed
for this.
The following commit will add stream_rar, which contains such a stream
filter.
This is really not needed. While we really can't take a loaded buffer
over to the cache, there's no reason why the cache couldn't read this
buffer normally.
On the other hand, this code could cause trouble when probing from a
stream before the cache has been enabled.
The way the url_options field was handled was not entirely sane: it's
actually a flexible array member, so it points to garbage for streams
which do not initialize this member (it just points to the data right
after the struct, which is garbage in theory and practice). This was
not actually a problem, since the field is only used if priv_size is
set (due to how this stuff is used). But it doesn't allow setting
priv_size only, which might be useful in some cases.
Also, make the protocols array not a fixed size array. Most stream
implementations have only 1 protocol prefix, but stream_lavf.c has
over 10 (whitelists ffmpeg protocols). The high size of the fixed
size protocol array wastes space, and it is _still_ annoying to
add new prefixes to stream_lavf (have to bump the maximum length),
so make it arbitrary length.
The two changes (plus some more cosmetic changes) arte conflated into
one, because it was annoying going over all the stream implementations.
Modeled after the old playlist_parser.c, but actually new code, and it
works a bit differently.
Demuxers (and sometimes streams) are the component that should be used
to open files and to determine the file format. This was already done
for subtitles, but playlists still use a separate code path.
Instead of always skipping in STREAM_BUFFER_SIZE blocks, allow an
arbitrary size. This allows - in theory - faster forward seeking in
pipes.
(Maybe not a very significant change, but it reduces the number of
things that depend on STREAM_BUFFER_SIZE for no good reason. Though
we still use that value as minimum read size.)
stream_file.c contains some code meant for forward seeking with pipes.
This simply reads data until the seek position is reached. Move this
code to stream.c. This stops stream_file from doing strange things
(messing with stream internals), and removes the code duplication too.
We also make stream_seek_long() use the new skip code. This is shorter
and much easier to follow than the old code, which basically did strange
things.
Using the radio set/step channel commands would have crashed (that was
broken for about a year, nobody ever noticed). The "capture" part of
a radio:// URI was incorrectly passed (this was broken quite recently).
Still couldn't test it fully. I have no radio device. I suspect nobody
uses this feature or will ever use it again.
So for example "file:///file%20name.mkv" will open "file name.mkv".
I'm not sure whether we want/need this. The old code didn't do it.
Also, it's not really clear whether this is handled correctly. It
seems the corresponding freedesktop.org "standard" allows a (useless)
hostname part, which we should skip in theory. The number of slashes
is not really clear either. We can open relative filenames (by removing
one of the slashes from the example above), which is perhaps an
unneeded feature. How does this even work with Windows paths?
This issues can probably be corrected later.
The URL unescape code is based on code from m_option.c removed with
a recent commit.
Move the URL parsing code from m_option.c to stream.c, and simplify it
dramatically. This code originates from times when http code used this,
but now it's just relict from other stream implementations reusing this
code. Remove the unused bits and simplify the rest.
stream_vcd is insane, and the priv struct is different on every
platform, so drop the URL parsing. This means you can't specify a track
anymore, only the device. (Does anyone use stream_vcd? Not like this
couldn't be fixed, but it doesn't seem worth the effort, especially
because it'd require potentially touching platform specific code.)
The URL option parser only accesses certain fields. Remove the fields
that are not accessed, and thus are completely unused and inaccessible.
Historically, these fields were supposed to be settable using an extra
list of options passed to open_stream(). Commit f518cf7 removed these
extra options. Apparently nothing ever actually used this facility.
In general, this warning can hint to actual bugs. We don't enable it
yet, because it would conflict with some unmerged code, and we should
check with clang too (this commit was done by testing with gcc).
These were printed only with -v. Most streams had them set to useless
or redundant values, so it's just badly maintained bloat.
Since we remove the "author" field too, and since this may have
copyright implications, we add the contents of the author fields to
the file headers, except if the name is already part of the file header.
Stream implementations could set this to a unix file descriptor. The
generic stream code could use it as fallback for a few things. This
was confusing and insane. In most cases, the stream implementations
defined all callbacks, so setting the fd member didn't have any
advantages, other than avoiding defining a private struct to store it.
It appears that even if the stream implementation used close() on the
fd (or something equivalent), stream.c would close() it a second time
(and on windows, even would call closesocket()), which should be proof
for the insanity of this code.
For stream_file.c, additionally make sure we don't close stdin or
stdout if "-" is used as filename.
For stream_vcd.c, remove the control() code. This code most likely
didn't make the slightest sense, because it used a different type
for stream->priv. It also leaked memory. Maybe it worked, but it's
incorrect and insignificant anyway, so kill it. This code was added
with commit 9521c19 (svn commit 31019).
Untested for all protocols other than stream_file.c.
Get rid of the strange and messy reliance on DEMUXER_TYPE_ constants.
Instead of having two open functions for the demuxer callbacks (which
somehow are both optional, but you can also decide to implement both...),
just have one function. This function takes a parameter that tells the
demuxer how strictly it should check for the file headers. This is a
nice simplification and allows more flexibility.
Remove the file extension code. This literally did nothing (anymore).
Change demux_lavf so that we check our other builtin demuxers first
before libavformat tries to guess by file extension.
This removes the dependency on DEMUXER_TYPE_* and the file_format
parameter from the stream open functions.
Remove some of the playlist handling code. It looks like this was
needed only for loading linked mov files with demux_mov (which was
removed long ago).
Delete a minor bit of dead network-related code from stream.c as well.
Generally remove all accesses to demux_stream from all the code, except
inside of demux.c. Make it completely private to demux.c.
This simplifies the code because it removes an extra concept. In demux.c
it is reduced to a simple packet queue. There were other uses of
demux_stream, but they were removed or are removed with this commit.
Remove the extra "ds" argument to demux fill_buffer callback. It was
used by demux_avi and the TV pseudo-demuxer only.
Remove usage of d_video->last_pts from the no-correct-pts code. This
field contains the last PTS retrieved after a packet that is not NOPTS.
We can easily get this value manually because we read the packets
ourselves. Reuse sh_video->last_pts to store the packet PTS values. It
was used only by the correct-pts code before, and like d_video->last_pts,
it is reset on seek. The behavior should be exactly the same.
Currently, all demuxer fill_buffer functions have a demux_stream
parameter. We want to remove that, but the TV code still depends on
it. Add a hack to remove that dependency.
The problem with the TV code is that reading video and audio frames
blocks, so in order to avoid a deadlock, you should read either of
them only if the decoder actually requests new data.
This is not directly related to the handling of format changes itself,
but playing audio normally after the change. This was broken: the output
byte rate was not recalculated, so audio-video sync was simply broken.
Fix this by calculating the byte rate on the fly, instead of storing it
in sh_audio.
Format changes are relatively common (switches between stereo and 5.1
in TV recordings), so this fixes a somewhat critical bug.
Add this option, which lets users set the cache size without forcing it
even when playing from the local filesystem.
Also document the default value explicitly.
The Matroska linked segments case is slightly simplified: they can
never come from network (mostly because it'd be insane, and we can't
even list files from network sources), so the cache will never be
enabled automatically.
This is a regression caused by 854303a. This commit removed the include of
`sys/time.h` which was included in `cache.c` through a chain of recurvive
includes.
These separate arrays were used by the old demuxers and are not needed
anymore. We can simplify track switching as well.
One interesting thing is that stream/tv.c (which is a demuxer) won't
respect --no-audio anymore. It will probably work as expected, but it
will still open an audio device etc. - this is because track selection
is now always done with the runtime track switching mechanism. Maybe
the TV code could be updated to do proper runtime switching, but I
can't test this stuff.
Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does
better than them (except in rare corner cases), and the demuxers have
a bad influence on the rest of the code. Often they don't output
proper packets, and require additional audio and video parsing. Most
work only in --no-correct-pts mode.
Remove them to facilitate further cleanups.
Commit 7b16d4b changed some stream implementations to check the buffer
size passed to them. This made stream_cdda stop working, because the
default buffer size is smaller than the CDIO frame size. So pass the
sector size instead of the (arbitrary) default buffer size.
Seeking to position 0 meant to try reconnecting with some streams,
actually just the internal http implementation. This has been removed,
so we don't need the special handling anymore.
This means we don't have to be stuck in a retry loop if the stream
doesn't even support reconnect.
stream_vstream.c in particular was actually dependent on the network
code, and didn't compile anymore.
Cleanup the protocol list in mpv.rst, and add some missing ones
supported by libavformat to stream_lavf.c.
This was an old leftover from an earlier cleanup (which happened in
2003), and which used "special" stuff for streams that could be only
forward-seeked.
Also, don't add mode flags to s->flags; they're supposed to be in
s->mode instead.
This was under CONFIG_NETWORKING, so in theory it should have been save
to remove. But actually this disables forward skipping when reading
from a pipe. (Still a questionable feature, because it doesn't behave
well with libavformat - but it was not supposed to be changed.)
This commit removes the "old" networking code in favor of libavformat's
code.
The code was still used for mp_http, udp, ftp, cddb. http has been
mapped to libavformat's http support since approximately 6 months ago.
udp and ftp have support in ffmpeg (though ftp was added only last
month). cddb support is removed with this commit - it's probably not
important and rarely used if at all, so we don't care about it.
When reading something successfully, the eof flag should never be 1, so
clear it in these situations. The eof flag will be set properly on the
next read call.
STREAM_CTRL_GET_METADATA will be used to poll for streamcast metadata.
Also add DEMUXER_CTRL_UPDATE_INFO, which could in theory be used by
demux_lavf.c. (Unfortunately, libavformat is too crappy to read metadata
mid-stream for mp3 or ogg, so we don't implement it.)
stream_read_unbuffered() can sometimes return negative values on error.
Change that to return 0 - the negative values are nowhere used anyway.
If distinguishing errors and EOF is really needed, a flag could be added
instead.
This also fixes the stream_read_partial() call in cache.c, which assumes
the return values is always >= 0.
Querying this caused the cache to block and wait. Some parts of the
frontend (like progress bar) call this very often, so cache performance
was ruined in these cases.
Also print a message in -v mode when the cache is blocked for a
STREAM_CTRL. This should make debugging similar issues easier.
Seems like a completely unnecessary complication. Instead, always add a
1 byte padding (could be extended if a caller needs it), and clear it.
Also add some documentation. There was some, but it was outdated and
incomplete.
Or rather, keep hacking it until it somehow works. The problem here was
that trying to avoid calling STREAM_CTRL_GET_CURRENT_TIME too often
didn't really work, so the cache sometimes returned incorrect times.
Also try to avoid the situation that looking up the time with an
advanced read position doesn't really work, as well as when trying to
look it up when EOF or cache end has been reached. In that case we have
read_filepos == max_filepos, which is "outside" of the cache, but
querying the time is still valid.
Should also fix the issue that demuxing streams with demux_lavf and if
STREAM_CTRL_GET_CURRENT_TIME is not supported messed up the reported
playback position.
This stuff is still not sane, but the way the player tries to fix the
playback time and how the DVD/BD stream inputs return the current time
based on the current byte position isn't sane to begin with. So, let's
leave it at bad hacks.
The two changes that touch s->eof are unrelated and basically of
cosmetic nature (separate commit would be too noisy.)
This is useless on the cache side. The sector is needed only to deal
with stream implementations which are not byte addressable, and the
cache is always byte addressable.
Also set a default read_chunk value. (This value is never used unless
you chain multiple caches, but it's cleaner.)
DVD and bluray packet streams carry (essentially) random timestamps,
which don't start at 0, can wrap, etc. libdvdread and libbluray provide
a linear timestamp additionally. This timestamp can be retrieved with
STREAM_CTRL_GET_CURRENT_TIME.
The problem is that this timestamp is bound to the current raw file
position, and the stream cache can be ahead of playback by an arbitrary
amount. This is a big problem for the user, because the displayed
playback time and actual time don't match (depending on cache size),
and relative seeking is broken completely.
Attempt to fix this by saving the linear timestamp all N bytes (where
N = BYTE_META_CHUNK_SIZE = 16 KB). This is a rather crappy hack, but
also very effective.
A proper solution would probably try to offset the playback time with
the packet PTS, but that would require at least knowing how the PTS can
wrap (e.g. how many bits is the PTS comprised of, and what are the
maximum and reset values). Another solution would be putting the cache
between libdvdread and the filesystem/DVD device, but that can't be done
currently. (Also isn't that the operating system's responsibility?)
This was probably done this way to ensure that after a successful seek,
the reported stream position is the same as the requested seek position.
But it doesn't make too much sense, since both stream->pos and the
stream implementation's internal position will go out of sync.
The stream EOF flag should only be set when trying to read past the end
of the file (relatively similar to unix files). Always clear the EOF
flag on seeking. Trying to set it "properly" (depending whether data is
available at seek destination or not) might be an ok idea, but would
require attention to too many special cases. I suspect before this
commit (and in MPlayer etc. too), the EOF flag wasn't handled
consistently when the stream position was at the end of the file.
Fix one special case in ebml.c and stream_skip(): this function couldn't
distinguish between at-EOF and past-EOF either.
EOF should be set when reading more data fails. The stream
implementations have nothing to say here and should behave correctly
when trying to read when EOF was actually read.
Even when seeking, a correct EOF flag should be guaranteed. stream_seek()
(or actually stream_seek_long()) calls stream_fill_buffer() at least
once, which also updates the EOF flag.
This function was called in various places. Most time, it was used
before a seek. In other cases, the purpose was apparently resetting
the EOF flag. As far as I can see, this makes no sense anymore. At
least the stream_reset() calls paired with stream_seek() are completely
pointless. A seek will either seek inside the buffer (and reset the
EOF flag), or do an actual seek and reset all state.
This happens with something like "mpv https://www.youtube.com/watch".
The URL is obviously not valid, but the stream layer tries to reconnect.
This commit at least allows to use the terminal to abort gracefully.
(Other than killing the process.)
Basically rewrite all the code supporting the cache (i.e. anything other
than the ringbuffer logic). The underlying design is untouched.
Note that the old cache2.c (on which this code is based) already had a
threading implementation. This was mostly unused on Linux, and had some
problems, such as using shared volatile variables for communication and
uninterruptible timeouts, instead of using locks for synchronization.
This commit does use proper locking, while still retaining the way the
old cache worked. It's basically a big refactor.
Simplify the code too. Since we don't need to copy stream ctrl args
anymore (we're always guaranteed a shared address space now), lots of
annoying code just goes away. Likewise, we don't need to care about
sector sizes. The cache uses the high-level stream API to read from
other streams, and sector sizes are handled transparently.
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.
These assumed that the buffer provided with fill_buffer() was at least
sector sized, instead of checking the size parameter.
This is just a cleanup, since every caller made sure to align everything
on sector sizes, if a stream has the sector size set.
Of course all of stream_dvd.c (as well as libdvdread) is completely
insane, but at least this hack for ancient broken compilers on really
obscure platforms should be safe to remove.
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.
Internally, stream_dvd.c returned DEMUXER_TYPE_MPEG_PS, and the same
value was hardcoded to enforced usage of demux_lavf in demux.c. But
"-demuxer mpegps" basically did the same, so that switch was broken
for this format. Undo this and don't request a demuxer in stream_dvd.c.
demux_lavf.c is (probably) good enough to probe correctly with DVD.
Otherwise, we'd actually have to do something completely different to
force the libavformat demuxer.
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.)
GetTimer() is generally replaced with mp_time_us(). Both calls return
microseconds, but the latter uses int64_t, us defined to never wrap,
and never returns 0 or negative values.
GetTimerMS() has no direct replacement. Instead the other functions are
used.
For some code, switch to mp_time_sec(), which returns the time as double
float value in seconds. The returned time is offset to program start
time, so there is enough precision left to deliver microsecond
resolution for at least 100 years. Unless it's casted to a float
(or the CPU reduces precision), which is why we still use mp_time_us()
out of paranoia in places where precision is clearly needed.
Always switch to the correct time. The whole point of the new timer
calls is that they don't wrap, and storing microseconds in unsigned int
variables would negate this.
In some cases, remove wrap-around handling for time values.
This helps passing the channel layout correctly from decoder to audio
filter chain. (Because that part "reuses" the demuxer level codec
parameters, which is very disgusting.)
Note that ffmpeg stuff already passed the channel layout via
mp_copy_lav_codec_headers(). So other than easier dealing with the
demuxer/decoder parameters mess, there's no real advantage to doing
this.
Make the --channels option accept a channel map. Since simple numbers
map to standard layouts with the given number of channels, this is
downwards compatible. Likewise for demux_rawaudio.
Uses the same mechanisms as stream_dvd to report the virtual playback
time as known by libdvdread/libbluray, instead of the raw demuxer
output.
This should solve many problems with BD playback, like correct display
of playback time and duration.
On the other hand, this causes some new problems. For example, the
reported stream time has a rather low resolution (1-2 seconds), so
doing precise seeking on it is near impossible.
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).
These were found by the cppcheck and scan-build static analyzers. Most
of these aren't interesting (the 2 previous commits fix some interesting
cases found by these analyzers), and they don't nearly fix all warnings.
(Most of the unfixed warnings are spam, things MPlayer never cared
about, or false positives.)
Commit 4d14a42, a seemingly harmless change, introduced very bad cache
behavior when the cache isn't forked, such as on Windows, where it uses
threads. Apparently the cache code was designed for forking, and an
unknown obscure condition causes severe performance degradation if a
STREAM_CTRL is sent to the cache on every frame.
Since the cache code is literally insane (uses shared memory + fork(),
and has hacks to make it work with threads, is messed into the stream
code in extra-hacky ways), we just fix it by caching the STREAM_CTRL in
question.
This is also done for some other STREAM_CTRLs that are called on each
frame, such as playback duration. This indicates that the cache code has
some inherent problem with answering such requests in a timely matter,
and that there's no easy way around this.
(Even if the cache is eventually rewritten, these things will probably
have to be cached, otherwise you'd have to forcibly block until the
stream implementation is done with a blocking read. The real question
is why it worked fine with the forked cache, though.)
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.
br://: Fix querying current chapter.
This also fixes specifying an end chapter via -chapter.
Based on patch by Olivier Rolland [billl users.sourceforge.net]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36173 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove the "object settings" based track range parsing (needed by
stream_cdda only), and make stream_cdda use CONF_TYPE_INT_PAIR.
This makes the -vf parsing code completely independent from other
options. A bit of that code was used by the mechanism removed with
this commit.
ntddcdrm.h is no longer under the 'ddk' directory in MinGW-w64,
and since MPV focuses on it instead of the old MinGW32, there's no
reason to keep that dir prefix, as it stops VCD support from being
built at all for Windows.
Handle the severely broken headers QuickTime Streaming Server sends.
Instead of ending the header with \r\n\r\n it ends with
\r\n<4 byte MP3 header>\r\n.
And programs like wget just silently accept this without even
printing a warning!!
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35988 b3059339-0415-0410-9bf9-f77b7e298cf2
Note: see previous commit.
Support broken icy-metaint response from QuickTime Streaming Server.
The full version string is "QuickTime Streaming Server 6.1.0/532".
It sends a HTTP response header that contains an MP3 header!
Fixes bug #2133.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35987 b3059339-0415-0410-9bf9-f77b7e298cf2
Note that in mpv, "http://" is mapped to ffmpeg currently, and this
code is unused by default.
Clean up ifdefs so they make sense even if none or multiple are defined.
Also choose Linux as fallback case instead of failing, this
allows the code to compile e.g. on Android.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35971 b3059339-0415-0410-9bf9-f77b7e298cf2
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.
SHOUTcast bans "Mozilla" in the user-agent, Vimeo bans "Lavf" (part of
the libavformat normal user-agent). "MPlayer 1.1-..." seems to work
everywhere, and is close to the intented use (mpv is based on MPlayer,
after all).
Use codec names instead of FourCCs to identify codecs. Rewrite how
codecs are selected and initialized. Now each decoder exports a list
of decoders (and the codec it supports) via add_decoders(). The order
matters, and the first decoder for a given decoder is preferred over
the other decoders. E.g. all ad_mpg123 decoders are preferred over
ad_lavc, because it comes first in the mpcodecs_ad_drivers array.
Likewise, decoders within ad_lavc that are enumerated first by
libavcodec (using av_codec_next()) are preferred. (This is actually
critical to select h264 software decoding by default instead of vdpau.
libavcodec and ffmpeg/avconv use the same method to select decoders by
default, so we hope this is sane.)
The codec names follow libavcodec's codec names as defined by
AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders
have names different from the canonical codec name. The AVCodecDescriptor
API is relatively new, so we need a compatibility layer for older
libavcodec versions for codec names that are referenced internally,
and which are different from the decoder name. (Add a configure check
for that, because checking versions is getting way too messy.)
demux/codec_tags.c is generated from the former codecs.conf (minus
"special" decoders like vdpau, and excluding the mappings that are the
same as the mappings libavformat's exported RIFF tables). It contains
all the mappings from FourCCs to codec name. This is needed for
demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the
codec as determined by libavformat, while the other demuxers have to do
this on their own, using the mp_set_audio/video_codec_from_tag()
functions. Note that the sh_audio/video->format members don't uniquely
identify the codec anymore, and sh->codec takes over this role.
Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which
provide cover the functionality of the removed switched.
Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure
container/video combinations (e.g. the sample Film_200_zygo_pro.mov)
are played flipped. ffplay/avplay doesn't handle this properly either,
so we don't care and blame ffmeg/libav instead.
Playing vimeo links using quvi support didn't work, even though clive
could. clive is using quvi and curl to download videos from streaming
sites, so if clive works mpv should always work as well. It didn't, and
it turned out that it was due to the user agent. Change the default
from whatever Lavf sends to what clive and cclive use. This will
probably always work, as c(c)live are by the same author as libquvi,
and there's a high chance it has been tested with all the supported
sites.
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.
The "http:" protocol has been switched to use ffmpeg's HTTP
implementation some time ago. One problem with this was that many HTTP
specific options stopped working, because they were obviously
implemented for the internal HTTP implementation only.
Add the missing things. Note that many options will work for ffmpeg
only, as Libav's HTTP implementation is missing these. They will
silently be ignored on Libav.
Some options we can't fix:
--ipv4-only-proxy, --prefer-ipv4, --prefer-ipv6
As far as I can see, not even libavformat internals distinguish
between ipv4 and ipv6.
--user, --passwd
ffmpeg probably supports specifying these in the URL directly.
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
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.
If ffmpeg returns AVERROR_PROTOCOL_NOT_FOUND, print a warning that
ffmpeg should be compiled with network support. Note that stream_lavf.c
itself includes a whitelist of directly supported ffmpeg protocols, so
it can't happen that a completely unknown/madeup protocol triggers
this message. (Unless the ffmpeg:// or lavf:// prefixes are used.)
Add `mp_find_config_file` to search different known paths and use that in
ass_mp to look for the fontconfig configuration file.
Some incidental changes spawned by this feature where:
* Buffer allocation for the strings containing the paths is now performed
with talloc. All of the allocations are done on a NULL context, but it still
improves readability of the code.
* Move the OSX function for lookup inside of a bundle: this code path was
currently not used by the bundle generated with `make osxbundle`. The plan
is to use it again in a future commit to get a fontconfig config file.
Doesn't define AVPROBE_SCORE_RETRY for some reason. They use
AVPROBE_SCORE_MAX/4 directly internally. AV_DISPOSITION_ATTACHED_PIC
is not defined with the most recent Libav release.
AVIOContext.av_class exists in Libav, but is apparently disabled in
old releases. Disable it for now until people stop torturing me with
old crap releases.
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.)
stream ftp: Pass full buffer size to snprintf
Previously the buffer size was always passed as one less than
the underlying buffer's size. This is not using the underlying
buffer to its full potential according to the C99 standard. The
last byte of the buffers were never used.
No vulnerabilities should have been caused by this mistake because
the strings stored in the buffers were zero terminated at all
times. Neither were out-of-array writes nor reads possible.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35488 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: open_f: Mark parameter file_format unused
We have nothing to say about it, so we do not set *file_format.
No need for compilers to emit a warning about it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35489 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: Set type to STREAMTYPE_STREAM
Previously this was not set at all from within the stream_ftp module.
This caused the run-time warning message "Streams need a type!".
The actual behaviour should not be affected by this change.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35490 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: Use C99 designated initializers
Simplify the initialization of the stream private struct's defaults.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35491 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: Remove unneeded cast
At worst these kind of casts can hide real errors. As it is, it is
just not needed at all, thus remove it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35492 b3059339-0415-0410-9bf9-f77b7e298cf2
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.
The internal mplayer http implementation is terrible and old. Try to use
ffmpeg instead. Enable ffmpeg https as well (we don't have native
support for it and never will).
Enable the cache for ffmpeg streams. In theory, we want to enable the
cache for network streams only (or at least, not enable it for files),
but there doesn't seem to be any way to query this. ffmpeg has its own
read-cache, but apparently it doesn't get filled asynchronously (only
to the degree internal socket/kernel buffers do).
Should it turn out that the mplayer implementation is better than
ffmpeg's in some way (unlikely), this commit might be reverted until
ffmpeg is ready. So far, the ffmpeg implementation seems to work very
well though.
The original mplayer stream implementation is made available under
"mp_http://" and "mp_http_proxy://". This is for testing, until the
http implementation is completely removed. Note that this is unlikely
to happen soon: ffmpeg doesn't support Microsoft streaming, while
mplayer has some support. This code has dependencies on http.
Note: "http_proxy://" doesn't work anymore. Use "httpproxy://" to get
the ffmpeg implementation of it.
Using https requires enabling OpenSSL in ffmpeg by adding
the --enable-openssl switch to ffmpeg's configure.
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.
This change was split into 8 patches. Squash them together, as they
affect stream_ftp.c only.
stream ftp: readline: Fix off-by-one error
Even if max bytes are available read at most max - 1 bytes.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35427 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
stream/stream_ftp.c
stream ftp: readline: Always initialize output parameter buf
Only exception if passed parameter max is less than or equal
to zero. That cannot happen with the current code.
Additionally change readresp function to always copy the first
response line if the parameter rsp is non-NULL. This fixes some
error reporting that used uninitialized stack arrays.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35428 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: readline: Always try to read complete lines
If there is not enough space in the provided line buffer just
skip the remaining bytes until reaching EOL.
Usually we are only interested in the first 5 characters and
for everything else the (on-stack) response buffer should still
be big enough.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35429 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: Revise file descriptor usage
* Set unbound descriptor variables to -1
* Always test >= 0 to see if a variable refers to a valid descriptor
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35430 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: Only send QUIT command if connected
Do not attempt to send commands without control connections.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35431 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: Create buffers before opening control connection
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35432 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: Allocate command buffer on-heap
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35433 b3059339-0415-0410-9bf9-f77b7e298cf2
stream ftp: Increase command buffer size
Allow for more longish file names (be it because of length or more
lengthy characters).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35434 b3059339-0415-0410-9bf9-f77b7e298cf2
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.
Update endpos each time libavformat asks for it.
Fixes playback of still downloading files to not stop before we
really reached the end.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35107 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demux_lavf.c
Change STREAM_CTRL_GET_SIZE argument type from off_t to
uint64_t.
Also fix the incorrect type of the uint64_res variable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35360 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demux_lavf.c
libmpdemux/muxer_lavf.c
Note: also merges the "forgotten" cache support from r35107.
Comment out unused code
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35359 b3059339-0415-0410-9bf9-f77b7e298cf2
Removing mmsu-related code
MMSU was never supported by MPlayer, and the protocol has been
deprecated. Since the code is not in use at all, Removing it
should not break anything.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35420 b3059339-0415-0410-9bf9-f77b7e298cf2
Most of these are reimar fixing issues found by Coverity static
analyzer, and possibly some more cleanup commits independent from
this.
Since these commits are rather noisy, squash them all together.
Try to make code a bit clearer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35294 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
audio/out/ao_alsa.c
Check the correct variable for NULL.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35323 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove pointless unreachable code (the loop condition already checks
the 0xff case).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35325 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix typo that might have caused reading beyond the string end.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35326 b3059339-0415-0410-9bf9-f77b7e298cf2
Do not needlessly use "long" types.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35331 b3059339-0415-0410-9bf9-f77b7e298cf2
Use AV_RB32 to avoid sign extension issues and validate offset before using it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35332 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove nonsense casts.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35343 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix crash in case sh_audio allocation failed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35348 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix potential NULL dereference.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35351 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpcodecs/ad_ffmpeg.c
Note: Slightly modified.
Fix malloc failure check to check the correct variable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35353 b3059339-0415-0410-9bf9-f77b7e298cf2
Avoid code duplication and pointless casts.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35363 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
stream/tv.c
Error out if an invalid channel list name was specified
instead of continuing and reading outside array bounds
all over the place.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35364 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
stream/tv.c
Make array "static const".
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35365 b3059339-0415-0410-9bf9-f77b7e298cf2
Properly free resources even when encountering many
parse errors.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35367 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
parser-cfg.c
Avoid leaks in error handling.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35380 b3059339-0415-0410-9bf9-f77b7e298cf2
Do not do sign comparisons on "char" type which can be both signed or unsigned.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35381 b3059339-0415-0410-9bf9-f77b7e298cf2
Free cookies file data after parsing it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35382 b3059339-0415-0410-9bf9-f77b7e298cf2
http_set_field only makes a copy of the string, so we still need to
free it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35383 b3059339-0415-0410-9bf9-f77b7e298cf2
check4proxies does not modify input URL, so mark it const.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35390 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove proxy "support" from stream_rtp and stream_upd, trying
to use a http proxy for UDP connections makes no sense.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35394 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
stream/stream_rtp.c
stream/stream_udp.c
Add url_new_with_proxy function to reduce code duplication and memleaks.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35395 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
stream/pnm.c
stream/stream_live555.c
stream/stream_nemesi.c
stream/stream_rtsp.c
Fix off-by-one errors in file descriptor validity checks.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35402 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove pointless cast.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35403 b3059339-0415-0410-9bf9-f77b7e298cf2
Abort when opening the file failed instead of calling
"write" with an invalid descriptor.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35404 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove pointless local variable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35411 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
stream/http.c
Remove the code that attempted to read cookie files from well-known
browser locations. This code was written for ancient browsers, and only
knew about Mozilla and Netscape. While it's possible that these browsers
are still alive and still use the same config locations and cookie file
formats, the only Mozilla-based browser that still matters is Firefox.
Firefox uses a sqlite database for cookies, located in a slightly
different config path.
Just remove this code.
The function fixup_network_stream_cache() accesses stream->opts, which
is NULL in some cases when loading playlists. stream->opts is a pointer
to the global MPOpts struct. For simplicity, this parameter is left
NULL in some cases. Usually, this doesn't matter, because barely
anything in stream/ uses MPOpts anyway.
Hack-fix this for now by not accessing MPOpts and disabling the stream
cache in this case. Calling open_stream() with options==NULL now
basically means: do not use cache settings.
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.)
Tis drops the silly lib prefixes, and attempts to organize the tree in
a more logical way. Make the top-level directory less cluttered as
well.
Renames the following directories:
libaf -> audio/filter
libao2 -> audio/out
libvo -> video/out
libmpdemux -> demux
Split libmpcodecs:
vf* -> video/filter
vd*, dec_video.* -> video/decode
mp_image*, img_format*, ... -> video/
ad*, dec_audio.* -> audio/decode
libaf/format.* is moved to audio/ - this is similar to how mp_image.*
is located in video/.
Move most top-level .c/.h files to core. (talloc.c/.h is left on top-
level, because it's external.) Park some of the more annoying files
in compat/. Some of these are relicts from the time mplayer used
ffmpeg internals.
sub/ is not split, because it's too much of a mess (subtitle code is
mixed with OSD display and rendering).
Maybe the organization of core is not ideal: it mixes playback core
(like mplayer.c) and utility helpers (like bstr.c/h). Should the need
arise, the playback core will be moved somewhere else, while core
contains all helper and common code.
Found by clang analyzer. This called strlen(NULL), if the uri field
in the http_hdr wasn't set. It seems all callers of this function set
the field properly, so remove the bogus fallback to "/".
Use snprintf instead of sprintf.
No good reason beyond paranoia and Coverity complaining about it.
In a very theoretical, construed case the adds might overflow
or the environment might change in-between the getenv calls.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35307 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace sprintf with snprintf.
To my knowledge the only "real" issue this fixes
is that setting certain environment variables to
very long strings might have caused overflows.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35306 b3059339-0415-0410-9bf9-f77b7e298cf2
Use mp_asprintf in make_noauth_url and make_http_proxy_url.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32971 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: cboesch
Conflicts:
stream/url.c
Note: the mp_asprintf() function was introduced in r32970, and put
into its own files. We just put that directly into url.c, as we use
talloc_asprintf() in general, and mp_asprintf() is for url.c code only.
(Making url.c use talloc would probably result in a big mess.)
Make proxy and url parameter const in get_noauth_url and get_http_proxy_url.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32972 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: cboesch
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
Allow STREAM_CTRL_GET_NUM_TITLES with cache enabled.
This is missing in r34474.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35258 b3059339-0415-0410-9bf9-f77b7e298cf2
Avoid sleeping 0 ms, this can cause sleep to be not called at all.
This will then cause long hangs e.g. when sleeping on single-CPU/core computers.
Should fix bug #2084.
Patch suggested by Visenri [visenri yahoo es]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35119 b3059339-0415-0410-9bf9-f77b7e298cf2
Explicitly signal EOF when reaching the end of a file/pipe.
Fixes a 4 second delay due to stream_reconnect for e.g.
echo | mplayer -
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35112 b3059339-0415-0410-9bf9-f77b7e298cf2
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.
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.)
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.
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.
The <libavutil/avutil.h> stopped including <libavutil/common.h>
recursively in recent ffmpeg/libav git revisions. As a result, some
files no longer got needed definitions, causing a build failure.
Modify #include lines in various files to fix build with the latest
versions of ffmpeg/libav headers.
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.
stream_file always printed "File not found" if it could not open a
file, even though this could be due to other reasons such as
permission problems. Print strerror() information instead. This
changes the output for "mplayer /etc/shadow" from
File not found: '/etc/shadow'
to
Cannot open file '/etc/shadow': Permission denied
The commit 74df1d8e05 (and f752212c62) replaced the configure
endian check with byte order macros defined by standard headers. It
turns out that MinGW-w64 actually doesn't define these macros in the
sys/types.h system header. (I assumed it does, because a quick test
seemed to work. But that was because gcc -W -Wall doesn't warn against
undefined macros. You need -Wundef for that.) MinGW-w64 has a
sys/params.h header defining these macros, but sys/types.h doesn't
include it, so it's useless without special casing the mplayer code.
Add a hack top configure instead. Define the macros directly, and
assume MinGW-w64 only works on little endian machines.
The other changes are basically random typos and superficial oversights.
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.)
stream_pvr: Use sizeof() to get destination buffer size.
The code in lines 382/384 used the wrong constant.
Fixes bug #2066.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34895 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
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
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
This avoid some strange differences in behaviour between -cache and -nocache.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34461 b3059339-0415-0410-9bf9-f77b7e298cf2
cache2: fix seeking with e.g. flv files
This is a regression that was introduced in r34461.
Found and bisected by Anssi Hannula [anssi.hannula iki fi].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34575 b3059339-0415-0410-9bf9-f77b7e298cf2
cache2: print an error when streams behave in a way that the cache cannot handle
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34576 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Make cache process detect when the main process disappeared and
make it exit on its own in that case.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34371 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
'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
Mark two warnings that usually only indicate a performance issue as such.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33955 b3059339-0415-0410-9bf9-f77b7e298cf2
Another attempt to make message easier to understand.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33956 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Teletext requires special OSD support. Because I can't even test
teletext, I can't restore support for it. Since teletext can be
considered ancient and obscure, and since it doesn't make sense to keep
the remaining teletext code without being able to use it, I'm removing
it.
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.
Most of these demuxers and decoders are provided in better form by
libav, while the mplayer builtin ones are essentially unmaintained. The
only legimitate use case for not using the libav ones was working around
libav bugs or bugs related to the way mplayer uses libav. Instead of
trying to keep dead code alive, development effort should go into
improving libav or the mplayer libav glue code.
Note that the libav demuxer have been preferred over the mplayer builtin
ones for a while in mplayer2. There were some exceptions: playing DVDs
with dvdnav or playing network sources. (That's because some stream
modules and network.c requested explicit file formats, such as
DEMUXER_TYPE_MPEG_PS, which mapped to builtin demuxers.) With this
commit, they are switched to use libav. One caveat is that the requested
format is not passed to libavformat, instead we rely on the auto probing
to select the correct libav demuxer (see code in demux_open_stream()).
mplayer had three ways of enabling CPU specific assembler routines:
a) Enable them at compile time; crash if the CPU can't handle it.
b) Enable them at compile time, but let the configure script detect
your CPU. Your binary will only crash if you try to run it on a
different system that has less features than yours.
This was the default, I think.
c) Runtime detection.
The implementation of b) and c) suck. a) is not really feasible (it
sucks for users). Remove all code related to this, and use libav's CPU
detection instead. Now the configure script will always enable CPU
specific features, and disable them at runtime if libav reports them
not as available.
One implication is that now the compiler is always expected to handle
SSE (etc.) inline assembly at runtime, unless it's explicitly disabled.
Only checks for x86 CPU specific features are kept, the rest is either
unused or barely used.
Get rid of all the dump -mpcu, -march etc. flags. Trust the compiler
to select decent settings.
Get rid of support for the following operating systems:
- BSD/OS (some ancient BSD fork)
- QNX (don't care)
- BeOS (dead, Haiku support is still welcome)
- AIX (don't care)
- HP-UX (don't care)
- OS/2 (dead, actual support has been removed a while ago)
Remove the configure code for detecting the endianness. Instead, use
the standard header <endian.h>, which can be used if _GNU_SOURCE or
_BSD_SOURCE is defined. (Maybe these changes should have been in a
separate commit.)
Since this is a quite violent code removal orgy, and I'm testing only
on x86 32 bit Linux, expect regressions.
This enables playing URLs from libquvi supported streaming sites
directly, e.g. "mplayer http://www.youtube.com/watch?v=...."
Anything opened with mplayer is checked with libquvi. If it looks like
a URL of a supported streaming site, libquvi is used to extract the
media URL, which is then passed to the lower level mplayer code
instead of the HTML URL. Hopefully the libquvi URL checker works well
enough that it doesn't cause any problems with normal URLs, files, or
whatever else mplayer's stream layer accepts.
Add the --libquvi-format option. the option value is directly passed to
libquvi as requested format. The only values that seem to work for any
streaming site seem to be "best" (best quality) and "default" (lowest
quality). The mplayer option defaults to "best" (overriding libquvi's
default).
Outstanding issues:
- Does libquvi checking every opened file really not cause problems?
Should there be a runtime option to disable libquvi use?
(Probably not an issue.)
- Should we check/set the supported protocol? By default libquvi has
support for all protocols enabled. In the worst case, it might return
an URL using a protocol not supported by mplayer, even though it
could extract URLs with other protocols too.
(Probably not an issue.)
- Somehow export metadata (like media title) to the mplayer frontend?
Conflicts:
.gitignore
bstr.c
cfg-mplayer.h
defaultopts.c
libvo/video_out.c
The conflict in bstr.c is due to uau adding a bstr_getline function in
commit 2ba8b91a97. This function already existed in this branch.
While uau's function is obviously derived from mine, it's incompatible.
His function preserves line breaks, while mine strips them. Add a
bstr_strip_linebreaks function, fix all other uses of bstr_getline, and
pick uau's implementation.
In .gitignore, change vo_gl3_shaders.h to use an absolute path
additional to resolving the merge conflict.
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.
Conflicts:
bstr.c
bstr.h
libvo/cocoa_common.m
libvo/gl_common.c
libvo/video_out.c
mplayer.c
screenshot.c
sub/subassconvert.c
Merge of cocoa_common.m done by pigoz.
Picking my version of screenshot.c. The fix in commit aadf1002f8 will
be redone in a follow-up commit, as the original commit causes too many
conflicts with the work done locally in this branch, and other work in
progress.
The per-CD info will be printed on playback start, per-track info when
a track is played. (This is not a technical restriction, and just goes
along with the existing code.)
The following fields are not included in output, because these are
supposedly binary: CDTEXT_DISCID, CDTEXT_GENRE, CDTEXT_SIZE_INFO,
CDTEXT_TOC_INFO, CDTEXT_TOC_INFO2.
Fix cdda speed default value, range and use more robust condition.
Based on patch by Ingo Brückl [ib wupperonline de].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34458 b3059339-0415-0410-9bf9-f77b7e298cf2
Do not call paranoia_overlapset with 0, it actually causes cdparanoia to just hang.
Instead use it to set/unset PARANOIA_MODE_OVERLAP.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34459 b3059339-0415-0410-9bf9-f77b7e298cf2
Fail if trying to seek beyond the last chapter, not just if it is beyond the end of the disc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34460 b3059339-0415-0410-9bf9-f77b7e298cf2
cdda: set position to an actual EOF position when we set EOF.
This avoids some inconsistency like the stream indicating EOF but
a read still returning more data.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34462 b3059339-0415-0410-9bf9-f77b7e298cf2
Allow PARANOIA_MODE_FULL with skipping.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34467 b3059339-0415-0410-9bf9-f77b7e298cf2
Don't call paranoia_modeset() for PARANOIA_MODE_DISABLE.
cdparanoia destroys start sector information after such a call.
Since it is pointless without setting a mode anyway, don't do it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34468 b3059339-0415-0410-9bf9-f77b7e298cf2
Add comment to a condition that is just a hack around a cdparanoia bug.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34472 b3059339-0415-0410-9bf9-f77b7e298cf2
Add checks for errors in stream_cdda's get_track_by_sector().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34495 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix seeking beyond EOF in stream_cdda to work with cache.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34577 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
command.c
libao2/ao_alsa.c
libao2/ao_dsound.c
libao2/ao_pulse.c
libao2/audio_out.h
mixer.c
mixer.h
mplayer.c
Replace my mixer changes with uau's implementation, which is based on
my code.
Commit 30afc64532 ("stream_ffmpeg: switch to libavformat avio
API") somehow contained a nonsense line which broke the control()
function. Fix. Also add avformat_network_init() to central libav
initialization code to avoid warnings.
struct station_elem_s had a field "name[8]", but the rest of the code
used PVR_STATION_NAME_SIZE as field size in snprintf and some other
calls accessing the field. Change the field size to
PVR_STATION_NAME_SIZE so it matches the accesses.
The per-CD info will be printed on playback start, per-track info when
a track is played. (This is not a technical restriction, and just goes
along with the existing code.)
The following fields are not included in output, because these are
supposedly binary: CDTEXT_DISCID, CDTEXT_GENRE, CDTEXT_SIZE_INFO,
CDTEXT_TOC_INFO, CDTEXT_TOC_INFO2.
Fix cdda speed default value, range and use more robust condition.
Based on patch by Ingo Brückl [ib wupperonline de].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34458 b3059339-0415-0410-9bf9-f77b7e298cf2
Do not call paranoia_overlapset with 0, it actually causes cdparanoia to just hang.
Instead use it to set/unset PARANOIA_MODE_OVERLAP.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34459 b3059339-0415-0410-9bf9-f77b7e298cf2
Fail if trying to seek beyond the last chapter, not just if it is beyond the end of the disc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34460 b3059339-0415-0410-9bf9-f77b7e298cf2
cdda: set position to an actual EOF position when we set EOF.
This avoids some inconsistency like the stream indicating EOF but
a read still returning more data.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34462 b3059339-0415-0410-9bf9-f77b7e298cf2
Allow PARANOIA_MODE_FULL with skipping.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34467 b3059339-0415-0410-9bf9-f77b7e298cf2
Don't call paranoia_modeset() for PARANOIA_MODE_DISABLE.
cdparanoia destroys start sector information after such a call.
Since it is pointless without setting a mode anyway, don't do it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34468 b3059339-0415-0410-9bf9-f77b7e298cf2
Add comment to a condition that is just a hack around a cdparanoia bug.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34472 b3059339-0415-0410-9bf9-f77b7e298cf2
Add checks for errors in stream_cdda's get_track_by_sector().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34495 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix seeking beyond EOF in stream_cdda to work with cache.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34577 b3059339-0415-0410-9bf9-f77b7e298cf2
Windows uses a legacy codepage for char* / runtime functions accepting
char *. Using UTF-8 as the codepage with setlocale() is explicitly
forbidden.
Work this around by overriding the MSVCRT functions with wrapper
macros, that assume UTF-8 and use "proper" API calls like _wopen etc.
to deal with unicode filenames. All code that uses standard functions
that take or return filenames must now include osdep/io.h. stat()
can't be overridden, because MinGW-w64 itself defines "stat" as a
macro. Change code to use use mp_stat() instead.
This is not perfectly clean, but still somewhat sane, and much better
than littering the rest of the mplayer code with MinGW specific hacks.
It's also a bit fragile, but that's actually little different from the
previous situation. Also, MinGW is unlikely to ever include a nice way
of dealing with this.
