Commit Graph

22 Commits

Author SHA1 Message Date
Guido Cella 81dea9031d command: add playlist-next-playlist and playlist-prev-playlist
playlist-prev-playlist goes to the beginning of the previous playlist
because this seems more useful and symmetrical to
playlist-next-playlist. It does not go to the beginning when the current
playlist-path starts with the previous playlist-path, e.g. with mpv
--loop-playlist foo/, which expands to foo/{1..9}.zip, the current
playlist path foo/1.zip beings with the playlist-path foo/ of {2..9}.zip
and thus playlist-prev-playlist goes to 9.zip rather than to 2.zip.

Closes #12495.
2023-10-09 15:09:35 +00:00
Dudemanguy 034f75dacd loadfile: fix an old wonky playlist heuristic
2c6a3cb1f2 originally added this struct
member and then 1be863afdb later added
some more logic to loadfile that uses this. There's been more changes
since then of course, but bits using playback_short and playback_start
have mostly stayed the same. It's a bit strange it's worked this way for
so long since it makes an assumption on how long files should be and
leads to weird, broken behavior on playlists with shorter videos. The
main reason for playlist_short, as far as I can tell, is to deal with
some fringe cases with short videos and trying to go back in the
playlist. More specifically, if you use --loop=inf on a very short video
(say less than 1 second) and try to go back in the playlist, you won't
be able to without any of this special logic that deals with it. But the
current approach has several side effects like going back multiple items
in the playlist instead of just one if the video is less than one
second. This is just bad so delete everything related to playlist_short
and playlist_start.

Instead, let's handle this by keeping track of playlist-prev attempts.
Going forward in the playlist doesn't require any special handling since
a bad/broken file will just advance to the next one. So it's only going
backwards that requires some special consideration. If we're going
backwards and the user isn't using force, then mark the playlist entry
with a special flag. If the file loads successfully in
play_current_file, we can just clear the flag and not worry about it.
However if there's a failure, then we set a bool telling
play_current_file that it should go back one more item in the playlist
if possible and try again. This way, we avoid the previously mentioned
--loop=inf edgecase and the user can still attempt to retry previously
failed items in the playlist (like a url or such).

Fixes #6576, fixes #12548.
2023-10-05 17:09:43 +02:00
Guido Cella e1f9444d4d playlist: remove unused code to track redirects
It turns out that the code to track redirects (playlists and
directories) never worked correctly, only the last redirect is
remembered and num_redirects is never greater than 1.

You can see this by doing quit-watch-later with the old watch later
system, before dbf244fd2f, on a m3u playlist of files and a m3u playlist
of directories. Only in the first case a redirect entry for the m3u file
is created, because in the second case the m3u redirect is replaced by
the directory one.

If you did mpv --directory-mode=lazy /foo it did create redirect entries
for all subdirectories e.g. /foo/bar, /foo/bar/baz, /foo/bar/baz/qux,
this made it seem like it worked correctly, but actually
/foo/bar/bar/qux was the only redirect entry and thus it was considered
as the first redirect, and mpv created redirect entries for each segment
of the first redirect only.

In the previous commit dbf244fd2f, rather than figuring out how to fix
the code to track redirects, and since creating redirect entries for
multiple redirects is overkill, I just used the new playlist-path
property which does the same thing but only for the last redirect.

By replacing the only other use of the old redirect code with
playlist-path, we can remove it.
2023-08-28 18:31:17 +00:00
Dudemanguy e8a77e5279 player: add playlist-path properties
A bit of a long standing pain with scripting is that when opening a file
that gets interpreted as a playlist (like an m3u), the original path of
the file gets thrown away later. Workarounds basically consist of
getting the filename before mpv expands the path, but that's not really
reliable. Instead of throwing it away, save the original playlist path
by copying to the playlist entries when applicable (demuxer playlist and
the playlist option). Then expose these as properties: playlist-path for
the currently playing entry and playlist/N/playlist-path for each
specific entry. Closes #8508, #7605.
2023-08-13 19:58:20 +00:00
wm4 df0d8cda08 client API: report IDs of inserted playlist entries on loading playlist
May or may not help when dealing with playlist loading in scripts. It's
supposed to help with the mean fact that loading a recursive playlist
will essentially edit the playlist behind the API user's back.
2020-03-27 00:57:11 +01:00
wm4 7e885a3bc3 client API: add a playlist entry unique ID
This should make dealing with some async. things easier.

It's intentionally not a globally unique ID.
2020-03-21 19:33:03 +01:00
wm4 5a26150717 command: add a playlist-unshuffle command
Has a number of restrictions.

See: #2491, #7294
2019-12-28 21:32:15 +01:00
wm4 582f3f7cc0 playlist: change from linked list to an array
Although a linked list was ideal at first, there are cases where it
sucks, and became increasingly awkward (with the mpv command API
preferring integer indexes to access the list). In future, we probably
want to add more playlist-related functionality, so better change it to
an array now.

An array isn't always ideal either. Since playlist entries are still
separate objects (because in some cases you need a stable "iterator" to
it), but you still need to efficiently get the next/previous playlist
entry, there's a pl_index field, that needs to be maintained. E.g.
adding an entry at the start of the playlist => update the pl_index
field for all other entries. Well, it's not really worth to do something
more complicated to avoid these things.

This commit is probably buggy as shit. It's not like I bothered to test
everything. That's _your_ role.
2019-12-28 21:32:15 +01:00
wm4 1cb9e7efb8 stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)

It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.

The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
  ("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this

This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.

I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).

There may be a lot of bugs in this.

This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit

Fixes: #7274
2019-12-20 13:00:39 +01:00
wm4 76dc5d9aa9 command: make loadlist command async and abortable
Don't allow it to freeze everything when loading a playlist from network
(although you definitely shouldn't do that, but whatever).

This also affects the really obscure --ordered-chapters-files option.
The --playlist option on the other hand has no choice but to freeze the
shit, because there's no concept of aborting the player during command
line parsing.
2018-05-24 19:56:35 +02:00
wm4 8a9b64329c Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.

There are probably more files to which this applies, but I'm being
conservative here.

A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).

common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.

codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.

From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).

misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.

screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
wm4 35f43dfacb player: make watch later/resume work when "playing" directories
If you do "mpv /bla/", and then branch out into sub-directories using
playlist navigation, and then used quit and watch later, then playing
the same directory did not resume from the previous point. This was
because resuming is based on the path hash, so a path prefix can't be
detected when resuming the parent directory.

Solve this by writing each path prefix when playing directories is
involved. (This includes all parent paths, so interestingly, "mpv /"
would also resume in the above example.)

Something like this was requested multiple times, and I want it too.
2016-01-06 22:40:55 +01:00
wm4 8e82a64f56 player: parse and expose m3u playlist titles
Requested. Closes #2100.
2015-07-10 21:22:35 +02:00
Marcin Kurczewski f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
wm4 a4b6bf8c41 player: refine rar:// playlist-safety handling
It was possible to make the player play local files by putting rar://
links into remote playlists, and some other potentially unsafe things.

Redo the handling of it. Now the rar-redirector (the thing in
demux_playlist.c) sets disable_safety, which makes the player open any
playlist entries returned. This is fine, because it redirects to the
same file anyway (just with different selection/interpretation of the
contents). On the other hand, rar:// itself is now considered fully
unsafe, which means that it is ignored if found in normal playlists.
2015-03-02 19:09:36 +01:00
wm4 c0fbab7a7c player: deal with some corner cases with playlist navigation
The purpose is making accessing the current playlist entry saner when
commands are executed during initialization, termination, or after
playlist navigation commands.

For example, the "playlist_remove current" command will invalidate
playlist->current - but some things still access the playlist entry even
on uninit. Until now, checking stop_play implicitly took care of it, so
it worked, but it was still messy.

Introduce the mpctx->playing field, which points to the current playlist
entry, even if the entry was removed and/or the playlist's current entry
was moved (e.g. due to playlist navigation).
2014-09-09 01:23:10 +02:00
wm4 5ea84e17c0 player: don't allow remote playlists to load local files
Because that might be a bad idea.

Note that remote playlists still can use any protocol marked with
is_safe and is_network, because the case of http-hosted playlists
containing URLs using other streaming protocols is not unusual.
2014-09-01 00:13:22 +02:00
wm4 866e0e1670 player: always load playlists
Until now, you had to use --load-unsafe-playlists or --playlist to get
playlists loaded. Change this and always load playlists by default.

This still attempts to reject unsafe URLs. For example, trying to invoke
libavdevice pseudo-demuxer is explicitly prevented. Local paths and any
http links (and some more) are always allowed.
2014-08-31 19:49:39 +02:00
wm4 68ff8a0484 Move compat/ and bstr/ directory contents somewhere else
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.

The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
2014-08-29 12:31:52 +02:00
Alessandro Ghedini 08415933db command: append entries to the end of the playlist with loadlist append
Currently entries are added after the current playlist element. This is kinda
confusing, more so given that "loadfile append" appends at the end of the
playlist.
2014-07-25 14:32:34 +02:00
wm4 47972a0077 player: remove ASX, SMIL and NSC playlist parsers
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.
2014-04-13 15:40:05 +02:00
wm4 0112143fda Split mpvcore/ into common/, misc/, bstr/ 2013-12-17 02:39:45 +01:00