| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
See previous commit. It compiles, but 100% untested.
|
| |
|
|
| |
See previous commit.
|
| |
|
|
|
|
|
|
| |
The write functionality is almost unused (only encoding 2-pass mode uses
it to write the log file). Moreover, it almost makes no sense to use
this in a not local scenario. This change is just to prevent people from
duplicating the short write logic across all streams that happen to
support writing. Mostly untested; local log file writing still works.
|
| |
|
|
|
|
| |
The old rar code could do uncompressed rar, libarchive supports at least
some rar compression algorithms. There is no need to keep the old rar
code.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux analog TV support (via tv://) was excessively complex, and
whenever I attempted to use it (cameras or loopback devices), it didn't
work well, or would have required some major work to update it. It's
very much stuck in the analog past (my favorite are the frequency tables
in frequencies.c for analog TV channels which don't exist anymore).
Especially cameras and such work fine with libavdevice and better than
tv://, for example:
mpv av://v4l2:/dev/video0
(adding --profile=low-latency --untimed even makes it mostly realtime)
Adding a new input layer that targets such "modern" uses would be
acceptable, if anyone is interested in it. The old TV code is just too
focused on actual analog TV.
DVB is rather obscure, but has an active maintainer, so don't remove it.
However, the demux/stream ctrl layer must go, so remove controls for
channel switching. Most of these could be reimplemented by using the
normal method for option runtime changes.
|
| |
|
|
|
|
| |
This was possibly needed by libdvdread, and/or old CD drivers on some
system. It still works with on-filesystem DVD and BD test images, so
this can go.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes anything related to DVD/BD/CD that negatively affected the
core code. It includes trying to rewrite timestamps (since DVDs and
Blurays do not set packet stream timestamps to playback time, and can
even have resets mid-stream), export of chapters, stream languages,
export of title/track lists, and all that.
Only basic seeking is supported. It is very much possible that seeking
completely fails on some discs (on some parts of the timeline), because
timestamp rewriting was removed.
Note that I don't give a shit about optical media. If you want to watch
them, rip them. Keeping some bare support for DVD/BD is the most I'm
going to do to appease the type of lazy, obnoxious users who will care.
There are other players which are better at optical discs.
|
| |
|
|
| |
Isolate icky DVD garbage into a single file.
|
| |
|
|
|
|
|
|
|
|
|
| |
stream_dvd.c contained large amounts of ancient, unmaintained code,
which has been historically moved to libdvdnav. Basically, it's full of
low level parsing of DVD on-disc structures.
Kill it for good. Users can use the remaining dvdnav support (which
basically operates in non-menu mode). Users have reported that
libdvdread sometimes works better, but this is just libdvdnav's problem
and not ours.
|
| |
|
|
|
|
|
| |
s->priv->cancel will be freed when s is freed, so
freeing it explicitly is not required.
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
| |
It seems some DVB-T2 cards take longer to push out data.
|
| |
|
|
|
|
|
| |
While they accept the frequency field with MHz for DVB-S,
for DVB-C and DVB-T, it may be in Hz, kHz or MHz.
The official rule is to multiply whatever is in the channels.conf
by 1000 until a value > 1000000 is reached to get correct units for tuning.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Manual changes done:
* Merged the interface-changes under the already master'd changes.
* Moved the hwdec-related option changes to video/decode/vd_lavc.c.
|
| | |
| |
| |
| |
| |
| | |
Adapt documentation accordingly and
also, fix an off-by-one check in the code.
closes #6371
|
| | |
| |
| |
| |
| |
| | |
Seems to happen often with ytdl pseudo-DASH streams, so whatever. I
couldn't reproduce it and check what triggers it, I just remember seeing
the error message and found it annoying.
|
| | | |
|
| | |
| |
| |
| | |
it's more like an input speed rather than a cache speed, but who cares.
|
| |\ \
| |/
|/|
| |
| |
| | |
wm4-commits--merge-edition
This bumps libmpv version to 1.103
|
| | |
| |
| |
| |
| |
| | |
The demuxer cache is the only cache now. Might need another change to
combat seeking failures in mp4 etc. The only bad thing is the loss of
cache-speed, which was sort of nice to have.
|
| | |
| |
| |
| | |
Often requested, trivial.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Alway give each demuxer its own mp_cancel instance. This makes
management of the mp_cancel things much easier. Also, instead of having
add/remove functions for mp_cancel slaves, replace them with a simpler
to use set_parent function. Remove cancel_and_free_demuxer(), which had
mpctx as parameter only to check an assumption. With this commit,
demuxers have their own mp_cancel, so add demux_cancel_and_free() which
makes use of it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The properties/commands touched in this commit are all for obscure
special inputs (BD/DVD/DVB/TV), and they all block on the demuxer/stream
layer. For network streams, this blocking is very unwelcome. They will
affect playback and probably introduce pauses and frame drops. The
player can even freeze fully, and the logic that tries to make playback
abortable even if frozen complicates the player.
Since the mentioned accesses are not needed for network streams, but
they will block on network streams even though they're going to fail,
add a flag that coarsely enables/disables these accesses. Essentially it
establishes a whitelist of demuxers/streams which support them.
In theory you could to access BD/DVD images over network (or add such
support, I don't think it's a thing in mpv). In these cases these
controls still can block and could even "freeze" the player completely.
Writing to the "program" and "cache-size" properties still can block
even for network streams. Just don't use them if you don't want freezes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The intention is to avoid that the parent mp_cancel retains the
internally allocated wakeup pipe. File FDs are a relatively scarce
resource, so try to avoid having too many. This might matter for
subtitle files, for which it is relatively likely that they are loaded
in large quantities.
demux_lavf.c will close the underlying stream for most subtitle files,
and now it will free the wakeup pipe too. Actually, there are currently
only 1 or 2 mp_cancel objects per mpv core, but this could change if
every external subtitle track gets its own mp_cancel in later commits.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It seems a bit inappropriate to have dumped this into stream.c, even if
it's roughly speaking its main user. At least it made its way somewhat
unfortunately to other components not related to the stream or demuxer
layer at all.
I'm too greedy to give this weird helper its own file, so dump it into
thread_tools.c.
Probably a somewhat pointless change.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is some code that checks a FD for whether it is a regular file or
not. If it's not a regular file, it e.g. enables use of poll() to avoid
blocking forever.
But this was done only for FDs that were open()ed by us, not from stdin
special handling or fd://. Consequently, " | mpv -" could block the
player. Fix this by moving the code and running for it on all FDs.
Also, set p->regular_file even on mingw.
|
| | |
| |
| |
| | |
strncpy does not guarantee that the string will be NULL-terminated.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This happened with a .flac file inside an archive. It tried to seek
beyond the end of the archive entry in a format where seeking isn't
supported. stream_libarchive handles these situations by skipping data.
But when the end of the archive is reached, archive_read_data() returns
0. While libarchive didn't bother to fucking document this, they do say
it's supposed to work like read(), so I guess a return value of 0 really
means EOF. So change the "< 0" to "<= 0". Also add some error logging.
The same file actually worked without out of bounds reads when
extracted, so there still might be something very wrong.
|
| | |
| |
| |
| |
| |
| |
| | |
Functions `write` and `smbc_write` are given a diminishing buffer of
incorrect constant size. After partial writes, the code would do another
write of the full original length, failing to subtract the amount
already written.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thread-unsafe libsmbclient is likely to crash when used simultaneously
across threads. For example, by:
mpv "smb://...mkv" --sub-file "smb://...srt"
Work around this by locking all calls to this library under a single
global mutex. This is a temporary solution. When the libsmbclient bug
[1] is fixed, switch to the code from branch [2] which uses a new api to
create per-thread smb contexts. Fixes [3].
[1] https://bugzilla.samba.org/show_bug.cgi?id=11413
[2] https://github.com/orbisvicis/mpv/tree/smbclient_threaded_api
[3] https://github.com/mpv-player/mpv/issues/5936
|
| | | |
|
| | |
| |
| |
| | |
Often requested, trivial.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
There is some code that checks a FD for whether it is a regular file or
not. If it's not a regular file, it e.g. enables use of poll() to avoid
blocking forever.
But this was done only for FDs that were open()ed by us, not from stdin
special handling or fd://. Consequently, " | mpv -" could block the
player. Fix this by moving the code and running for it on all FDs.
Also, set p->regular_file even on mingw.
|
| |
|
|
|
| |
Seeking back can be excessively slow with most formats, so it'll benefit
from this.
|
| |
|
|
|
|
|
|
|
|
| |
When this happens, network calls are forcibly aborted (more or less),
but demuxers might keep going, as most of them do not check for forced
exits properly. This can possibly lead to broken packets being added.
Also do not attempt to read more packets in this situation.
Also do not print a stream open failed message if opening was aborted
anyway.
|
| |
|
|
| |
Requested in #634. Better late than never?
|
| |
|
|
| |
Fixes #5643.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Naturally, there's more than one fourcc that indicates an mjpeg
stream.
I have a particular ancient webcam here (Logitech QuickCam Messanger)
that only supports the single 'JPEG' format, but there are other
devices out there which support both 'JPEG' and 'MJPG' with no visible
differences, and others where the streams are slightly different.
Regardless of those details, it remains correct to treat 'JPEG'
the same as 'MJPG' from a stream consumption perspective.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Do this because retrying reading on higher levels (like the demuxer)
usually causes tons of problems. A hack like this is simpler and could
allow to remove some of the higher level retry behavior.
This works by trying to detect whether the file is appended. If we reach
EOF, check if the file size changed compared to the initial value. If it
did, it means the file was appended at least once, and we set the
p->appending flag. If that flag is set, we simply retry reading more
data every time we encounter EOF. The only way to do this is polling,
and we poll for at most 10 times, after waiting for 200ms every time.
|
| |
|
|
|
|
| |
The use of the FFmpeg hls protocol (as opposed to demuxer) is
"discouraged", and probably only causes additional potential security
problems at best, so drop it.
|
| | |
|
| |
|
|
| |
libbluray's way too verbose on default loglevel with non-breaking issues.
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit eliminates the following clang warning:
warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
Going by the clang commit message, this seems to be explicitly specified
as UB by the standard, and they added this warning because MSVC
apparently results in different behavior. Whatever, we can just avoid
the warning with some small changes.
|
| |
|
|
| |
Close #5325
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For quite some time, msg.c hasn't output partial log messages anymore,
and instead buffered them in memory. This means the MP_INFO() statement
here just kept appending the message to memory, instead of outputting
it.
Easy enough to fix by abusing the status line (which means the frontend
and this code will "fight" for the status line, but this code seems to
win usually, as the frontend doesn't update it so often).
Users should probably really switch to --cache-pause-initial.
Fixes #5360.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove our own hacky reconnection code, and use libavformat's feature for
that. It's disabled by default, and until recently it did not work too
well. This has been fixed in recent ffmpeg git master[1], so there's no reason
to keep our own code.
[1] FFmpeg/FFmpeg@8a108bdea06fac43af9f44b6d2538f357451167a
We set "reconnect_delay_max" to 7, which limits the maximum time it
waits. Since libavformat doubles the wait time on each reconnect attempt
(starting with 1), and stops trying to reconnect once the wait time is
over the reconnect_delay_max value, this allows for 4 reconnection
attempts which should add to 11 seconds maximum wait time. The default
is 120, which seems too high for normal playback use.
(The user can still override these parameters with --stream-lavf-o.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Don't drop the stream buffers, because the read call (that must have
been failing) might try to extend an existing read buffer in the first
place. Just move the messy seek logic to stream_lavf.c. (In theory,
stream_lavf should probably make libavformat connect at the correct
offset instead of using a seek to reconnect it again. This patch doesn't
fix it, but at least it's a good argument to have the messing with the
position not in the generic code.)
Also update the comment about avio not supporting reconnecting. It has
that feature now. Maybe we should use it, but only after it gets fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit 1199c1e3, we added checks to every libarchive API call to make
sure the archive was closed on ARCHIVE_FATAL - otherwise, libarchive
could endow us with free CVEs (such as it apparently happens when you
continue reading a rar archive that uses features not yet supported by
libarchive).
This broke the fallback for seeking in unseekable archive formats. Of
course libarchive won't tell us directly whether a format implementation
has seek support or not - and OF COURSE it returns ARCHIVE_FATAL if it
has no seek support. (The error string, which you can retrieve via API,
is actually more detailed, and also claims it's an "internal error". I
don't think so, libarchive.) Returning ARCHIVE_FATAL means we have to
assume free CVEs are ahead, and we have to close the archive. Which
breaks the fallback in a dumb way (we have no way of telling which of
those cases happened anyway).
Fix this by assuming that all seek errors are potentially due to lack of
seek support. If the seek call fails, reopen the archive, and set a flag
so the seek API is never tried again. (This means we can still skip
ahead for forward seeks, which is more efficient than skipping from the
start of the archive entry.)
Also fix an old typo in an error message.
|
| |
|
|
|
| |
This just put the cache into an endless loop. This can happen simply if
any seek call of the underlying stream returns an error.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reduce it from 75MB in both directions (forward/backwards) to 10MB each.
The stream cache is kind of becoming useless in favor of the demuxer
cache. Using both doesn't make much sense, because they will contain
duplicated data for no reason.
Still leave it at 10MB, which may help with mp4 a bit. libavformat's mp4
demuxer tends to seek too much, so we try to avoid triggering network
level seeks by having some caching in the stream layer.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I |
