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.
