| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces new stream protocols: bdnav(and others).
bdnav stream shares lots of codes with original bluray stream, so
it's not separated in different source file.
Major difference from bluray is that bdnav does not support longest
title because there is no way to query that information.
bdnav://menu and bdnav://first correspond to top menu title and
first play title respectively, though they often point same title.
Also, binary position based seeking has been removed, because it
didn't have no point.
|
|
|
|
|
|
|
|
| |
This was accidentally broken in commit b72ba3f7. I somehow made the
wild assumption that replaygain adjusted the volume relative to 0%
instead of 100%.
The detach suboption was similarly broken.
|
|
|
|
|
|
|
|
| |
This was actually supposed to be removed with pull reuqest #671, but
I accidentally re-added it with a rebasing mistake.
This probably also coincidentally fixes compilation with older
libbluray (issue #672).
|
|
|
|
|
|
|
|
| |
Use bd_get_playlist_info() instead of bd_get_title_info(). The
previous implementation couldn't query current playlist and this
made it impossible to call bd_get_playlist_info() which is more
desirable than bd_get_title_info() because, for Blu-rays, playlist
is the unit of playback not title. This commit fixes that.
|
|
|
|
|
|
|
|
| |
The cost of calling bd_get_title_info() is quite expensive and
requires lots of CPU usage. Using BD_EVENT_PLAYLIST and
BD_EVENT_TITLE, it's possible to cache BLURAY_TITLE_INFO object for
current title and BD_EVENT_ANGLE handler caches current angle. In
my test case, with this commit, CPU usage can be saved about 15-20%.
|
|
|
|
|
|
| |
This commit brings libbluray's event queue into stream_bluray.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
| |
demux_mf.c explicitly checks for the stream type to check whether images
are opened via pattern (mf://..., i.e. stream_mf.c) or directly. Of
course the stream type is not set to STREAMTYPE_MF if the stream is
wrapped through the cache, so it tried to open the pattern directly as
file, which failed.
Fix this by disabling caching for mf://. The cache doesn't make sense
here anyway, because each file is opened and closed every frame (perhaps
to avoid memory bloat).
|
|
|
|
|
|
|
|
|
|
| |
It's possible that MPContext has a chapter list, but the demuxer
doesn't. In this case, accesing the chapter-metadata property would
lead to invalid accesses.
(This fixes the out of bound access, but in theory, the returned data
can still be incorrect, since MPContext chapters don't need to map
directly to demuxer chapters.)
|
| |
|
|
|
|
|
|
| |
This cd_info_t struct was practically unused. The only thing it did was
storing the track name of the form "Track %d" in a very roundabout way.
Remove it. (It made more sense when there was still CDDB support.)
|
|
|
|
|
|
|
|
|
|
| |
Don't use an integer division to get the time, since that would round on
second boundaries. Also round up the time by sector size. Seeking rounds
down due to alignment constraints, but if we round up the time, we can
make it land on the exact destination sector.
This fixes that the track change code printed the previous track when
seeking by chapter.
|
|
|
|
|
|
| |
This was usually handled at the end of the switch statement, so if
something returns from the function before that, the event has to be
freed explicitly.
|
|
|
|
|
|
|
| |
Previous implementation updated video resolution when highlight
event was given. However, this may not work if highlight event
is given before video size is queried.
This commit adds checking routine into rendering function, too.
|
|
|
|
|
|
|
|
|
|
|
| |
dvdnav.c did not handle event in regular sequence. Usually this
does not make any trouble except around MP_NAV_EVENT_RESET_ALL.
Those events should be handled in regular sequence. If they're
mixed, it can make wrong result.
For instance, MP_NAV_EVENT_HIGHLIGHT right after
MP_NAV_EVENT_RESET_ALL should not be ignored but it might be
because MP_NAV_EVENT_RESET_ALL makes the demuxer reloaded and osd
hidden.
|
|
|
|
|
| |
Since subsizes were never updated, the bitmap buffer was always
reallocated whenever mp_nav_get_highlight() called.
|
|
|
|
|
|
| |
And consistently use MP_NOPTS_VALUE as error value for the users of this
function. This is better than using -1, especially because negative
values can be valid timestamps.
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of comparing the current chapter every time, set the playback
end timestamp to the chapter end. Likewise, don't execute an extra seek
for the start chapter.
Maybe we could also use the timeline facility to restrict playback to
the given chapter range, but this would be strange when using
--chapter=N to start playback at a given chapter. Then you couldn't seek
back, which is possibly not what the user wants.
|
| |
|
|
|
|
|
|
| |
For some reason, it mattered whether mpctx->chapters was NULL or not,
even if mpctx->num_chapters was 0. Remove this separation; it serves no
purpose.
|
|
|
|
|
|
| |
Instead, always use the mpctx->chapters array. Before this commit, this
array was used only for ordered chapters and such, but now it's always
populated if there are chapters.
|
|
|
|
|
|
|
|
| |
Stream-level chapters (like DVD etc.) did potentially not have
timestamps for each chapter, so STREAM_CTRL_SEEK_TO_CHAPTER and
STREAM_CTRL_GET_CURRENT_CHAPTER were needed to navigate chapters. We've
switched everything to use timestamps and that seems to work, so we can
simplify the code and remove this old mechanism.
|
|
|
|
|
|
|
|
|
| |
Report the time for each chapter (tracks are treated as chapters). This
allows us to get rid of the "old" chapter mechanism, and also behaves
better with the frontend.
This makes assumptions about the audio formats, but that format is
hardcoded anyway in the rawaudio demuxer defaults (and always was).
|
|
|
|
|
| |
The changes in vo_opengl.c are merely for adding the icc options to the
set of options than can be changed with the vo_cmdline command.
|
|
|
|
|
| |
It's obvious but, since STREAM_CTRL_GET_TIME_LENGTH is called
frequently, the amount of leaked memory here is quite big.
|
|
|
|
|
|
|
|
| |
Libav 10 was released, so we can enable testing the stable Libav version
again.
FFmpeg 2.2 was also released, but since we still support 2.1.4, we stick
with the older version. This is better for testing.
|
|
|
|
| |
It's better if argc/argv always mean the same thing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were some bad interactions with the OSC.
For one, dragging the OSC bar, and then moving the mouse outside of the
OSC (while mouse button still held) would suddenly initiate window
dragging. This was because win_drag_button1_down was not reset when
sending a normal mouse event, which means the window dragging code can
become active even after we've basically decided that the preceding
click didn't initiate window dragging.
Second, dragging the window and clicking on the OSC bar after that did
nothing. This was because no mouse button up event was sent to the core,
even though a mouse down event was sent. So make sure the key state is
erased with MP_INPUT_RELEASE_ALL.
|
| |
|
| |
|
|
|
|
| |
There's no reason to. This is basically a cosmetic change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't check whether the WM supports _NET_WM_MOVERESIZE_MOVE, but
if it doesn't, nothing bad happens. There might be a race condition
when pressing a button, and then moving the mouse and releasing the
button at the same time; then the WM might get the message to initiate
moving the window after the mouse button has been released, in which
case the result will probably be annoying. This could possibly be fixed
by sending _NET_WM_MOVERESIZE_CANCEL on button release, but on the
other hand, we probably won't receive a button release event in this
situation, so ignore this problem.
The dragging is initiated only when moving the mouse pointer after a
click in order to reduce annoying behavior when the user is e.g.
doubleclicking.
Closes #608.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The title for stream_bluray DID start from 1 and I misunderstood
that it started from 0 because mpv accepted bd://0 as a proper
argument. In fact, 0 title was an alias for the longest title but
it was not handled as a special value. This commit fixes these
behavious. 'disc-title' property for Blu-ray now starts from 0 and
the default title can be specified by 'longest' title just like
stream_dvdnav: bd://longest. Of course, 'longest' can be omitted.
|
|
|
|
|
|
|
|
| |
This commit makes 'disc-title' property writable using
STREAM_CTRL_SET_CURRENT_TITLE. This commit also contains
implementation of STREAM_CTRL_SET_CURRENT_TITLE for stream_bluray.
Currently, 'disc-title' is writable only for stream_dvdnav and
stream_bluray and stream_dvd is not supported.
|
|
|
|
| |
Done two commits ago.
|
| |
|
|
|
|
|
|
|
|
| |
This commit makes 'disc-title' properties for DVDs start from 0.
There was an inconsistency around 'disc-title' property between
DVDs (from 1) and Blu-rays (from 0). This fixes #648.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
This check incorrectly passed on Cygwin. While Cygwin has the
statfs.f_type field, it contains the volume's FileSystemAttributes,
which aren't useful for detecting network mounts.
|
|
|
|
|
|
|
|
|
| |
"enable-osc" will make the OSC appear at any time (although it'll
quickly disappear again if the mouse is not inside the OSC). "disable-
osc" will make it disappear permanently.
Also, if the OSC is visible, force remap the DEL key to make the OSC
disappear.
|
|
|
|
| |
More consistent naming.
|
|
|
|
|
|
|
|
| |
Change script_message to broadcast the message to all clients. Add a new
script_message_to command, which does what the old script_message
command did.
This is intended as simplification, although it might lead to chaos too.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VAAPI has some ambiguous image formats, like VA_FOURCC_I420,
VA_FOURCC_IYUV, VA_FOURCC_YV12 (the latter exactly the same as the first
two, just with swapped planes). There is potentially a problem when one
specific VAAPI format was picked, and converting it to a mpv format and
back to a VAAPI FourCC would result in a numerically different format
(even if it's actually the same). Then it could e.g. happen that
functions like va_surface_upload() reallocate the underlying VAImage,
which would be inefficient. Change the code so that this can't happen.
(Probably not a problem in practice with the current VAAPI usage.)
|
|
|
|
| |
Merge va_surface_priv into va_surface.
|
|
|
|
|
|
| |
It's not really needed to be public. Other code can just use mp_image.
The only disadvantage is that the other code needs to call an accessor
to get the VASurfaceID.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although I at first thought it would be better to have a separate
implementation for hwaccels because the difference to software images
are too large, it turns out you can actually save some code with it.
Note that the old implementation had a small memory management bug. This
got painted over in commit 269c1e1, but is hereby solved properly.
Also note that I couldn't test vf_vavpp.c (due to lack of hardware), and
I hope I didn't accidentally break it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The plan is to get rid of the custom VAAPI and possibly VDPAU surface
allocators.
Add custom surface allocation, because hwaccel surfaces are allocated
completely differently from software surfaces.
Add optional LRU allocation, which is (probably) helpful for hwaccel,
but (probably) less optimal for software surfaces.
mp_image_pool_get_no_alloc() is specifically for VAAPI, which can't
allocate new decoder surfaces after decoder init.
|
|
|
|
|
|
| |
They were used by ancient libavcodec versions. This also removes the
need to distinguish vdpau image formats at all (since there is only
one), and some code can be simplified.
|
| |
|
|
|
|
|
|
| |
Image formats used to be FourCCs, so unsigned int was better. But now
it's annoying and the only difference is that unsigned int is more to
type than int.
|
|
|
|
| |
We no more support ancient libavutil versions.
|
|
|
|
|
| |
Needed in theory. I don't know if there are even any real-world files
which change the profile mid-stream.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of doing it on every seek (libavcodec calls get_format on every
seek), reinitialize the decoder only if the video resolution changes.
Note that this may be relatively naive, since we e.g. (or: in
particular) don't check for profile changes. But it's not worse than the
state before the get_format change, and at least it paints over the
current vaapi breakage (issue #646).
|
|
|
|
|
|
| |
There's already a more detailed "AUTHORS" section.
Closes #647.
|
| |
|
|
|
|
|
| |
Seems kind of wrong that this wasn't done, although it didn't have any
bad consequences.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Set refcounted_frames, because in some versions of libavcodec mixing the
new AVFrame API and non-refcounted decoding could cause memory
corruption. Likewise, it's probably still required to unref a frame
before calling the decoder.
|
|
|
|
| |
See previous commit.
|
|
|
|
| |
See previous commit.
|
|
|
|
| |
See previous commit.
|
|
|
|
| |
See previous commit.
|
|
|
|
|
|
|
| |
This follows the (only slowly progressing) plan to replace all internal
video filters with libavfilter.
All what's left in vf_gradfun.c is the weird wrapper around vf_lavfi.c.
|
|
|
|
|
| |
This is all not needed anymore. In particular, remove all configure
switches except --enable-libavfilter.
|
|
|
|
|
| |
av_copy_packet() was FFmpeg specific, av_packet_ref() is now available
on all supported libavcodec releases.
|