summaryrefslogtreecommitdiffstats
path: root/timeline
Commit message (Collapse)AuthorAgeFilesLines
* core, timeline: cache external ordered chapter files tooStefano Pigozzi2012-09-181-5/+49
| | | | | | | | | | | | | | | | | | | | | | | Previously, Matroska source files other than the initially opened one were always accessed without caching. Enable cache for extra files too. A separate cache process/thread is started for each file, which is less than optimal but probably better than no caching if the user explicitly enabled cache. This commit only implements caching for Matroska ordered chapters (not for EDL timeline). To build the timeline we need to demux the files in the current directory to look for segments with matching uuid. This first demux is done with no cache since we don't need to read a lot of the stream. If the file is recognized as one of the needed sources it's reopened with cache enabled. Also move the stream_cache_size global variable to the options struct. Conflicts: cfg-mplayer.h mplayer.c stream/stream.h timeline/tl_matroska.c
* core: move implementation for -audiofile to the frontendwm42012-09-181-1/+1
| | | | This should behave as before, with the same set of caveats.
* core, timeline: don't keep separate stream fieldwm42012-09-073-35/+23
| | | | | | | | | | | The timeline code kept pairs of stream and demuxer references around. The reference to the stream is redundant, because it can be accessed through the demuxer. Simplify the code by removing the redundant stream reference. Also, set mpctx->stream to the current segment when using timeline. Fix a small memory leak in tl_matroska.c introduced earlier.
* mp_msg: remove filename_recodewm42012-07-311-3/+2
| | | | | | | | | | This was intended for translating filenames from filesystem charset to the terminal charset. Modern sane platforms use UTF-8 for everything, and on Windows we use unicode APIs, so this is not needed anymore. Remove filename_recode, all uses of it, options and configure checks related to terminal output charset, and code that tries to determine the same.
* bstr: rename bstr() function to bstr0(), and typedef bstr to struct bstrwm42012-07-283-14/+14
| | | | | Replace all uses of bstr() with bstr0(). Also remove the ridiculous C++ workaround.
* Merge remote-tracking branch 'origin/master'wm42012-07-281-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .gitignore bstr.c cfg-mplayer.h defaultopts.c libvo/video_out.c The conflict in bstr.c is due to uau adding a bstr_getline function in commit 2ba8b91a97e7e8. This function already existed in this branch. While uau's function is obviously derived from mine, it's incompatible. His function preserves line breaks, while mine strips them. Add a bstr_strip_linebreaks function, fix all other uses of bstr_getline, and pick uau's implementation. In .gitignore, change vo_gl3_shaders.h to use an absolute path additional to resolving the merge conflict.
* | Merge remote-tracking branch 'origin/master' into my_masterwm42012-03-161-0/+2
|\| | | | | | | | | | | | | | | Conflicts: command.c mp_core.h mplayer.c screenshot.c
| * windows support: unicode filenameswm42012-03-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Windows uses a legacy codepage for char* / runtime functions accepting char *. Using UTF-8 as the codepage with setlocale() is explicitly forbidden. Work this around by overriding the MSVCRT functions with wrapper macros, that assume UTF-8 and use "proper" API calls like _wopen etc. to deal with unicode filenames. All code that uses standard functions that take or return filenames must now include osdep/io.h. stat() can't be overridden, because MinGW-w64 itself defines "stat" as a macro. Change code to use use mp_stat() instead. This is not perfectly clean, but still somewhat sane, and much better than littering the rest of the mplayer code with MinGW specific hacks. It's also a bit fragile, but that's actually little different from the previous situation. Also, MinGW is unlikely to ever include a nice way of dealing with this.
* | struct stat.st_blocks is not available on MinGWwm42012-02-281-4/+4
| |
* | cue: play .bin files as raw PCM audio (even if it means playing noise)wm42012-02-261-0/+14
| | | | | | | | | | | | | | | | | | | | The cue code will open the .bin file with demux_rawaudio if the file can't be opened otherwise. In case the .bin file isn't in the exact format demux_rawaudio uses (usually 44100 Hz, 2 ch, s16le PCM), noise will be played. This is done only if no other demuxer could open the file, and the file extension is ".bin".
* | core: add new support for reading .cue fileswm42012-01-181-0/+422
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Playing a .cue file directly will now parse the .cue file, and load and play the file(s) referenced in the cue. If multiple files are referenced, a timeline including all files will be created to create the impression of a single, flat audio file containing all the tracks. For each track, a chapter is created. The chapter navigation commands can be used to jump between tracks. The chapter titles will use the string provided by the track's TITLE cue command. (The -identify command can be used to print all chapters in a not so user friendly way.) Other than the chapter names, there is no attempt at displaying or exposing any other meta data contained in the cue files yet. The handling (or lack of thereof) of gaps (track pregaps and postgaps) is probably not correct yet. In general, mplayer's mapping of tracks to the source audio files can be verified by examining the timeline, which will be printed when passing the -v switch. Note that this has nothing to do with the old cue:// support. The old code isn't touched, and is still only able to play .cue/.bin pairs. Prefixing a .cue file with cue:// will always invoke the old code, while playing a .cue file directly (i.e. "mplayer file.cue") will always use the new code. Playing audio images (.cue/.bin pairs of files) doesn't work yet.
* | matroska: speed up ordered chapters scanning with improved heuristicswm42011-12-231-13/+38
|/ | | | | | | | | | | | | | | | | | | | | | | Try to be a bit more clever when scanning for linked mkv files (ordered chapters feature). Instead of just preferring filenames with a closer prefix match, consider file sizes as well. The assumption is that it is better to scan small files first. Achieve this by sorting by prefix first, and then by file size. In order to make this new behavior trigger more often, be a more "fuzzy" about the prefix matching: consider all matches in a certain range as equal. This will speed up the following case: title_01.mkv title_02.mkv title_03.mkv title_op.mkv (title0*.mkv link to it) Playing title_01.mkv, the old code would first scan title_0*, and then title_op.mkv, as "title_0" is the largest prefix. The new code would reduce the common prefix to "title", and then sort the resulting files by size, causing title_op.mkv to be scanned first. The total number of scanned files is reduced.
* demuxer.h: avoid including stream.hUoti Urpala2011-08-192-0/+3
| | | | | | Drop the unnecessary include and add a missing direct include in some files. This also revealed that demux_rtp_internal.h was missing a config.h include, fix that too.
* demux_mkv: skip files faster in ordered chapter file searchUoti Urpala2011-08-041-6/+10
| | | | | | | | | | | | Ordered chapter code tries opening files to find those matching the SegmentUID values specified in the timeline. Previously this scan did a full initialization of the Matroska demuxer for each file, then checked whether the UID value in the demuxer was a match. Make the scan code instead provide a list of searched-for UIDs to the demuxer open code, and make that do a comparison against the list as soon as it sees the UID in the file, aborting if there is no match. Also fix units used in "Merging timeline part" verbose message.
* bstr: rename BSTR() -> bstr()Uoti Urpala2011-07-272-6/+6
| | | | | | Rename the BSTR() function to bstr(). The former caused a conflict with some Windows OS name, and it's no longer a macro so uppercase naming is less appropriate.
* EDL: add support for new EDL file formatUoti Urpala2011-04-052-18/+398
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The timeline code previously added to support Matroska ordered chapters allows constructing a playback timeline from segments picked from multiple source files. Add support for a new EDL format to make this machinery available for use with file formats other than Matroska and in a manner easier to use than creating files with ordered chapters. Unlike the old -edl option which specifies an additional file with edits to apply to the video file given as the main argument, the new EDL format is used by giving only the EDL file as the file to play; that file then contains the filename(s) to use as source files where actual video segments come from. Filename paths in the EDL file are ignored. Currently the source files are only searched for in the directory of the EDL file; support for a search path option will likely be added in the future. Format of the EDL files The first line in the file must be "mplayer EDL file, version 2". The rest of the lines belong to one of these classes: 1) lines specifying source files 2) empty lines 3) lines specifying timeline segments. Lines beginning with '<' specify source files. These lines first contain an identifier used to refer to the source file later, then the filename separated by whitespace. The identifier must start with a letter. Filenames that start or end with whitespace or contain newlines are not supported. On other lines '#' characters delimit comments. Lines that contain only whitespace after comments have been removed are ignored. Timeline segments must appear in the file in chronological order. Each segment has the following information associated with it: - duration - output start time - output end time (= output start time + duration) - source id (specifies the file the content of the segment comes from) - source start time (timestamp in the source file) - source end time (= source start time + duration) The output timestamps must form a continuous timeline from 0 to the end of the last segment, such that each new segment starts from the time the previous one ends at. Source files and times may change arbitrarily between segments. The general format for lines specifying timeline segments is [output time info] source_id [source time info] source_id must be an identifier defined on a '<' line. Both the time info parts consists of zero or more of the following elements: 1) timestamp 2) -timestamp 3) +duration 4) * 5) -* , where "timestamp" and "duration" are decimal numbers (computations are done with nanosecond precision). Whitespace around "+" and "-" is optional. 1) and 2) specify start and end time of the segment on output or source side. 3) specifies duration; the semantics are the same whether this appears on output or source side. 4) and 5) are ignored on the output side (they're always implicitly assumed). On the source side 4) specifies that the segment starts where the previous segment _using this source_ ended; if there was no previous segment time 0 is used. 5) specifies that the segment ends where the next segment using this source starts. Redundant information may be omitted. It will be filled in using the following rules: - output start for first segment is 0 - two of [output start, output end, duration] imply third - two of [source start, source end, duration] imply third - output start = output end of previous segment - output end = output start of next segment - if "*", source start = source end of earlier segment - if "-*", source end = source start of a later segment As a special rule, a last zero-duration segment without a source specification may appear. This will produce no corresponding segment in the resulting timeline, but can be used as syntax to specify the end time of the timeline (with effect equal to adding -time on the previous line). Examples: ----- begin ----- mplayer EDL file, version 2 < id1 filename 0 id1 123 100 id1 456 200 id1 789 300 ----- end ----- All segments come from the source file "filename". First segment (output time 0-100) comes from time 123-223, second 456-556, third 789-889. ----- begin ----- mplayer EDL file, version 2 < f filename f 60-120 f 600-660 f 30- 90 ----- end ----- Play first seconds 60-120 from the file, then 600-660, then 30-90. ----- begin ----- mplayer EDL file, version 2 < id1 filename1 < id2 filename2 +10 id1 * +10 id2 * +10 id1 * +10 id2 * +10 id1 * +10 id2 * ----- end ----- This plays time 0-10 from filename1, then 0-10 from filename1, then 10-20 from filename1, then 10-20 from filename2, then 20-30 from filename1, then 20-30 from filename2. ----- begin ----- mplayer EDL file, version 2 < t1 filename1 < t2 filename2 t1 * +2 # segment 1 +2 t2 100 # segment 2 t1 * # segment 3 t2 *-* # segment 4 t1 3 -* # segment 5 +0.111111 t2 102.5 # segment 6 7.37 t1 5 +1 # segment 7 ----- end ----- This rather pathological example illustrates the rules for filling in implied data. All the values can be determined by recursively applying the rules given above, and the full end result is this: +2 0-2 t1 0-2 # segment 1 +2 2-4 t2 100-102 # segment 2 +0.758889 4-4.758889 t1 2-2.758889 # segment 3 +0.5 4.4758889-5.258889 t2 102-102.5 # segment 4 +2 5.258889-7.258889 t1 3-5 # segment 5 +0.111111 7.258889-7.37 t2 102.5-102.611111 # segment 6 +1 7.37-8.37 t1 5-6 # segment 7
* tl_matroska.c: move the find_files() function hereUoti Urpala2011-03-031-3/+58
| | | | | | Move the find_files() function from findfiles.c to tl_matroska.c. Delete the findfiles.c file. Add a check against opendir() failure in find_files().
* core: ordered chapters: move timeline creation to timeline/Uoti Urpala2011-02-261-0/+234
Add new file timeline/tl_matroska.c. Move the code that parses ordered chapter information from Matroska files and creates the timeline structure based on that to the new file. Initialize the format parameter given to open_stream() in the moved code. The previous uninitialized value shouldn't have caused any visible effects.