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.
Windows definitely supports Unix-style fd inheritance. This mostly
worked when launched from mpv.exe, though mpv should change the file
mode to O_BINARY. When launched from mpv.com, the wrapper must pass the
list of handles (stored in the undocumented lpReserved2 and cbReserved2
fields) to the mpv process.
This is only for specific Hauppage cards. According to the comments in
who is actively using this feature. Get it out of the way.
Anyone who still wants to use this should complain. Keeping this code
would not cause terribly much additional work, and it could be restored
again. (But not if the request comes months later.)
This commit introduces logic to read other volumes from the same source
as the primary archive. Both .rar formats as well as 7z are supported for now.
It also changes the libarchive callback structure to be per-volume
consistent with the libarchive intenal client data array constructed
with archive_read_append_callback_data.
Added open, close and switch callbacks. Only the latter is strictly
required to make sure that the streams always start at position 0, but
leaving all volumes open can eat a lot of memory for archives with many
parts.
Don't print the URL that is opened twice. stream.c and stream_lavf.c
each printed it once. Remove the logging from stream_lavf.c, and move
the log call to a more interesting point.
This causes weirdness with the "cache-size" property and option. Only
the read handler of the property included the backbuffer, while all
others did not. Make it consistent, and subtract the backbuffer size
from the cache size.
Fixes#2305.
As expected, probing with libarchive is a disaster. Both libavformat and
libarchive are too eager to misdetect file formats just because files
"might" be of a specific type. In this case, it's mp3 vs. tar. To be
fair, neither file format has an actual header. I'm not sure why we'd
need tar support, but since libarchive provides it, and idiots on the
internet apparently pack media files in tar sometimes (really, idiots),
keep it for now, and probe tar last.
libarchive uses a quite confusing ifdeffery mess for some of the types
used in callbacks. Currently, archive_read_set_seek_callback() causes a
warning at least on Windows due to mismatching return type. The header
file uses __LA_INT64_T as return type, so I think the user is intended
to use int64_t.
(The ssize_t return type for the read_cb seems correct, on the other
hand.)
Things like .gz etc., which have no real file header. A mixed bag,
because it e.g. tends to misdetect mp3 files as compressed files or
something (of course it has no mp3 support - I don't know as what it
detects them). But requested by someone (or maybe not, I'm not sure
how to interpret that).
This works similar to the existing .rar support, but uses libarchive.
libarchive supports a number of formats, including zip and (most of)
rar.
Unfortunately, seeking does not work too well. Most libarchive readers
do not support seeking, so it's emulated by skipping data until the
target position. On backwards seek, the file is reopened. This works
fine on a local machine (and if the file is not too large), but will
perform not so well over network connection.
This is disabled by default for now. One reason is that we try
libarchive on every file we open, before trying libavformat, and I'm not
sure if I trust libarchive that much yet. Another reason is that this
breaks multivolume rar support. While libarchive supports seeking in
rar, and (probably) supports multivolume archive, our support of
libarchive (probably) does not. I don't care about multivolume rar, but
vocal users do.
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
This was essentially missing from commit 0b52ac8a.
Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.
For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
Allow setting an arbitrary amount, instead of the fixed 50%.
This is nto striclty backwards compatible. The defaults don't change,
but the --cache/--cache-default options now set the readahead portion.
So in practice, users who configured this until now will see the
double amount of cache being used, _plus_ the 75MB default backbuffer
will be in use.
Currently, this is perfectly equivalent, because back_size is hardcoded
to buffer_size/2. But this fixes the logic for the case the back_size
can be configured freely.
DVD/BD menu support never worked right, and are a pain to maintain. In
particular, DVD menus never actually worked correctly, because
highlights were not rendered correctly. Fixing this requires major
effort, which I'm not interested to spend.
Most importantly, the requirement to switch streams without losing the
DVD/BD state caused major weirdness in the playback core. It was
implemented by somehow syncing the playback state to the DVD/BD
implementation (in stream_dvdnav.c etc.), and then reloading the demuxer
without destroying and recreating the stream. This caused a bunch of
special-cases which I'm looking forward to remove.
For now, don't just remove everything related to menu support and just
disable it. If someone volunteers, it can be restored (i.e. rewritten)
in a reasonable way. If nobody volunteers soon, it goes.
Normally, the cache keeps 50% of the buffer for seeking backwards. Until
now, the cache just used the full buffer size at the beginning of a
file, because the 50% normally reserved for the backbuffer are unused.
This caused a problem: when streaming from http, the player would first
read about 150MB (default cache size), then stop until 75MB of the cache
has been played. (Until the 75MB position, the cache is fully used, so
nothing new can be read. After that, part of the backbuffer starts
getting unreserved, and can be used for readahead.) This long read pause
can cause the server to terminate the connection. Reconnecting may be
possible, but if youtube-dl is used, the media URL may have become
invalid.
Fix this by limiting readahead to 50% even if unnecessary. The only
exception is when the whole file would fit in the cache. In this case,
it won't matter if we can't reconnect, because the cache covers
everything anyway, and hopefully the cache will stay valid.
Likely fixes#2000.
There is not much of a reason to have these wrappers around. Use POSIX
standard functions directly, and use a separate utility function to take
care of the timespec calculations. (Course POSIX for using this weird
format for time values.)
This code does not know whether the stream supports reconnecting until
STREAM_CTRL_RECONNECT is called. So the message should be printed after
it. To avoid that reconnects that succeed on the first try go unnoticed,
print a warning on success.
An approximate measure to make it exit possibly slightly earlier.
Relatively speaking, some time will pass between cancellation and
the cache actually being requested to exit, so it's good if the
cache returns EOF immediately.
The caller can check for cache interruption instead. There's no need to
define special return values and such. It would be rather hard to make
waiting for the condition and stream cancellation atomic too (and
pointless, since the underlying stream will also be "cancelled" and exit
early), so nothing about cancellation being a separate call will change.
This put some effort into distinguishing between two messages to print -
all worthless. Even more so, this kept printing the message, which
doesn't feel overly useful either. (The message will be printed
repeatedly anyway if network recovers for a while and then gets stuck
again.)
All in all, the demuxer cache triggering the buffering state does a
better job here. But don't remove it completely, since knowing that the
network did nothing for a relatively short time is still useful.
If a directory is encountered, replace it with its contents in the
internal playlist.
This is messed into demux_playlist.c, because why not. STREAMTYPE_DIR
could be avoided by unconditonally trying opendir() in demux_playlist.c,
but it seems nicer not to do weird things like calling it on real files.
This does not work on Windows, because msvcrt is retarded.
The libavformat rtmp protocol's "timeout" option has two problems:
1) Unlike all other protocols, it's in seconds and not microseconds
2) It enables "listen" mode, which breaks playback
Make the --network-timeout do nothing in the rtmp case.
Fixes#1704.
I think this is what I alwass missed ever since I found the MPlayer
cache options: a way to enable the cache on local files with the default
settings, whatever they are.
Seems appropriate, and will probably avoid performance surprises with
scary architectures which don't have trivial implementations for atomic
loads. (Consider that demux_mkv calls this very often now, and
libavformat demuxers and streams did this for a while now.)
This causes the cache to be enabled with --cache=auto. It was not done
previously because the small cache size 320k actually led to worse
performance. However, with the current default cache size of 25000kb,
caching notably improves performance.
If we're caching a stream with unknown size, and we reach EOF, then
consider the EOF position the file size. Typically makes sense when
reading from a pipe or a http connection that did not send a size.
It was possible to make the player play local files by putting rar://
links into remote playlists, and some other potentially unsafe things.
Redo the handling of it. Now the rar-redirector (the thing in
demux_playlist.c) sets disable_safety, which makes the player open any
playlist entries returned. This is fine, because it redirects to the
same file anyway (just with different selection/interpretation of the
contents). On the other hand, rar:// itself is now considered fully
unsafe, which means that it is ignored if found in normal playlists.
It is also used for initialization in channel-list setup.
Should fix compilation on FreeBSD, and is more correct
since it is used unconditionally.
Reverts 6445648 .
Refactors an older hack, which for some reason used a more complicated
way. This generates the playlist representing the contents of the rar
file in demux_playlist.c. The pseudo-demuxer could easily be separate
from the the playlist parsers (and in fact there's almost no shared
code), but I don't think this obscure feature deserves a separate file.
Sample files created with:
rar a -v20000k -m0 files.rar file1.mkv file1.mkv
This message will be printed relatively often once EOF is reached. In
some cases this is rather annoying, for example when playing HLS. (With
HLS, the stream is just a playlist file, while libavformat opens actual
media files without mpv's knowledge, so the cache is completely useless
and hits EOF instantly.)
That it retries reading is apparently a good thing: at least local files
can grow, and even after the player got the EOF, playback _could_ be
resumed by basically polling and detecting that there is more data. So
I'm not changing this behavior yet.
Most things stopped using this field for better support of growing
files. Go through the trouble to repalce the remaining uses, so it can
be removed.
Also move the "streaming" field; saves 4 bytes (wow!).
Fix return types and return values to make them more consistent. Some
reformatting and making code more concise.
In stream_reconnect(), avoid the additional mp_cancel_test() call by
moving the "connection lost" message below the mp_cancel_wait() call,
which effectively leads to the same behavior when the stream was already
canceled. (The goal is not to show the message in this case.)
Merge stream_seek_long() into stream_seek(). It was the only caller.
Always clear the eof flag on seeks.
Reduce access to stream internals in cache.c and stream_lavf.c.
Looks like a bunch of off-by-one errors.
The track number was mistakenly offset by 1 - this shifted all chapters
by one, and make the first chapter start on the second track (so the
"chapter" property returned -1 in the first track since it was before
the first chapter).
Also, the calculation of the sector destination was messed up. This
comes from commit 32d818f0, where I apparently attempted to calculate
the position to one byte before the section, but unfortunately math
doesn't work this way and it was nonsense. Just drop this idea; while it
may help with seeking (probably...), it also returns slightly different
times. The user shall use hr-seeks if accurate seeking is required.
Hopefully fixes#1560.
In my opinion, libavformat should be doing this. But a patch handling a
very safe case rejected, so I suppose we have to do it manually. (This
patch was only escaping spaces, which can never work because they break
the basic syntax of the HTTP protocol.)
This commit attempts to do 2 things:
- Try to guess whether libavformat will use the URL for http. This is
not always trivial, because some protocols will recursively pass part
of the user URL to http in some way.
- Try to fix invalid URLs. We fix only the simplest case: only
characters that are never valid are escaped. This excludes invalid
escape codes, which happen with freestanding '%' characters.
Fixes#1495.
libdvdnav is garbage. Seeking by time is incredibly inexact, which is in
part due to the fact that it does not use the DVD seek tables. Instead,
it assumes CBR for certain ranges within the DVD, which makes especially
small seeks unreliable.
I have no good fix for this, other than hacking libdvdnav (I'd rather
prefer to remove mpv DVD support completely than doing this). So here's
a shitty hack that tries to workaround these problems. A basic
observation is that seeking in VLC seems to work quite well; however it
seems to be based on seeking by blocks (unless there is a subtle "trick"
I didn't see in the source code). mpv usually seeks by timestamps, so
this is not an option for us. However, we can pretend we are doing this
in the DVD layer.
The previous commit added a way to pass through relative seeks. This
commit uses the relative seek. STREAM_CTRL_SEEK_TO_TIME is backwards
compatible (there's still dvdread and bluray), so most code is about
extracing the relative seek information and turning it into a block
seek.
(Another way would have been using SEEK_FACTOR stuff, but that would
probably make for a less reliable way to handle this situation.)
Additionally, if a hr-seek is done, add an offset by 10 seconds. As long
as the error done by libdvdnav is not worse, this should help with hr-
seeks - although it makes them much slower.
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.
It contains now also a boolean which tells whether this is an DVB-S2 channel (not initialized yet - tbd in next commit).
We could also pass through the type of the delivery system (would be more flexible), but the delivery-system-enum is only available with S2API, so this is more backwards-compatible.
If someone has DVB-T2 / DVB-C2 hardware and extends the code to deal with it, this should be changed.
Also allows demuxers to buffer, and we explicitly discard stale QPSK events.
Inspiration taken from the szap-s2 implementation.
S2API is only used if available and for DVB-S cards - it might also be useful to have that for DVB-T2 / DVB-C2 tuning later, but I do not have the HW / no DVB-T2 broadcasting station nearby to test functionality.
This should do no functional changes, only usage of the different API. The S2API is more extensible and a requirement for all the HD-deliveries (e.g. DVB-S2) and since 2.6.28 is the successor of the old API.
Tuning to DVB-S2 channels actually already "works" like this if the delivery is hardcoded in - for a fully working implementation, the channels.conf.sat would need an additional field indicating the delivery type (VDR-type channels.conf have that).
This commit also:
- Cleans up some debug output.
- Moves an unneeded usleep(100000) (only needed for diseqc switching for SAT) into the DVB-S-only part of the implementation.
Define a new macro "DVB_USE_S2API" to be used to switch to S2API if available,
also document what is the main difference in the new S2API.
StreamID-handling is only supported since API 5.2, and some macros
were renamed or only added later with 5.8 (somewhere around kernel 3.6),
so some define-fixups are needed to support these intermediate
kernel header versions.
Apparently this is what users would expect.
Going the way of least resistance (in terms of messing with this old,
rarely used code), sorting them by some kind of addition timestamp
(called priority in the patch) is the easiest.
Fixes#1390.
stream_edl merely makes demux_edl act "special", which checks for the
stream type explicitly and then does something with its URL. If a cache
is added before the stream, it'll try to use the cache's URL (i.e. an
empty string), and will then obviously fail to parse the URL. While this
is slightly stupid, just disabling the entirely useless cache is the
most effective solution.
Fixes#1378.
As suggested in issue #1251. I think the main point is that it acts as
a hack to return to the DVD menu when jumping past the last chapter,
because it will reach title-EOF, instead of explicitly jumping to the
next file (which usually exits the player).
This basically reverts commit 8b7418d, except it doesn't include an
off-by-1 error (apparently).
Closes#1251.
This was requested.
It seems libdvdread can't get the duration for titlesets other than the
currently opened title. The data structures contain dangling pointers
for these, and MPlayer works this around by opening every title
separately for the purpose of dumping the title list.
Apparently, we treat different tracks as titles, so returning the number
of titles (which is user-visible as "disc-titles" property) is
completely misguided.
Apparently, libdvdnav always reports a last chapter that points to the
exact end of the title. This is useless for us.
Again, same possible caveats as with the previous commit.
This way, chapter 0 will always point to the start of the title.
At least this is the intention; it's likely that DVDs as well as
libdvdnav do random things that lead to random results.
This was completely breaking any low-level caching. Change it so that at
least demuxer caching will work.
Do this by using the metadata cache mechanism to funnel through the menu
commands.
For some incomprehensible reason, I had to reorder the events (which
affects their delivery priority), or they would be ignored. Probably
some crap about the event state being cleared before it could be
delivered. I don't give a shit.
All this code sucks. It would probably be better to let discnav.c access
the menu event "queue" directly, and to synchronize access with a mutex,
instead of going through all the caching layers, making things
complicated and slow.
...because everything is terrible.
strerror() is not documented as having to be thread-safe by POSIX and
C11. (Which is pretty much bullshit, because both mandate threads and
some form of thread-local storage - so there's no excuse why
implementation couldn't implement this in a thread-safe way. Especially
with C11 this is ridiculous, because there is no way to use threads and
convert error numbers to strings at the same time!)
Since we heavily use threads now, we should avoid unsafe functions like
strerror().
strerror_r() is in POSIX, but GNU/glibc deliberately fucks it up and
gives the function different semantics than the POSIX one. It's a bit of
work to convince this piece of shit to expose the POSIX standard
function, and not the messed up GNU one.
strerror_l() is also in POSIX, but only since the 2008 standard, and
thus is not widespread.
The solution is using avlibc (libavutil, by its official name), which
handles the unportable details for us, mostly. We avoid some pain.
In addition to the messed-up expression, the endianness was also
inverted. The code reads big endian by default.
It "worked" by coincidence, but for little endian, codepoints outside of
latin1 were broken.
The broken expression was found by Coverity.
Thanks to STREAM_CTRL_HAS_AVSEEK, we actually know whether CTRL_AVSEEK
is implemented at all, and we can avoid a blocking wait on the cache if
demux_lavf sends CTRL_AVSEEK even if it won't wait. I'm hoping this
can't currently happen, but why hope if we can explicitly prevent it.
It'll make us more robust against future changes in libavformat.
