[MPlayer-dev-eng] [PATCH] libdvdread 0.9.5 update

[Robert Bradbury]

On 8/12/07, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

> Why would testing for < 0 be wrong? Is there a system where lseek()
> return type would be unsigned? Or do you expect other negative values to
> be valid non-error file positions?


I'm not sure.  The lseek() call has a poor definition history (as did the
seek() call before it).  The Linux man page (and my experience with old UNIX
systems) is that it *always* returned -1 on failure.  It also returns the
offset in bytes in the file that resulted from the seek operation (which
could be between 0 and 2^32 - 2.  While in my system files off_t is defined
as a signed long integer (on x86 thats a signed 32 bit integer) the
documentation does not indicate that attempting to seek to 0x80000000 will
return -1.  On many systems I doubt that it does.  I suspect the precise
semantics for offsets between 2GB and 4GB are undefined and may vary with
implementation.  This wasn't a problem when file sizes (and drives) were all
less than 4 GB in size but those days are now in the distant past.

I'm not certain, but I think the problem I'm having involves reading
chapters on the DVD disk which are in the 2nd layer of a dual layer disk
(which are past 4GB and require greater than a 32 bit seek).  I've got 80
chapters on the disk and mounted disk size is ~8GB but mplayer can only pull
chapters 1-49 off the DVD.  Chapter 50 fails in the middle and chapters
51-80 cannot be read at all.

This wouldn't be a problem if mplayer were reading the actual VOB files on
the disk because those all appear to be < 1.073 GB.  The problem appears to
be when it attempts to read the DVD in raw mode which requires seeking into
the 4-8GB range on the DVD [1].

There are a handful of notes in various bug reports, BBSs, etc. regarding a
handful of programs accessing DVDs (presumably through dvdread and/or
libdvdcss) which indicate that a number of people have tripped over "seek
errors" before.  None of them appear to point out that these
libraries/programs are using lseek() and that it simply will not work on
larger DVDs.

Configure should enable defines needed for largefile support so that
> off_t is 64 bits and plain lseek() works. If that doesn't happen on your
> system investigate the reason for that first.


The configure code is fine.  It defines _FILE_OFFSET_BITS=64 and
_LARGEFILE64_SOURCE.   I just ran a test case with this and it appears that
the lseek() call is getting turned into lseek64() in by the headers and/or
compiler (at least that is what the assembler says).  So I guess I am more
puzzled than before.  While the error return test should *still* be
(off_t)-1, I suspect there is someplace else in the libraries or mplayer
source (stream functions?) that is improperly computing the block address.
There are cases where one is recomputing the block address by dividing the
lseek() return offset by 2048 when one knows if the lseek succeeded that it
has to be at the DVD "block" specified as the argument to the seek
functions.

Robert

1. I will note that there is a possibility that this isn't an mplayer or
library problem but is a Linux and/or DVD problem.  Though the mounted DVD
size is 8,258,968 blocks (8.457 GB) the most a straight "dd" from /dev/dvd
will return is 4.389GB.  But I haven't looked at the dd source code to see
if it has been updated to use lseek64 instead of lseek on 32 bit machines
(if it uses lseek at all).