| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Like the previous commit, this removes names only, not actual support
for these formats.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, use the native-endian alias, and switch the wayland format
depending on the target platform's endian.
This drops support for swapped-endian formats, but I think that is ok.
Not only are the affected formats rather ancient and backwards, but
using swapped formats probably does not make any sense for performance
either.
Untested.
|
|
|
|
|
|
|
|
|
| |
These formats are still supported; you just can't reference them via a
defined constants directly. They are now handled via the generic
passthrough.
(If you want to use such a format, you either have to add the entry
back, or use AV_PIX_FMT_* directly.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a rather radical change: instead of maintaining a whitelist of
FFmpeg formats we support, we automatically support all formats.
In general, a format which doesn't have an explicit IMGFMT_* name will
be converted to a known format through libswscale, or will be handled
by code which can treat pixel formats in a generic way using the pixel
format description, like vo_opengl.
AV_PIX_FMT_UYYVYY411 is a special-case. It's packed YUV with chroma
subsampling by 4 in both directions. Its component order is documented
as "Cb Y0 Y1 Cr Y2 Y3", meaning there's one UV sample for 4 Y samples.
This means each pixel uses 1.5 bytes (4 pixels have 1 UV sample, so
4 bytes + 2 bytes). FFmpeg can actually handle this format with its
generic mechanism in an extremely awkward way, but it doesn't work for
us. Blacklist it, and hope no similar formats will be added in the
future.
Currently, the AV_PIX_FMT_*s allowed are limited to a numeric value of
500. More is not allowed, and there are some fixed size arrays that need
to contain any possible format (look for IMGFMT_END dependencies).
We could have this simpler by replacing IMGFMT_* with AV_PIX_FMT_*
through the whole codebase. But for now, this is better, because we
can compensate for formats missing in Libav or older FFmpeg versions,
like AV_PIX_FMT_RGB0 and others.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FFmpeg has only a AV_PIX_FMT_FLAG_BE flag, not a LE one, which causes
problems for us: we want to have the LE flag too, so code can actually
detect whether a format is non-native endian. Basically, we want to
reconstruct the LE/BE suffix all AV_PIX_FMT_*s have.
Doing this is hard due to the (messed up) way AVPixFmtDescriptor works.
The worst is AV_PIX_FMT_RGB444: this group of formats describe an
endian-independent access (since no component actually spans 2 bytes,
you only need byte accesses with a fixed offset), so we have to go
through some pain.
|
|
|
|
| |
Makes no sense.
|
| |
|
|
|
|
|
|
|
| |
Use the "default" selection for the ff-index, not the "no" selection.
Broken by commit f0f83ff.
Fixes #1243.
|
|
|
|
|
|
| |
Pretty useless and only good for testing.
Does not include any form of GLES support.
|
|
|
|
|
| |
XInternAtom() has a 64 entry hash table to avoid network accesses. Rely
on this cache, instead of caching these manually.
|
|
|
|
| |
....
|
|
|
|
|
|
|
|
|
| |
This influences the demuxer readahead display. If a stream has reached
EOF, we want to ignore it for the purpose of this calculation.
Note that if a stream contains no packets, it still should cause the
value 0s to be displayed (unless it's EOF), because that's just the
actual situation.
|
|
|
|
|
|
|
|
| |
This was relying on the fact that timestamps will always be numerically
larger than MP_NOPTS_VALUE, but the trick didn't actually work for
MP_PTS_MIN. Be a bit more sincere, and don't rely on this anymore. This
fixes the comparison, and avoids the readahead amount displaying as
"???" in some situations (since one of the values was NOPTS).
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this case, we didn't find any new packets for this stream, even
though we've read ahead as much as possible. (If reading ahead in this
case, the "Too many packets in the demuxer packet queues" error is
normally printed.)
If we do consider this an underrun, handle_pause_on_low_cache() will
pause and show the "buffering" state, which is not useful.
Could also happen on very bad interleaving.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mechanism was introduced for Opus, and allows correct skipping of
"preroll" data, as well as discarding trailing audio if the file's
length isn't a multiple of the audio frame size.
Not sure how to handle seeking. I don't understand the purpose of the
SeekPreRoll element.
This was tested with correctness_trimming_nobeeps.opus, remuxed to mka
with mkvmerge v7.2.0. It seems to be correct, although the reported file
duration is incorrect (maybe a mkvmerge issue).
|
|
|
|
|
| |
Apparently we actually need this. At least the following commit would
break without this.
|
|
|
|
|
|
| |
More or less requested by #1237.
Should be simple to extend this to other backends.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a generic mechanism to the VO to relay "extra" events from VO to
player. Use it to notify the core of window resizes, which in turn will
be used to mark all affected properties ("window-scale" in this case) as
changed.
(I refrained from hacking this as internal command into input_ctx, or to
poll the state change, etc. - but in the end, maybe it would be best to
actually pass the client API context directly to the places where events
can happen.)
|
|
|
|
|
|
| |
Add a comment about this to avoid confusing users of this function. The
parameter is essentially unused, but exists so that we don't need to
add extra APIs if the need for it arises.
|
|
|
|
| |
A client API user has no other way to know the version.
|
|
|
|
| |
This was stupid.
|
|
|
|
| |
Has been annoying me since forever.
|
|
|
|
|
|
|
|
|
| |
Instead of defining a separate data structure in the core.
For some odd reason, demux_chapter exported the chapter time in
nano-seconds. Change that to the usual timestamps (rename the field
to make any code relying on this to fail compilation), and also remove
the unused chapter end time.
|
|
|
|
|
|
|
|
| |
Note that you can't pass .cue or .edl files to it, at least not yet.
Requested in context of allowing to specify custom chapters. For that
to work well, we probably need to add some sort of chapter metadata
pseudo-demuxer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the --playlist option is no longer recommended.
A while ago, mpv rewrote all playlist parsers and added some minimal
security mechanisms (like not allowing local file access or unsafe
protocols in remote playlists). Further, mpv can load playlists by
passing them as normal file arguments, without the option.
Now, --playlist is needed only in these situations:
1) loading plaintext files
2) disabling additional security mechanisms
(e.g. using a remote playlist to play local files)
|
|
|
|
| |
Fixes #1236.
|
|
|
|
|
|
| |
NSDisableScreenUpdates came to hunt me in the end and when mpv was paused, it
did wait for a frame that never came (because of interaction with the live
resizing code)!
|
|
|
|
| |
Use TOOLS/osxbundle.py instead. It's just better and less hacky.
|
|
|
|
|
| |
The receiving part was implemented, but since no messages are enabled
by default, it couldn't be used.
|
| |
|
|
|
|
|
| |
Calling mpv_resume() too often is considered an API usage violation,
and will trigger an internal assertion somewhere.
|
| |
|
|
|
|
| |
Use TOOLS/osxbundle.py instead. It's just better and less hacky.
|
|
|
|
|
| |
Rename the variable, update comments, and update the documentation of
the property which returns its value.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was shown only if decoder-framedropping was enabled, and only if at
least 50 frames were dropped by it. Since drop_frame_cnt used to mean
"number of late frames", this code made sense, but this is not the case
anymore: drop_frame_cnt can be even 0, all while video gets hopelessly
behind audio.
One problem with this is that short desync spikes (which usually can
probably dealt with) will also cause this message to be shown. If it
gets triggered too often, the code will need to be adjusted.
|
|
|
|
|
|
|
|
| |
This shouldn't use the host's 'ar' when building static libs. It only
worked until now because Linux 'ar' is usually built with PE support.
Couldn't confirm whether it works, because this dumb crap is just
broken when cross-compiling to mingw.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Trades one strange thing against another, but seems slightly less
strange.
|
|
|
|
|
|
|
| |
This change is probably too simplistic, but most things appear to work,
so I don't care about that now.
Fixes #1232.
|
|
|
|
|
|
|
|
|
| |
For example, if --force-window is used, and video is switched off during
playback, then you need to redecide the rendering method to get subs
displayed correctly.
Do this by moving the state setup code into a function, and call it on
every frame.
|
|
|
|
|
| |
The <pthread_np.h> header expects that <pthread.h> was already included.
We were including <pthread.h> only later via our threads.h.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently this can "sometimes" return an error. In my opinion, this
should never return an error: neither the semantics of the function,
nor the ALSA documentation or ALSA sample code seem to indicate that
a failure is to be expected. I'm not perfectly sure about this though
(I blame ALSA being a weird, big, underdocumented API).
Since it causes problems for some users, and since there is really no
reason why we should abort on such an error, turn it into a warning.
Fixes #1231.
|
|
|
|
|
| |
Hopefully less confusing, and hopefully doesn't exceed the terminal
width in any situation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you played e.g. an audio-only file and something bad happened that
interrupted playback, the exit message could say "No files played".
This was awkward, so show a different message in this case.
Also overhaul how the exit status is reported in order to make this
easier. This includes things such as not reporting a playback error
when loading playlists (playlists contain no video or audio, which
was considered an error).
Not sure if I'm happy with this, but for now it seems like a slight
improvement.
|
|
|
|
| |
This sounds much more intuitive, while "empty" was a bit of a WTF.
|
|
|
|
|
| |
There was chance that some data was left in various local buffers after
time-seeks. Probably doesn't actually matter.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically, this will mark the demuxer as seekable with rtmp* and mmsh
protocols. These protocols have network-level time seeking, and whether
you can seek on the byte level does not matter.
Until now, seeking was typically only enabled because of the cache, and
a (nonsensical) warning was shown accordingly.
It still could happen that the server doesn't actually support thse
requests (or simply rejects them), so this is somewhat imperfect.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure if this could be done in libavformat instead. Probably not,
because libavformat doesn't seem to have any mechanism for trying one
protocol and reverting (or redirecting) to another one if needed.
This commit is sort of a hack too, because it redirects the URL by
pretending the http:// link is a playlist containing the mmsh:// link.
The list of mime types is borrowed from MPlayer (which has completely
different code to handle this).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently this is needed for correct 3D mode subtitles. In general,
it seems you need to duplicate the whole "GUI", so it's done for all
OSD elements.
This doesn't handle the "duplication" of the mouse pointer. Instead,
the mouse can be used for the top/left field only. Also, it's possible
that we should "compress" the OSD in the direction it's duplicated, but
I don't know about that.
Fixes #1124, at least partially.
|
|
|
|
|
| |
If there are several input.confs in the set of valid config paths, load
them all.
|
|
|
|
| |
Probably doesn't matter much.
|
|
|
|
| |
No reason why only demux_mkv.c should do this.
|
|
|
|
| |
It was implemented only for the case the index exists (pretty useless).
|
|
|
|
|
| |
This gives us approximate fallback playback percentage position if the
duration is unknown.
|
|
|
|
|
|
| |
On OSD/terminal, just don't display the duration if unavailable.
Make the "length" property unavailable if duration is unavailable.
|
|
|
|
|
|
| |
This is probably what libmpv users want; and it also improves error
reporting (or we'd have to add a way to communicate such mid-playback
failures as events).
|
|
|
|
|
|
|
|
| |
This was probably done incorrectly in cases when the currently selected
channel had no data. I'm not sure if this codepath is functional at all,
though. Maybe not.
Untested due to lack of DVB hardware.
|
|
|
|
| |
Give somewhat more information on playback failure.
|
|
|
|
|
|
|
|
|
| |
Using magic integer values was an attempt to keep the API less verbose.
But it was probably not a good idea.
Reason 1 (restart) is not made explicit, because it is not used anymore
starting with the previous commit. For ABI compatibility, the value is
left as a hole in the enum.
|
|
|
|
|
|
|
| |
Use the codepath that is normally used for DVD/BD title switching and
DVB channel switching. Removes some extra artifacts from the client API:
now MPV_EVENT_END_FILE will never be called on reloads (and neither is
MPV_EVENT_START_FILE).
|
|
|
|
|
|
|
|
|
|
| |
This was originally done for DVD/BD/DVB, where the start position could
be something different from 0, and seeking back to 0 would mess it up
completely.
Since we're not quite sure that these streams are unseekable, we can
simplify this somewhat, and also make sure we also start at 0 for normal
files. Helps a little bit with the following edition reloading commit.
|
|
|
|
|
|
|
|
|
| |
The only reason for mpv_wait_event() not being thread-safe is that it
returns a pointer to a mpv_event struct member in the mpv_handle
context, which in turn is done for ABI-safety (user doesn't allocate or
manage the struct), and to avoid the need additional memory management.
Some users were interpreting this incorrectly.
|
| |
|
|