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

385 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 struct demuxer *open_demuxer(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 MPContext *mpctx, char *filename, 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
{
return demux_open_withparams(&mpctx->opts, stream,
DEMUXER_TYPE_MATROSKA, NULL, mpctx->opts.audio_id,
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
mpctx->opts.video_id, mpctx->opts.sub_id, filename, 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
}
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;
cache: refactor how cache enabling is done Code enabling the cache by default for network streams did that by modifying the value of the "cache" option. This wasn't sane, as multiple streams may be created and all share the same options. Change the code to not modify options but store data in the stream instance instead. Conflicts: core/mplayer.c demux/demux.c stream/cache2.c stream/network.c stream/network.h stream/pnm.c stream/stream.c stream/stream_rtp.c Merged from mplayer2 commit e26070. Note that this doesn't solve any actual bug, as the playlist crashing bug has been fixed before. Since the global cache size option value is not overwritten anymore, the option doesn't need to be restored on end of playback (M_OPT_LOCAL).
2012-11-17 17:12:13 +00:00
if (!(opts->stream_cache_size > 0 ||
opts->stream_cache_size < 0 && (*stream)->cache_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
return 0;
char *filename = talloc_strdup(NULL, (*demuxer)->filename);
free_demuxer(*demuxer);
free_stream(*stream);
int format = 0;
*stream = open_stream(filename, &mpctx->opts, &format);
if (!*stream) {
talloc_free(filename);
return -1;
}
stream_enable_cache_percent(*stream,
opts->stream_cache_size,
opts->stream_cache_min_percent,
opts->stream_cache_seek_min_percent);
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
*demuxer = open_demuxer(*stream, mpctx, filename, 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
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,
};
int format = 0;
struct stream *s = open_stream(filename, &mpctx->opts, &format);
if (!s)
return false;
struct demuxer *d = open_demuxer(s, mpctx, filename, &params);
if (!d) {
free_stream(s);
return was_valid;
}
if (d->file_format == DEMUXER_TYPE_MATROSKA) {
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");
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 (mpctx->demuxer->stream->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;
}