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.
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.
This complains within dvb_strtok_r() that savePtr is uninitialized.
There doesn't seem to be any code path where this can happen though, so
it's probably a false positive. Silence it anyway.
This causes more constant reading from the DVB device,
and seems not to hurt the stream-controls.
As the device cache seems to fill up when not
reading from it for several seconds, reading
into the cache fixes desync-issues after
the initial analyzeduration of the demuxer.
Was already possible before by injecting the magic PID
8192 into channels.conf, the flag makes this much more
useable and we also have it documented.
Useful not only for debugging, but also for incomplete
channels.conf (mplayer format...), multi-channel
recording, or channels which do dynamic PID switchng.
full-transponder is also useful for channels which switch PIDs on-the-fly.
ffmpeg can handle this, but it needs the full stream with all PIDs.
There is the STD which contains service-names
(ffmpeg can understand it),
and the EIT which contains the EPG
(ffmpeg does not parse it, but e.g. VLC does).
As we now have more PIDs in general, increase the maximum
number of demuxers we can open. ffmpeg has an internal
limit of 64 PIDs, we are still far from that.
If VDR-channel-config is used, we know the service_id.
Using that, PMT can be extracted from PAT (code for that
inspired by szap-s2 again).
For this, we need to demux PAT with a special filter-setup,
and once PMT was found it can be added to the PID-list.
PMT is only resolved the first time one tunes to a channel,
then stored in the channel-list in memory.
With PMT available, ffmpeg can safely decode the teletext-pids.
I also added a comment explaining the potentially occuring structures for future reference.
For tokenization, a custom strtok_r implementation is used,
inspired by strtok_r as implemented in musl and ffmpeg,
hopefully slightly more readable (av_strtok_r is not available in libav,
and strtok_r is not available everywhere).
Move PID-string parsing into a separate function, reduces code-duplication.
Drop TPID-parsing again since teletext-stream seems not really correctly identified (ffmpeg guessed mp3 in my test...).
Parsing now done using strtok + sscanf instead of sscanfs with fixed numbers of expected fields -
gives more correct checking of PID-overflow, will allow VDR-style PID-field parsing.
The PID-parsing is not really nicely done and also does not yet handle the special VDR-style syntax.
A later commit will move the parsing to a separate function handling that which also checks that the maximum PID-count is not exceeded.
In mplayer-style channels-config, we had a LNB-field used for that.
In old VDR times, the location-field was also containing DISEQc information,
now it does that only indirectly (location => LNB => vdr knows from lnb-config).
We only accept it as this if the field is fully numeric.
Now also "stream ID" (for DVB-S2) and "inversion" are understood.
The parameter-string can also provide information on FEC, rolloff etc. For DVB-S, "auto" which mpv uses by default should be fine, I can also confirm it works. For non-DVB-S cards, it might be useful to also parse this information in case of a vdr-channel list.
As I have no such hardware and thus would have to do it blindly, I added a FIXME.
Mostly complete vdr-channels.conf format documentation is at http://www.vdr-wiki.de/wiki/index.php/Channels.conf (german only).
Still incomplete. Initialize is_dvb_s2 boolean in channel-struct.
We first check whether the channels.conf-line at hand is sscanf'able with a vdr-style pattern. If yes, we assume it is a vdr-channel-config (we check whether sscanf consumed the full line).
The vdr-style config also contains a parameter-string which contains information about polarization + delivery type (e.g. DVB-S2).
With this change, S2-tuning works with a VDR-channel list.
Missing (later commits):
- vdr-parameter-string also contains other information, e.g. invert-flag, needs to be parsed.
- Diseqc-lnb-number is not present in VDR-config (I believe it is handled via the location-parameter + lnb-config there). For backwards compatibility, the location-parameter can be the lnb-number - we should test whether it is an int and assume this in this case.
- VID, AID and TID-lists are extremely ugly in their syntax for VDR. At the moment, only the first number is parsed (and TID fully ignored), needs to be fixed.
Got lost some time ago. Although I'm not sure if it actually does
anything on MPlayer (it exists there, but might broken, not sure).
Fixes#988 (untested).
Something like "char *s = ...; isdigit(s[0]);" triggers undefined
behavior, because char can be signed, and thus s[0] can be a negative
value. The is*() functions require unsigned char _or_ EOF. EOF is a
special value outside of unsigned char range, thus the argument to the
is*() functions can't be a char.
This undefined behavior can actually trigger crashes if the
implementation of these functions e.g. uses lookup tables, which are
then indexed with out-of-range values.
Replace all <ctype.h> uses with our own custom mp_is*() functions added
with misc/ctype.h. As a bonus, these functions are locale-independent.
(Although currently, we _require_ C locale for other reasons.)
Search $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS for config files.
This also negates the need to have separate user and global variants of
mp_find_config_file()
Closes#864, #109.
Signed-off-by: wm4 <wm4@nowhere>
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
Convert all these commands to properties. (Except tv_last_channel, not
sure what to do with this.) Also, internally, don't access stream
details directly, but dispatch commands with stream ctrls.
Many of the new properties are a bit strange, because they're write-
only. Also remove some OSD output these commands produced, because I
couldn't be bothered to port these.
In general, this makes everything much cleaner, and will also make it
easier to e.g. move the demuxer to its own thread.
Don't bother updating input.conf, but changes.rst documents how old
commands map to the new ones.
Mostly untested, due to lack of hardware.
For some reason, we support writeable streams. (Only encoding uses that,
and the use of it looks messy enough that I want to replace it with FILE
or avio today.)
It's a chaos: most streams do not actually check the mode parameter like
they should. Simplify it, and let streams signal availability of write
mode by setting a flag in the stream info struct.
I hate tabs.
This replaces all tabs in all source files with spaces. The only
exception is old-makefile. The replacement was made by running the
GNU coreutils "expand" command on every file. Since the replacement was
automatic, it's possible that some formatting was destroyed (but perhaps
only if it was assuming that the end of a tab does not correspond to
aligning the end to multiples of 8 spaces).
There's a single mp_msg() in path.c, but all path lookup functions seem
to depend on it, so we get a rat-tail of stuff we have to change. This
is probably a good thing though, because we can have the path lookup
functions also access options, so we could allow overriding the default
config path, or ignore the MPV_HOME environment variable, and such
things.
Also take the chance to consistently add talloc_ctx parameters to the
path lookup functions.
Also, this change causes a big mess on configfiles.c. It's the same
issue: everything suddenly needs a (different) context argument. Make it
less wild by providing a mp_load_auto_profiles() function, which
isolates most of it to configfiles.c.
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
This is needed so that new processes (created with fork+exec) don't
inherit open files, which can be important for a number of reasons.
Since O_CLOEXEC is relatively new (POSIX.1-2008, before that Linux
specific), we #define it to 0 in io.h to prevent compilation errors on
older/crappy systems. At least this is the plan.
input.c creates a pipe. For that, add a mp_set_cloexec() function (which
is based on Weston's code in vo_wayland.c, but more correct). We could
use pipe2() instead, but that is Linux specific. Technically, we have a
race condition, but it won't matter.
The priv struct is now allocated by talloc in stream.c. It doesn't need
to be manually freed, and using free() instead of talloc_free() probably
crashes.
Now that talloc has been removed, the license can be switched back to
GPLv2+. Actually, there never was a GPLv2+ licensed MPlayer (fork or
not) until now, but removal of some GPLv2-only code makes this possible
now. Rewrite the Copyright file to explain the reasons for the licenses
MPlayer and forks use. The old Copyright file didn't contain anything
interesting anymore, and all information it contained is available at
other places in the source tree.
The reason for the license change itself is that it should improve
interoperability with differently licensed code in general.
This essentially reverts commit 1752808.
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.
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.
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.
