| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36677 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |
|
|
|
|
|
|
| |
This is probably ok. Probing could hit this case very often, since it'll
mean running this function on potentially binary data, but on the other
hand, probing usually uses a memory stream (to limit the amount of data
read), and memory streams have s->log silenced (details see
open_memory_stream()).
|
| |
|
|
| |
Text files should never contain these.
|
| |
|
|
|
|
|
|
|
| |
This simplifies the implementation and should make it more robust. For
example, we return an error if a line is longer than the provided buffer
(instead of splitting the line).
The code is much shorter, because now finding the new line and reading
characters is done in one go.
|
| |
|
|
|
|
|
| |
Doesn't affect the generated code, but avoids confusion
in both humans and newer Coverity versions.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36623 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |
|
|
|
|
|
|
|
| |
The struct we need to copy is actually a cdrom_msf0, not cdrom_msf.
Even though the kernel for no good reason reads it in as a
cdrom_msf struct, but only uses the part shared with cdrom_msf0 -
this is probably a kernel bug.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36622 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |
|
|
|
|
| |
This was accidentally committed.
<rcombs> `mp_sleep_us(100000);` <-- are you drunk?
|
| |
|
|
| |
Output only 1 message every 5 seconds at most.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Starting a network stream could stall by executing uncacheable stream
control requests (STREAM_CTRL_GET_LANG and STREAM_CTRL_GET_DVD_INFO).
Being uncacheable means the player has to wait until the cache is done
reading the current block of data. These requests can't be cached
because they're too complicated, so the only way to avoid them is
special casing the DVD and Bluray streams (which are the only things
which need these requests), and not doing them in other cases.
(This is kind of inelegant, but so is the rest of the DVD/BD code.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes two things:
1. Dropping files on the VO window will auto-load subtitles (since most
drag & drop code prefixes the filenames with 'file://', and the
subtitle auto-load code considers 'file://' non-local)
2. Fix behavior of the %x screenshot filename template (similar problem)
One could force all that code to special-case 'file://' URLs, but just
replacing the filename on playback start is simpler.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
| |
Fallout from the mp_msg conversions.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Streams like CDDA have special requirements in what quantities data can
be read: you can only read a sector at once, not more and not less. The
stream_peek() function didn't respect that and set less (used internal
buffer size of 2048 bytes, instead of CD sector size of 2352 bytes), so
no data was read and EOF was accidentally set, making playback with
cdda:// fail.
This is a regression since commit 9a723f, but that commit merely exposed
the issue (the redundant seek would clear the EOF flag).
|
| |
|
|
|
| |
Yep, smb_username/password were unused since forever, even in MPlayer.
Removal untested. (Does anyone even use smb://?)
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
| |
Avoid global state (reload cookie file every time), actually free
loaded cookies, use mp_get_user_path() for cookie file.
|
| | |
|
| |
|
|
| |
Same for companion functions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
We also drop some slave mode stuff from stream_vcd.
|
| |
|
|
|
|
|
| |
The TV code pretends to be part of stream/, but it's actually demuxer
code too. The audio_in code is shared between the TV code and
stream_radio.c, so stream_radio.c needs a small hack until stream.c is
converted.
|
| |
|
|
|
|
|
|
| |
Always pass around mp_log contexts in the option parser code. This of
course affects all users of this API as well.
In stream.c, pass a mp_null_log, because we can't do it properly yet.
This will be fixed later.
|
| | |
|
| |
|
|
|
|
| |
In my opinion, config.h inclusions should be kept to a minimum. MPlayer
code really liked including config.h everywhere, though, even in often
used header files. Try to reduce this.
|
| | |
|
| |
|
|
|
| |
This was a gettext-style macro to mark strings that should be
translated.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The tmsg stuff was for the internal gettext() based translation system,
which nobody ever attempted to use and thus was removed. mp_gtext() and
set_osd_tmsg() were also for this.
mp_dbg was once enabled in debug mode only, but since we have log level
for enabling debug messages, it seems utterly useless.
|
| |
|
|
| |
This way we probably do the right thing, and avoid all the menu shit.
|
| |
|
|
|
|
| |
Before this, they were displayed forever. Since some dvd screens seem
not to allow escaping from the still frame using the menu, this could
get you stuck forever.
|
| |
|
|
|
|
|
|
|
| |
On dvdnav, caching kind of works but not really. (Not our fault, at
least not fully. It's due to libdvdnav being slightly misdesigned; see
previous commit for some explanations.)
The TV code is implemented in the demuxer, and the stream implementation
is just a wrapper, so caching makes no sense here.
|
| |
|
|
|
|
| |
No idea why this was disabled. It was in the original MPlayer code,
which doesn't make much sense to me, because using the MPlayer stream
cache seems 100% broken due to design issues.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
EOF is a special case. Normally, the reader will block until the cache
thread has new data. Obviously we don't want to do this on EOF, because
we'd potentially block forever. On the other hand, EOF will put the
cache thread into a waiting state, so if EOF recovers, this will happen
at a "later" point. This is bad if there is some kind of external event
that ends the EOF condition. In this case, a steram_read() call would
still return EOF. Make it so that the reader waits at least for one
iteration of the cache trying to rad a new block.
Also adjust some debug messages to not print file positions in hex.
|
| |
|
|
|
|
| |
There was already something similar in the code that did the actual
seek, but I think seeking to the same position could still trigger an
actual seek due to weid interaction with the buffer.
|
| |
|
|
|
| |
And use it in demux_lavf.c. It looks like otherwise, some data might be
left over, depending on how the hell av_seek_frame() behaves.
|
| |
|
|
|
| |
Not sure if this actually can happen. It doesn't remove the problem that
mpv sometimes shows highlights on nav screens which have no highlight.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This readds a more or less completely new dvdnav implementation, though
it's based on the code from before commit 41fbcee. Note that this is
rather basic, and might be broken or not quite usable in many cases.
Most importantly, navigation highlights are not correctly implemented.
This would require changes in the FFmpeg dvdsub decoder (to apply a
different internal CLUT), so supporting it is not really possible right
now. And in fact, I don't think I ever want to support it, because it's
a very small gain for a lot of work. Instead, mpv will display fake
highlights, which are an approximate bounding box around the real
highlights.
Some things like mouse input or switching audio/subtitles stream using
the dvdnav VM are not supported.
Might be quite fragile on transitions: if dvdnav initiates a transition,
and doesn't give us enough mpeg data to initialize video playback, the
player will just quit.
This is added only because some users seem to want it. I don't intend to
make mpv a good DVD player, so the very basic minimum will have to do.
How about you just convert your DVD to proper video files?
|
| |
|
|
| |
Good clang catches programming errors. `open(2)` takes `int` not `mode_t`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Uncompressed rar archives can be transparently opened, but the filename
the player doesn't have the direct filename (but something starting
with rar://... instead). This will lead to external subtitles not
being loaded.
This doesn't handle multi-volume rar files, but in that cases just use
the --autosub-match=fuzzy option.
Fixes #397 on github.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
pthreads should be available anywhere. Even if not, for environment
without threads a pthread wrapper could be provided that can't actually
start threads, thus disabling features that require threads.
Make pthreads mandatory in order to simplify build dependencies and to
reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe
we will use pthreads more in the future, and then it'd become a real
bother.)
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This used to be needed to access the generic stream header from the
specific headers, which in turn was needed because the decoders had
access only to the specific headers. This is not the case anymore, so
this can finally be removed again.
Also move the "format" field from the specific headers to sh_stream.
|
reimar
wm4
Andre D
Miro Hrončok
Stefano Pigozzi