summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2012-07-31 21:33:26 +0200
committerwm4 <wm4@nowhere>2012-07-31 21:33:26 +0200
commit89a17bcda6c166e98861723b8adc9989f2724c34 (patch)
treef89e05ea12d48c92b04c90c5d447521d29db711c /DOCS
parent6e020e66e0e454e8c7f1eeb17e85b90262e95386 (diff)
downloadmpv-89a17bcda6c166e98861723b8adc9989f2724c34.tar.bz2
mpv-89a17bcda6c166e98861723b8adc9989f2724c34.tar.xz
mplayer: turn playtree into a list, and change per-file option handling
Summary: - There is no playtree anymore. It's reduced to a simple list. - Options are now always global. You can still have per-file options, but these are optional and require special syntax. - The slave command pt_step has been removed, and playlist_next and playlist_prev added. (See etc/input.conf changes.) This is a user visible incompatible change, and will break slave-mode applications. - The pt_clear slave command is renamed to playlist_clear. - Playtree entries could have multiple files. This is not the case anymore, and playlist entries have always exactly one entry. Whenever something adds more than one file (like ASX playlists or dvd:// or dvdnav:// on the command line), all files are added as separate playlist entries. Note that some of the changes are quite deep and violent. Expect regressions. The playlist parsing code in particular is of low quality. I didn't try to improve it, and merely spent to least effort necessary to keep it somehow working. (Especially ASX playlist handling.) The playtree code was complicated and bloated. It was also barely used. Most users don't even know that mplayer manages the playlist as tree, or how to use it. The most obscure features was probably specifying a tree on command line (with '{' and '}' to create/close tree nodes). It filled the player code with complexity and confused users with weird slave commands like pt_up. Replace the playtree with a simple flat playlist. Playlist parsers that actually return trees are changed to append all files to the playlist pre-order. It used to be the responsibility of the playtree code to change per-file config options. Now this is done by the player core, and the playlist code is free of such details. Options are not per-file by default anymore. This was a very obscure and complicated feature that confused even experienced users. Consider the following command line: mplayer file1.mkv file2.mkv --no-audio file3.mkv This will disable the audio for file2.mkv only, because options are per-file by default. To make the option affect all files, you're supposed to put it before the first file. This is bad, because normally you don't need per-file options. They are very rarely needed, and the only reasonable use cases I can imagine are use of the encode backend (mplayer encode branch), or for debugging. The normal use case is made harder, and the feature is perceived as bug. Even worse, correct usage is hard to explain for users. Make all options global by default. The position of an option isn't significant anymore (except for options that compensate each other, consider --shuffle --no-shuffle). One other important change is that no options are reset anymore if a new file is started. If you change settings with slave mode commands, they will not be changed by playing a new file. (Exceptions include settings that are too file specific, like audio/subtitle stream selection.) There is still some need for per-file options. Debugging and encoding are use cases that profit from per-file options. Per-file profiles (as well as per-protocol and per-VO/AO options) need the implementation related mechanisms to backup and restore options when the playback file changes. Simplify the save-slot stuff, which is possible because there is no hierarchical play tree anymore. Now there's a simple backup field. Add a way to specify per-file options on command line. Example: mplayer f1.mkv -o0 --{ -o1 f2.mkv -o2 f3.mkv --} f4.mkv -o3 will have the following options per file set: f1.mkv, f4.mkv: -o0 -o3 f2.mkv, f3.mkv: -o0 -o3 -o1 -o2 The options --{ and --} start and end per-file options. All files inside the { } will be affected by the options equally (similar to how global options and multiple files are handled). When playback of a file starts, the per-file options are set according to the command line. When playback ends, the per-file options are restored to the values when playback started.
Diffstat (limited to 'DOCS')
-rw-r--r--DOCS/OUTDATED-tech/playtree123
1 files changed, 0 insertions, 123 deletions
diff --git a/DOCS/OUTDATED-tech/playtree b/DOCS/OUTDATED-tech/playtree
deleted file mode 100644
index 2aaf5a175e..0000000000
--- a/DOCS/OUTDATED-tech/playtree
+++ /dev/null
@@ -1,123 +0,0 @@
-
-How work the playtree ?
-
-Good question, I try to explain but note that it's the first doc
-I write :)
-
-First there is two things. The playtree itself and the iterator.
-The playtree represent the data and the iterator is used by
-mplayer to go from entry to entry.
-
-First the play_tree struct :
-
-
-struct play_tree {
- play_tree_t* parent;
- play_tree_t* child;
- play_tree_t* next;
- play_tree_t* prev;
-
- play_tree_param_t* params;
- int loop;
- char** files;
- int entry_type;
-};
-
-The play_tree_t* hold the links in the 4 directions, the params hold
-all parameters of this entry, loop is obvious (loop < 0 mean infint loop),
-files hold all the files of this entry and entry_type obviously tell the
-type of this entry (Node, file, dvd, vcd ot tv).
-
-An entry can hold more than one file, why ?
-
-Because an entry can be a network stream and usually you have more than
-one server. But all send the same thing, so it's only on entry with sevral
-sources.
-
-Then how do I use this stuff ?
-
-First you create an entry using the play_tree_new func. This create the struct
-and fill it with defaults values.
-Then this can become a node or a leaf. It will become a node as soon as you link it
-to another one using either play_tree_set_child or play_tree_set_parent.
-Or it will become a leaf as soon as you use play_tree_add_file on it.
-If an entry contain at least one file it can't become an node (an assert will be
-raised) and if en entry has a child you can't add file to (here also an assert will
-be raised).
-Then to create a list of entry you should use play_tree_append_entry,
-play_tree_prepend_entry or play_tree_insert_entry.
-In all this function you can use any entry of the the list as first argument,
-no need that it's the first one. The same apply when you set the child of a node,
-the child argument can be any entry in a list.
-To remove an entry from the tree use play_tree_remove. If the second arg (free_it)
-is true it will also free it, if the entry should be freed and the third
-arg is true it will also free the children.
-
-When your tree is ready you can then use play_tree_cleanup to remove all unuseful
-entries.
-
-If you want to load a playlist you can use parse_playtree which take a stream_t
-as argument or parse_playlist_file which take a filename as argument.
-Both function will return NULL in case of failure or a new (cleaned) tree that
-you can add somewhere in your tree.
-
-How do I add DVD, VCD or TV entry to the tree ?
-
-You should use some virtual URL as filename like :
- dvd://x where x is the title number.
- vcd://x where x is the track number
- tv://x where x is the channel
-
-
-My playtree is ready now, what with this play_tree_iter ?
-
-This is an iterator used to go trough the tree. It handle itself
-loop of list and setting mplayer config according to the params
-of each entry.
-It's created with play_tree_iter_new which take as argument a play_tree_t
-and an m_config_t which is then used to set/unset the params of each entry.
-After creation the iter point to nothing, you should init with a first step.
-To go to another entry in the list you should use play_tree_iter_step. The
-second argument is the direction of the step : positive value go frontward,
-negative go backward and 0 don't move. The third tell if must care of
-node or not. If it's true, the iterator will stop on nodes, otherwise it go
-to the next valid entry.
-This function return different values :
-PLAY_TREE_ITER_ERROR : obvious
-PLAY_TREE_ITER_ENTRY : we are now on an entry
-PLAY_TREE_ITER_NODE : we are now on a node
-PLAY_TREE_ITER_END : we are now at end
-(( Note : I must add a PLAY_TREE_ITER_BEGINNING for the beginning. Don't know
-what it will return in a such case. PLAY_TREE_ITER_ERROR ? ))
-
-There is also play_tree_iter_up_step which can be used to break a loop or skip
-the current list. The argument are the same than play_tree_iter_step. The
-difference is that it go back to parent of the current list, and then step according
-to the arguments.
-
-Then when your iter returned PLAY_TREE_ITER_ENTRY you can use
-play_tree_iter_get_file to get the file. If you call it more than one time
-it will return the next file for this entry or loop trough the list if no more
-file are available. You can now how many files are available using
-iter->num_files and which one it returned using iter->file.
-In case the entry is a DVD, VCD or TV channel the returned string is not a filename
-but "DVD title x", "VCD track x" or "TV channel x".
-To distinc those case from a normal file you can check iter->tree->entry_type.
-It will contain one of PLAY_TREE_ENTRY_DVD, PLAY_TREE_ENTRY_VCD,
-PLAY_TREE_ENTRY_TV or PLAY_TREE_ENTRY_FILE.
-
-If you need to make some check with the iter, such as will next entry be valid, etc
-You must create a clone with play_tree_iter_new_copy. This iter will not affect
-the config, so you can do all you want with it.
-
-Then when you have finish with the iter free it with play_tree_iter_free.
-
-
-Ok, that's all for now. To have some exemples look into mplayer.c ;)
-First just after config parsing, the iterator is created there. Also
-after stream opening, in case the stream is a playlist it replace the
-entry which contained the playlist by the result of the parsing.
-In the event handling it check if a step can be done, etc. And finnaly
-at the end it go the next entry.
-
-Suggestion, flames, etc about this doc must go to albeu@free.fr