The audio subsystem now wakes up the playback thread explicitly, and we
don't need this anymore.
It still could cause dropouts and such if there are bugs in the recently
introduced audio changes, so this is a thing to watch out for.
And slightly adjust the semantics of MPV_EVENT_PAUSE/MPV_EVENT_UNPAUSE.
The real pause state can now be queried with the "core-idle" property,
the user pause state with the "pause" property, whether the player is
paused due to cache with "paused-for-cache", and the keep open event can
be guessed with the "eof-reached" property.
This property is set to "yes" if playback was paused due to --keep-open.
The change notification might not always be perfect; maybe that should
be improved.
Currently this is (probably) equivalent to "paused-for-cache", but the
latter is a bit special, while this new property is a bit more general.
One case where they might actually be different is dvdnav menus, but I
haven't checked.
Also add property change notifications for these two properties.
This is a read-only property that uses VFCTRL_GET_METADATA
to retrieve mp_tags metadata from a filter specified by label
Signed-off-by: wm4 <wm4@nowhere>
These playlist parsers are all what's left from the old mplayer playlist
parsing code. All of it is old code that does little error checking; the
type of C string parsing code that gives you nightmare.
Some playlist parsers have been rewritten and are located in
demux_playlist.c. The removed formats were not reimplemented. ASX and
SMIL use XML, and since we don't want to depend on a full blown XML
parser, this is not so easy. Possibly these formats could be supported
by writing a very primitive XML-like lexer, which would lead to success
with most real world files, but I haven't attempted that. As for NSC, I
couldn't find any URL that worked with MPlayer, and in general this
formats seems to be more than dead.
Move playlist_parse_file() to playlist.c. It's pretty small now, and
basically just opens a stream and a demuxer. No use keeping
playlist_parser.c just for this.
Basically a cheap hack to fix that the --msgmodule prefix will cause an
unwanted linebreak by making the line too long.
Suggested by Hamuko in github issue #710.
Fixes#710.
This is needed if you want to reimplement the status line in lua
I could only test drop-frame-count because I didn't find an easy way to
trigger paused-for-cache and total-avsync-change
Signed-off-by: wm4 <wm4@nowhere>
Otherwise, the client API user could not know why playback was stopped.
Regarding the fact that 0 is used both for normal EOF and EOF on error:
this is because mplayer traditionally did not distinguish these, and in
general it's hard to tell the real reason. (There are various weird
corner cases which make it hard.)
Although this is something really basic, Lua's standard library doesn't
provide anything like this. Probably because there are too many ways to
do it right or wrong.
This code tries to be really careful when dealing with mixed
arrays/maps, e.g. when a table has integer keys starting from 1, making
it look like an array, but then also has other keys.
The only tricky part is keeping the cache contents, which is made simple
by allocating the new cache while still keeping the old cache around,
and then copying the old data.
To explain the "Don't use this when playing DVD or Bluray." comment: the
cache also associates timestamps to blocks of bytes, but throws away the
timestamps on seek. Thus you will experience strange behavior after
resizing the cache until the old cached region is exhausted.
Some of these property implementations already send notifications on
their own, but most don't. This takes care of them.
Of course this still doesn't handle all propertry changes - this is
impossible without special-casing each property that can change on its
own.
This turned out ridiculously complex. I think it will have to be
simplified some day. Main reason for the complexity are:
- filtering properties by forcing clients to observe individual
properties explicitly
(to avoid spamming clients with changes they don't want)
- optional retrieval of property value with the notification
(the basic idea was that this is more user friendly)
- allowing to the client to specify a format in which the value
should be retrieved
(because if a property changes its type, the client API couldn't
convert it properly, and compatibility would break)
I don't know yet which of these are important, and everything could
change. In particular, the interface and semantics should be adjusted
to reduce the implementation complexity.
While I consider the API complete, there could (and probably will) be
bugs left. Also while the implementation is complete, it's inefficient.
The complexity of the property matching is O(a*b*c) with a clients,
b observed properties, and c properties changing at once. I threw away
an earlier implementation using bitmasks, because it was too unwieldy.
Remove the use of mp_ring and use a simple array and a bunch of
variables instead. This is way less awkwad.
The change in reserve_reply fixes incorrect tracking of free events.
Now they can be paused and resumed.
Since pausing and disabling the timer is essentially the same underlying
operation, we also just provide one method for it.
mp.cancel_timer probably still works, but I'm considering this
deprecated, and it's removed from the manpage. (We didn't have a release
with this function yet, so no formal deprecation.)
Change the type of the property from a string list (alternating
key/value entries) to a map. Using the client API, this will return
MPV_FORMAT_NODE_MAP, while Lua mp.get_property_native returns a
dictionary-like table.
We've just checked whether a sub-path started with "name/", but that
changes behavior whether the property name has a trailing '/' or not.
Using a helper function to split of path components avoids this problem.
This played the file at a wrong sample rate if the rate was out of
certain bounds.
A comment says this was for the sake of libaf/af_resample.c. This
resampler has been long removed. Our current resampler
(libav/swresample) checks supported sample rates on reconfiguration, and
will error out if a sample rate is not supported. And I think that is
the correct behavior.
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.
Reduce most dependencies on struct mp_csp_details, which was a bad first
attempt at dealing with colorspace stuff. Instead, consistently use
mp_image_params.
Code which retrieves colorspace matrices from csputils.c still uses this
type, though.
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 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.
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.
