[DVDnav-discuss] dvdnav patches from llink project

[Jorgen Lundman]

Since we are re-considering patches, I can resend my first suggested patch for 
convenience.

Other patches are:

1: Proper AD chain functionality: this one.
    (improves UDF compliance, should be considered)

2: Add ExtFileInfo (262) support.
    (Bring us to UDF2.50 compliance, not directly interesting to DVD reading, 
but assists with general UDF reading. /Should be considered).

3: Add FileType (250) re-direct support.
    (Used with UDF2.50, BD-ISO file types. /Should be considered)

4: DVDFileStat
    (Already accepted by other patchers)

5: 32bit to 64bit fixes.
    (Current dvdread reads only last 4 bytes of UDF 8 byte file length, and 
truncate all sizes to 32bit. There is no reason for this hackery, and proper 
64bit values should be maintained in API. /Should be considered)

6: Extend dvd_input's API
    (dvd_input can handle 2 inputs, dvdcss or posix IO. Added API call to set 
own set of IO functions [open,seek,read,close) to allow API callers to define 
external IO. Good for Windows overlapping IO, streaming from containers like 
RAR, other transports etc. /API extension, possibly undesirable by general 
population.)

7: Extend dvdread with UDF2.50/POSIX IO functions.
    (Add API calls to dvdread to be a generic UDF library as well. For UDF2.50 
ISOs, add opendir/readdir/closedir and open() by filename. API extension, 
probably undesired if blurays are not considered.)



------------------------------------------------------------------------

The problem:

dvdread currently assumes that "file" in UDF have a starting block, and a 
length. The data is then contiguous from "start" until the final block.

In reality, UDF is split up into "AD chains" of contiguous segments, generally 
in increasing order. This is true from UDF 1.02 and up. However, it is unknown 
if there are DVDs that would have non-contiguous AD ordering, and only few have 
'gap blocks' so far.


    (reality)        (dvdread's image)
UDF Spec File:      Current dvdread file:
  chain 0 start          file start
        |                    |
  chain 0 end                |
        |                    |
       gap                   |
        |                    |
  chain 1 start              |
        |                    |
  chain 1 end            file end
        |


This means that dvdread will incorrectly send the "gap blocks", as well as reach 
the "end" of the file sooner than it should. (Since gap blocks are counted).

This patch removes the view that a UDF file is start "starting block, and 
length" (known in the sources as 'lbnum'), and creates a new "udf_file_t" 
structure to hold the number of AD chains, the AD chains and a few useful bits 
of information.

A new function has been written to convert the wanted block number inside the 
UDF file. Previously it was always "start_block + offset_block". Now it scans 
the AD chain for the chain in which "offset_block" is contained, and returns the 
correct RAW block offset from that AD chain's starting block.

UDF AD chains do not HAVE to be in incrementing order either, and you will find 
that some ARCcoS DVDs have the chains backwards. This patch will also fix this 
situation.

This patch mostly changes dvd_udf.c internally, with changes to dvd_reader.c to 
use the new udf_file_t instead of "lbnum". The patch should be transparent to 
software using dvdread. (Apart from no longer receiving GAP blocks, and 
receiving the full end blocks of VOBs larger than 1 AD chain).

This patch is required to allow larger files in UDF format, as the number of AD 
chains increases with filesize. For example, a 4GB file will use 5 AD chains.


-- 
Jorgen Lundman       | <lundman at lundman.net>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dvdread_patch_udf_file2.txt
URL: <http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/attachments/20100528/d634c364/attachment.txt>