RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/core/timeline/tl_matroska.c

375 lines
13 KiB
C
Raw Normal View History

core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
/*
* This file is part of MPlayer.
*
* MPlayer is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* MPlayer is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with MPlayer; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
#include <stdlib.h>
#include <stdbool.h>
#include <inttypes.h>
tl_matroska.c: move the find_files() function here 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().
2011-02-23 15:57:08 +00:00
#include <assert.h>
#include <dirent.h>
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
#include <libavutil/common.h>
windows support: unicode filenames 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.
2012-02-03 07:05:11 +00:00
#include "osdep/io.h"
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
#include "talloc.h"
Rename directories, move files (step 2 of 2) Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
2012-11-09 00:06:43 +00:00
#include "core/mp_core.h"
#include "core/mp_msg.h"
#include "demux/demux.h"
#include "core/path.h"
#include "core/bstr.h"
#include "core/mp_common.h"
demuxer.h: avoid including stream.h 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.
2011-08-19 02:36:27 +00:00
#include "stream/stream.h"
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
struct find_entry {
char *name;
int matchlen;
struct stat.st_blocks is not available on MinGW
2012-02-28 22:01:13 +00:00
off_t size;
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
};
static int cmp_entry(const void *pa, const void *pb)
{
const struct find_entry *a = pa, *b = pb;
// check "similar" filenames first
int matchdiff = b->matchlen - a->matchlen;
if (matchdiff)
return FFSIGN(matchdiff);
// check small files first
struct stat.st_blocks is not available on MinGW
2012-02-28 22:01:13 +00:00
off_t sizediff = a->size - b->size;
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
if (sizediff)
return FFSIGN(sizediff);
return 0;
}
tl_matroska.c: move the find_files() function here 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().
2011-02-23 15:57:08 +00:00
static char **find_files(const char *original_file, const char *suffix)
{
void *tmpmem = talloc_new(NULL);
char *basename = mp_basename(original_file);
struct bstr directory = mp_dirname(original_file);
char **results = talloc_size(NULL, 0);
char *dir_zero = bstrdup0(tmpmem, directory);
DIR *dp = opendir(dir_zero);
if (!dp) {
talloc_free(tmpmem);
return results;
}
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
struct find_entry *entries = NULL;
tl_matroska.c: move the find_files() function here 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().
2011-02-23 15:57:08 +00:00
struct dirent *ep;
int num_results = 0;
while ((ep = readdir(dp))) {
int suffix_offset = strlen(ep->d_name) - strlen(suffix);
// name must end with suffix
if (suffix_offset < 0 || strcmp(ep->d_name + suffix_offset, suffix))
continue;
// don't list the original name
if (!strcmp(ep->d_name, basename))
continue;
bstr: rename bstr() function to bstr0(), and typedef bstr to struct bstr Replace all uses of bstr() with bstr0(). Also remove the ridiculous C++ workaround.
2012-07-28 21:47:42 +00:00
char *name = mp_path_join(results, directory, bstr0(ep->d_name));
tl_matroska.c: move the find_files() function here 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().
2011-02-23 15:57:08 +00:00
char *s1 = ep->d_name;
char *s2 = basename;
int matchlen = 0;
while (*s1 && *s1++ == *s2++)
matchlen++;
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
// be a bit more fuzzy about matching the filename
matchlen = (matchlen + 3) / 5;
struct stat statbuf;
if (stat(name, &statbuf) != 0)
continue;
struct stat.st_blocks is not available on MinGW
2012-02-28 22:01:13 +00:00
off_t size = statbuf.st_size;
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
core, timeline: don't keep separate stream field 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.
2012-08-19 15:58:58 +00:00
entries = talloc_realloc(tmpmem, entries, struct find_entry,
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
num_results + 1);
struct stat.st_blocks is not available on MinGW
2012-02-28 22:01:13 +00:00
entries[num_results] = (struct find_entry) { name, matchlen, size };
tl_matroska.c: move the find_files() function here 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().
2011-02-23 15:57:08 +00:00
num_results++;
}
closedir(dp);
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
// NOTE: maybe should make it compare pointers instead
tl_matroska: fix NULL pointer issue Found by clang analyzer. Probably doesn't matter in practice, because the number of entries was 0 when entries was NULL.
2012-10-31 23:24:08 +00:00
if (entries)
qsort(entries, num_results, sizeof(struct find_entry), cmp_entry);
tl_matroska.c: move the find_files() function here 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().
2011-02-23 15:57:08 +00:00
results = talloc_realloc(NULL, results, char *, num_results);
matroska: speed up ordered chapters scanning with improved heuristics 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.
2011-10-04 00:41:18 +00:00
for (int i = 0; i < num_results; i++) {
results[i] = entries[i].name;
tl_matroska.c: move the find_files() function here 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().
2011-02-23 15:57:08 +00:00
}
talloc_free(tmpmem);
return results;
}
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
core, timeline: cache external ordered chapter files too 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
2012-08-19 13:31:38 +00:00
static int enable_cache(struct MPContext *mpctx, struct stream **stream,
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
struct demuxer **demuxer, struct demuxer_params *params)
core, timeline: cache external ordered chapter files too 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
2012-08-19 13:31:38 +00:00
{
struct MPOpts *opts = &mpctx->opts;
options: add --cache-default option Add this option, which lets users set the cache size without forcing it even when playing from the local filesystem. Also document the default value explicitly. The Matroska linked segments case is slightly simplified: they can never come from network (mostly because it'd be insane, and we can't even list files from network sources), so the cache will never be enabled automatically.
2013-07-10 13:03:54 +00:00
if (opts->stream_cache_size <= 0)
core, timeline: cache external ordered chapter files too 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
2012-08-19 13:31:38 +00:00
return 0;
char *filename = talloc_strdup(NULL, (*demuxer)->filename);
free_demuxer(*demuxer);
free_stream(*stream);
core: change open_stream and demux_open signature This removes the dependency on DEMUXER_TYPE_* and the file_format parameter from the stream open functions. Remove some of the playlist handling code. It looks like this was needed only for loading linked mov files with demux_mov (which was removed long ago). Delete a minor bit of dead network-related code from stream.c as well.
2013-07-11 19:10:42 +00:00
*stream = stream_open(filename, &mpctx->opts);
core, timeline: cache external ordered chapter files too 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
2012-08-19 13:31:38 +00:00
if (!*stream) {
talloc_free(filename);
return -1;
}
cache: make the stream cache a proper stream that wraps other streams Before this commit, the cache was franken-hacked on top of the stream API. You had to use special functions (like cache_stream_fill_buffer() instead of stream_fill_buffer()), which would access the stream in a cached manner. The whole idea about the previous design was that the cache runs in a thread or in a forked process, while the cache awa functions made sure the stream instance looked consistent to the user. If you used the normal functions instead of the special ones while the cache was running, you were out of luck. Make it a bit more reasonable by turning the cache into a stream on its own. This makes it behave exactly like a normal stream. The stream callbacks call into the original (uncached) stream to do work. No special cache functions or redirections are needed. The only different thing about cache streams is that they are created by special functions, instead of being part of the auto_open_streams[] array. To make things simpler, remove the threading implementation, which was messed into the code. The threading code could perhaps be kept, but I don't really want to have to worry about this special case. A proper threaded implementation will be added later. Remove the cache enabling code from stream_radio.c. Since enabling the cache involves replacing the old stream with a new one, the code as-is can't be kept. It would be easily possible to enable the cache by requesting a cache size (which is also much simpler). But nobody uses stream_radio.c and I can't even test this thing, and the cache is probably not really important for it either.
2013-05-24 16:49:09 +00:00
stream_enable_cache_percent(stream,
core, timeline: cache external ordered chapter files too 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
2012-08-19 13:31:38 +00:00
opts->stream_cache_size,
options: add --cache-default option Add this option, which lets users set the cache size without forcing it even when playing from the local filesystem. Also document the default value explicitly. The Matroska linked segments case is slightly simplified: they can never come from network (mostly because it'd be insane, and we can't even list files from network sources), so the cache will never be enabled automatically.
2013-07-10 13:03:54 +00:00
opts->stream_cache_def_size,
core, timeline: cache external ordered chapter files too 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
2012-08-19 13:31:38 +00:00
opts->stream_cache_min_percent,
opts->stream_cache_seek_min_percent);
core: change open_stream and demux_open signature This removes the dependency on DEMUXER_TYPE_* and the file_format parameter from the stream open functions. Remove some of the playlist handling code. It looks like this was needed only for loading linked mov files with demux_mov (which was removed long ago). Delete a minor bit of dead network-related code from stream.c as well.
2013-07-11 19:10:42 +00:00
*demuxer = demux_open(*stream, "mkv", params, &mpctx->opts);
core, timeline: cache external ordered chapter files too 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
2012-08-19 13:31:38 +00:00
if (!*demuxer) {
talloc_free(filename);
free_stream(*stream);
return -1;
}
talloc_free(filename);
return 1;
}
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
// segment = get Nth segment of a multi-segment file
static bool check_file_seg(struct MPContext *mpctx, struct demuxer **sources,
int num_sources, unsigned char uid_map[][16],
char *filename, int segment)
{
bool was_valid = false;
struct demuxer_params params = {
.matroska_wanted_uids = uid_map,
.matroska_wanted_segment = segment,
.matroska_was_valid = &was_valid,
};
core: change open_stream and demux_open signature This removes the dependency on DEMUXER_TYPE_* and the file_format parameter from the stream open functions. Remove some of the playlist handling code. It looks like this was needed only for loading linked mov files with demux_mov (which was removed long ago). Delete a minor bit of dead network-related code from stream.c as well.
2013-07-11 19:10:42 +00:00
struct stream *s = stream_open(filename, &mpctx->opts);
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
if (!s)
return false;
core: change open_stream and demux_open signature This removes the dependency on DEMUXER_TYPE_* and the file_format parameter from the stream open functions. Remove some of the playlist handling code. It looks like this was needed only for loading linked mov files with demux_mov (which was removed long ago). Delete a minor bit of dead network-related code from stream.c as well.
2013-07-11 19:10:42 +00:00
struct demuxer *d = demux_open(s, "mkv", &params, &mpctx->opts);
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
if (!d) {
free_stream(s);
return was_valid;
}
demux: rewrite probing and demuxer initialization Get rid of the strange and messy reliance on DEMUXER_TYPE_ constants. Instead of having two open functions for the demuxer callbacks (which somehow are both optional, but you can also decide to implement both...), just have one function. This function takes a parameter that tells the demuxer how strictly it should check for the file headers. This is a nice simplification and allows more flexibility. Remove the file extension code. This literally did nothing (anymore). Change demux_lavf so that we check our other builtin demuxers first before libavformat tries to guess by file extension.
2013-07-12 19:58:11 +00:00
if (d->type == DEMUXER_TYPE_MATROSKA) {
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
for (int i = 1; i < num_sources; i++) {
if (sources[i])
continue;
if (!memcmp(uid_map[i], d->matroska_data.segment_uid, 16)) {
mp_msg(MSGT_CPLAYER, MSGL_INFO, "Match for source %d: %s\n",
i, d->filename);
if (enable_cache(mpctx, &s, &d, &params) < 0)
continue;
sources[i] = d;
return true;
}
}
}
free_demuxer(d);
free_stream(s);
return was_valid;
}
static void check_file(struct MPContext *mpctx, struct demuxer **sources,
int num_sources, unsigned char uid_map[][16],
char *filename, int first)
{
for (int segment = first; ; segment++) {
if (!check_file_seg(mpctx, sources, num_sources, uid_map,
filename, segment))
break;
}
}
static bool missing(struct demuxer **sources, int num_sources)
{
for (int i = 0; i < num_sources; i++) {
if (!sources[i])
return true;
}
return false;
}
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
static int find_ordered_chapter_sources(struct MPContext *mpctx,
core, timeline: don't keep separate stream field 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.
2012-08-19 15:58:58 +00:00
struct demuxer **sources,
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
int num_sources,
unsigned char uid_map[][16])
{
int num_filenames = 0;
char **filenames = NULL;
if (num_sources > 1) {
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
char *main_filename = mpctx->demuxer->filename;
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
mp_msg(MSGT_CPLAYER, MSGL_INFO, "This file references data from "
"other sources.\n");
cache: make the stream cache a proper stream that wraps other streams Before this commit, the cache was franken-hacked on top of the stream API. You had to use special functions (like cache_stream_fill_buffer() instead of stream_fill_buffer()), which would access the stream in a cached manner. The whole idea about the previous design was that the cache runs in a thread or in a forked process, while the cache awa functions made sure the stream instance looked consistent to the user. If you used the normal functions instead of the special ones while the cache was running, you were out of luck. Make it a bit more reasonable by turning the cache into a stream on its own. This makes it behave exactly like a normal stream. The stream callbacks call into the original (uncached) stream to do work. No special cache functions or redirections are needed. The only different thing about cache streams is that they are created by special functions, instead of being part of the auto_open_streams[] array. To make things simpler, remove the threading implementation, which was messed into the code. The threading code could perhaps be kept, but I don't really want to have to worry about this special case. A proper threaded implementation will be added later. Remove the cache enabling code from stream_radio.c. Since enabling the cache involves replacing the old stream with a new one, the code as-is can't be kept. It would be easily possible to enable the cache by requesting a cache size (which is also much simpler). But nobody uses stream_radio.c and I can't even test this thing, and the cache is probably not really important for it either.
2013-05-24 16:49:09 +00:00
if (mpctx->demuxer->stream->uncached_type != STREAMTYPE_FILE) {
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
mp_msg(MSGT_CPLAYER, MSGL_WARN, "Playback source is not a "
"normal disk file. Will not search for related files.\n");
} else {
mp_msg(MSGT_CPLAYER, MSGL_INFO, "Will scan other files in the "
"same directory to find referenced sources.\n");
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
filenames = find_files(main_filename, ".mkv");
tl_matroska.c: move the find_files() function here 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().
2011-02-23 15:57:08 +00:00
num_filenames = MP_TALLOC_ELEMS(filenames);
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
}
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
// Possibly get further segments appended to the first segment
check_file(mpctx, sources, num_sources, uid_map, main_filename, 1);
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
}
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
for (int i = 0; i < num_filenames; i++) {
if (!missing(sources, num_sources))
break;
mp_msg: remove filename_recode 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.
2012-07-30 23:35:53 +00:00
mp_msg(MSGT_CPLAYER, MSGL_INFO, "Checking file %s\n", filenames[i]);
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
check_file(mpctx, sources, num_sources, uid_map, filenames[i], 0);
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
}
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
talloc_free(filenames);
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
if (missing(sources, num_sources)) {
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
mp_msg(MSGT_CPLAYER, MSGL_ERR, "Failed to find ordered chapter part!\n"
"There will be parts MISSING from the video!\n");
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
int j = 1;
for (int i = 1; i < num_sources; i++)
core, timeline: don't keep separate stream field 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.
2012-08-19 15:58:58 +00:00
if (sources[i]) {
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
sources[j] = sources[i];
memcpy(uid_map[j], uid_map[i], 16);
j++;
}
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
num_sources = j;
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
}
core: matroska: support concatenated segments Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
2013-04-14 00:49:07 +00:00
return num_sources;
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
}
void build_ordered_chapter_timeline(struct MPContext *mpctx)
{
struct MPOpts *opts = &mpctx->opts;
if (!opts->ordered_chapters) {
mp_msg(MSGT_CPLAYER, MSGL_INFO, "File uses ordered chapters, but "
"you have disabled support for them. Ignoring.\n");
return;
}
mp_msg(MSGT_CPLAYER, MSGL_INFO, "File uses ordered chapters, will build "
"edit timeline.\n");
struct demuxer *demuxer = mpctx->demuxer;
struct matroska_data *m = &demuxer->matroska_data;
// +1 because sources/uid_map[0] is original file even if all chapters
// actually use other sources and need separate entries
core, timeline: don't keep separate stream field 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.
2012-08-19 15:58:58 +00:00
struct demuxer **sources = talloc_array_ptrtype(NULL, sources,
m->num_ordered_chapters+1);
sources[0] = mpctx->demuxer;
demux_mkv: skip files faster in ordered chapter file search 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.
2011-08-04 05:38:39 +00:00
unsigned char (*uid_map)[16] = talloc_array_ptrtype(NULL, uid_map,
m->num_ordered_chapters + 1);
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
int num_sources = 1;
memcpy(uid_map[0], m->segment_uid, 16);
for (int i = 0; i < m->num_ordered_chapters; i++) {
struct matroska_chapter *c = m->ordered_chapters + i;
if (!c->has_segment_uid)
memcpy(c->segment_uid, m->segment_uid, 16);
for (int j = 0; j < num_sources; j++)
if (!memcmp(c->segment_uid, uid_map[j], 16))
goto found1;
memcpy(uid_map[num_sources], c->segment_uid, 16);
core, timeline: don't keep separate stream field 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.
2012-08-19 15:58:58 +00:00
sources[num_sources] = NULL;
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
num_sources++;
found1:
;
}
num_sources = find_ordered_chapter_sources(mpctx, sources, num_sources,
uid_map);
// +1 for terminating chapter with start time marking end of last real one
struct timeline_part *timeline = talloc_array_ptrtype(NULL, timeline,
m->num_ordered_chapters + 1);
struct chapter *chapters = talloc_array_ptrtype(NULL, chapters,
m->num_ordered_chapters);
uint64_t starttime = 0;
uint64_t missing_time = 0;
int part_count = 0;
int num_chapters = 0;
uint64_t prev_part_offset = 0;
for (int i = 0; i < m->num_ordered_chapters; i++) {
struct matroska_chapter *c = m->ordered_chapters + i;
int j;
for (j = 0; j < num_sources; j++) {
if (!memcmp(c->segment_uid, uid_map[j], 16))
goto found2;
}
missing_time += c->end - c->start;
continue;
found2:;
/* Only add a separate part if the time or file actually changes.
* Matroska files have chapter divisions that are redundant from
* timeline point of view because the same chapter structure is used
* both to specify the timeline and for normal chapter information.
* Removing a missing inserted external chapter can also cause this.
* We allow for a configurable fudge factor because of files which
* specify chapter end times that are one frame too early;
* we don't want to try seeking over a one frame gap. */
int64_t join_diff = c->start - starttime - prev_part_offset;
if (part_count == 0
|| FFABS(join_diff) > opts->chapter_merge_threshold * 1000000
core, timeline: don't keep separate stream field 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.
2012-08-19 15:58:58 +00:00
|| sources[j] != timeline[part_count - 1].source) {
timeline[part_count].source = sources[j];
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
timeline[part_count].start = starttime / 1e9;
timeline[part_count].source_start = c->start / 1e9;
prev_part_offset = c->start - starttime;
part_count++;
} else if (part_count > 0 && join_diff) {
/* Chapter was merged at an inexact boundary;
* adjust timestamps to match. */
mp_msg(MSGT_CPLAYER, MSGL_V, "Merging timeline part %d with "
demux_mkv: skip files faster in ordered chapter file search 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.
2011-08-04 05:38:39 +00:00
"offset %g ms.\n", i, join_diff / 1e6);
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
starttime += join_diff;
}
chapters[num_chapters].start = starttime / 1e9;
chapters[num_chapters].name = talloc_strdup(chapters, c->name);
starttime += c->end - c->start;
num_chapters++;
}
timeline[part_count].start = starttime / 1e9;
demux_mkv: skip files faster in ordered chapter file search 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.
2011-08-04 05:38:39 +00:00
talloc_free(uid_map);
core: ordered chapters: move timeline creation to timeline/ 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.
2011-02-14 07:34:39 +00:00
if (!part_count) {
// None of the parts come from the file itself???
talloc_free(sources);
talloc_free(timeline);
talloc_free(chapters);
return;
}
if (missing_time)
mp_msg(MSGT_CPLAYER, MSGL_ERR, "There are %.3f seconds missing "
"from the timeline!\n", missing_time / 1e9);
mpctx->sources = sources;
mpctx->num_sources = num_sources;
mpctx->timeline = timeline;
mpctx->num_timeline_parts = part_count;
mpctx->num_chapters = num_chapters;
mpctx->chapters = chapters;
}