From 82faf2d5817af3ca8d303a8e1b62f23bb461dcaf Mon Sep 17 00:00:00 2001 From: Carl Hetherington Date: Tue, 24 Nov 2020 23:01:04 +0100 Subject: Fix the behaviour of FileGroup when seeking too far. Previously, if you did a seek off the end of the file group, the seek would return an error. This is not what fseek() does; it returns no error, and preserves the file pointer (returned by ftell()) as if the seek had been successful. fread()s after a too-far seek return no data, of course. Parsing some files (the example used to find the bug was a H264 MP4) involves a seek which is to the byte after the end of the mp4 file. If this fails the whole header parsing fails and DCP-o-matic refuses to use the file. --- src/lib/file_group.cc | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'src/lib') diff --git a/src/lib/file_group.cc b/src/lib/file_group.cc index 3e8a7b79c..f06ca3007 100644 --- a/src/lib/file_group.cc +++ b/src/lib/file_group.cc @@ -132,12 +132,18 @@ FileGroup::seek (int64_t pos, int whence) const if (sub_pos < int64_t (len)) { break; } - sub_pos -= len; ++i; + if (i < _paths.size()) { + /* If we've run out of files we need to seek off the end of the last file */ + sub_pos -= len; + } } if (i == _paths.size ()) { - return -1; + /* Seeking too far isn't an error; we'll seek too far in the last file which + * will "pass on" fseek()'s behaviour to our caller. + */ + i--; } ensure_open_path (i); -- cgit v1.2.3