Instead, parse manually. This is to get rid of the option API usages,
which seem unnecessary and shoehorned. (Just look at the URL pseudo
parsing and the dumb url_options map. They were pretty much artifacts
from refactoring old mplayer code.)
Don't access MPOpts directly, and always use the new m_config.h
functions for accessing them in a thread-safe way.
The goal is eventually removing the mpv_global.opts field, and the
demuxer/stream-layer specific hack that copies MPOpts to deal with
thread-safety issues.
This moves around a lot of options. For one, we often change the
physical storage location of options to make them more localized,
but these changes are not user-visible (or should not be). For
shared options on the other hand it's better to do messy direct
access, which is worrying as in that somehow renaming an option
or changing its type would break code reading them manually,
without causing a compilation error.
seek_fn is supposed to return the new file offset, or a negative error
code. Our code doesn't use the offset, and only wants to know if any
errors happened. The int cast is completely broken and might treat a
successful seek as failed depending on whether the sign bit will be set.
It's just wasted memory.
One corner case is when a file grows during playback, but this is rare
and usually happens on-disk only. The cache size was generally limited
before this change already, so no reason to care.
As an unrelated change, move the cache size info to the resize_cache()
function. There's really no reason not to do this, and it's slightly
more informative if the user changes the cache size at runtime.
If the normal stream cache init fails, and a file cache was initialized
before, we free the file cache as well. But since the file cache is
chained to the real stream, the real stream will also be freed. This has
to be prevented by clearing the pointer to the original stream in the
uncached_stream field.
This could in particular be triggered by using --cache-initial=1000 and
aborting playback during loading. (Without that option, stream cache
init failure is far less likely.)
Some client API users simply don't like such filenames. For their sake,
don't return them, but return a dummy filename instead. (Returning a
latin1-ized version would work too, but is slightly more work.)
Also remove the "\n" from the replacement dummy filename. This was
accidental.
The cache reader thread actually unlocks the mutex protecting the
underlying stream while reading from it. That's why other code goes out
of its way to run certain stream operations on the cache thread. Do the
same.
We could have this simpler by creating a mechanism that would "park" the
cache thread and make it wait for the lock (while we have it) in order
to gain exclusive access. This could be done in the future.
Eagerly execute seeks to the underlying stream in the cache seek
entrypoint itself. While asynchronous execution is a goal of the cache,
it doesn't matter too much for seeks. They always were executed within
the lock, so the reader was blocked anyway. It's not necessary to ensure
async. execution here either, because seeks are relatively rare, and the
demuxer can just stay blocked for a while.
Fixes: mpv http://samples.mplayerhq.hu/V-codecs/DIV5/ayaneshk-test.avi
For clang, it's enough to just put (void) around usages we are
intentionally ignoring the result of.
Since GCC does not seem to want to respect this decision, we are forced
to disable the warning globally.
This code evolved into an ifdef mess as support for cancellation on
Windows was added. Make the Windows-specific code completely separate.
It looks cleaner, and it also means that some of the posix code is not
uselessly enabled on Windows. The latter made msvcrt.dll output warnings
because it does not like -1 passed as FD to read/write. (The same would
be harmless on POSIX.)
Remove the attempted cleverness; keep it dumb.
This strictly calculates the average speed over an at least 1 second
window (longer if I/O blocks it).
Since this doesn't reset the speed anymore when reading stops by going
idle, the results might actually be more accurate now.
Tuning it in a way to be actually useful is too much effort.
As alternative, there's the "buffering" detection, which operates on a
much higher level. The only disadvantage is that it's harder to guess
for the user whether this is a network problem, or if e.g. libavformat
is probing too much data when opening a stream. Maybe the cache-speed
property is helpful here.
For now, do not remove the associated code, but just silence the
warning.
Fixes#3019.
I got a report that the build on a recent aarch64 Linux kernel failed.
DVB support was detected, but errored on compilation:
In file included from ../stream/stream_dvb.c:57:0:
../stream/dvbin.h:72:5: error: unknown type name 'fe_bandwidth_t'
fe_bandwidth_t bw;
Make the test stricter, which should take care of this. (I couldn't find
out what exactly triggered the failure, nor could I attempt to reproduce
it.)
The change in stream/dvbin.h is to make sure that this isn't caused by
incorrect header inclusion. It now includes the same files as the
configure test.
Don't assume EOF if we didn't try to read anything in the first place.
Fixes regressions in particular with low cache sizes, which triggered
the other code paths more often.
Instead of having a separate for each, which also requires separate
additional caching in the demuxer. (The demuxer adds an indirection,
since STREAM_CTRLs are not thread-safe.)
Since this includes the cache speed, this should fix#3003.
Should reflect I/O speed.
This could go into the terminal status line. But I'm not sure how to put
it there, since it already uses too much space, so it's not there yet.
Ever since a change in mplayer2 or so, relative seeks were translated to
absolute seeks before sending them to the demuxer in most cases. The
only exception in current mpv is DVD seeking.
Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR
is kept, because it's sometimes slightly useful for seeking in things
like transport streams. (And maybe mkv files without duration set?)
DVD seeking is terrible because DVD and libdvdnav are terrible, but
mostly because libdvdnav is terrible. libdvdnav does not expose seeking
with seek tables. (Although I know xbmc/kodi use an undocumented API
that is not declared in the headers by dladdr()ing it - I think the
function is dvdnav_jump_to_sector_by_time().) With the current mpv
policy if not giving a shit about DVD, just revert our half-working seek
hacks and always use dvdnav_time_search(). Relative seeking might get
stuck sometimes; in this case --hr-seek=always is recommended.
At least DTV_ENUM_DELSYS is not available in older versions.
It's hard to tell when this identifier was introduced, but it appears it
was probably API version 5.5.
Using the new API is a necessity for multiple-delivery-system
devices, since the old API does not offer a way to switch
the delivery system of the card.
This should in principle also be done for DVB-T / ATSC,
especially since most DVB-T devices also support DVB-C,
but I can not test such an implementation due to lack of hardware
(currently) so it seems better to leave the existing, tested code-path
in place for now.
No need use use all capital letters, and don't warn
if DVB-S2 is supported in addition since we handle that
in DVB-S case already.
Also, print the delivery system number for still unhandled
delivery systems to simplify debugging.
Saves one unnecessary additional ioctl per tuning
by just reusing existing information.
Should also fix the case of multiple supported delivery types
since we now rely on the initial query from the chosen
configuration after channel list parsing
instead of requerying the device.
Most common case would be DVB-C / DVB-T combination cards.
Cards with multiple delivery systems are only supported
starting from DVBv5 API (Kernel 2.6.38).
In this case, we loop over all delivery systems and
just treat them as different cards would be treated:
They all get their own TUNER-type, channel-list parsing etc.
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
On read, it returns the name of the current DVB program,
on write, it triggers a channel-switch to the program
if it is found in the channel list of the currently active card.
Compared to the dvb-channel property which already exists
and is a pair of integers (card + channel number) this has the limitation
of not switching the card, but is probably of much more common use.
The mutex is used in dvbin_open and dvbin_close only since these are
the only entry / exit points to the stream.
When opening, it is first checked (mutexed) whether the state already exists
and is in use, then a STREAM_ERROR is returned,
since there may be only one stream_dvb active at a time.
State-creation itself is also protected by mutex.
In dvbin_close, the usage-bit is set to false (mutexed) in case
of channel switch.
In case of stream-teardown, the state is destructed
(also protected by mutex).
The state-structure is kept in a static pointer and reused on
recreation of the stream.
To not leak the state and the FDs within upon mpv shutdown,
the state-structure is still destructed gracefully in dvbin_close(),
unless a channel switch has been initiated directly before.
This fixes channel-switching for DVB which was broken since a609877.
The state-struct now contains everything which can be kept after initial initialization.
This includes the channel-lists, configuration, device-fds and also information like
current channel and current card.
The dvb_priv_t is kept containing the mp-options, a pointer to the state and to the logger.
After this restructuring, the state-struct contains all information which can be persisted
across channel switching.
wm4
Ricardo Constantino
Aman Gupta
Ben Boeckel
stepshal
Niklas Haas
Oliver Freyermuth
Dmitrij D. Czarkoff