Hello list, So as a status update to my progress. I think my patching is probably quite different from your average libdvdread user, so there would probably too much work to include them in mplayers repository. But they are all available on my public CVS should someone else be seeking the same information. I have found the following patches needed; 1. Back-ported the DVDFileStat() functions so I can get VOB filesizes more easily. 2. Added ExtFileInfo (262) support for UDF2.50 3. Added Filetype 250, which seems to be a homegrown re-direct block, this enables libdvdread to process UDF2.50 images. 4. Unfortunately, libdvdread developers cheated an used "struct AD" both for AD use, and to carry back file-size information. AD's Location (number of blocks) is correctly 32bits, but filesizes in UDF are 64bit. Since DVD images are always <= 1GB, this has not been a problem so far. I updated "struct AD" to also have a 64bit value for filesize, which is not the correct solution, but the one with the least changes. 5. Unfortunately, libdvdread developers cheated when reading AD's from FileInfo data. It will parse them all, and return the last one found. Again, because DVDs are <= 1GB, there is only one AD chained and hence, no problem. For UDF2.50, and larger files, I needed extra patching to fetch the correct chain. Not entirely sure how best to fix this yet. 6. Since I can't really parse BD-ISO with "domain, title, part", I implemented opendir/readdir/closedir API functions. I used POSIX extension dt_type for quick type testing, and hacked in dt_filesize to save on stat() API calls. But perhaps, stat() should also be implemented. 7. Added DVDOpenFilename() to allow opening of a direct filename instead of "domain, title, part". 8. DVDFileSize() will return very strange values, and I find it hard to believe that it will ever return the correct number. (Generally only used for .IFO files). Anyone actually used it? 9. Added dvd_input methods for popen()ing "unrar" allowing for direct ISO access inside RAR storage container. That is all for now. Lund -- Jorgen Lundman | <lundman@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)
Il giorno gio, 18/09/2008 alle 12.52 +0900, Jorgen Lundman ha scritto:
Hello list,
So as a status update to my progress.
I think my patching is probably quite different from your average libdvdread user, so there would probably too much work to include them in mplayers repository. But they are all available on my public CVS should someone else be seeking the same information.
I have found the following patches needed;
1. Back-ported the DVDFileStat() functions so I can get VOB filesizes more easily.
2. Added ExtFileInfo (262) support for UDF2.50
3. Added Filetype 250, which seems to be a homegrown re-direct block, this enables libdvdread to process UDF2.50 images.
4. Unfortunately, libdvdread developers cheated an used "struct AD" both for AD use, and to carry back file-size information. AD's Location (number of blocks) is correctly 32bits, but filesizes in UDF are 64bit. Since DVD images are always <= 1GB, this has not been a problem so far. I updated "struct AD" to also have a 64bit value for filesize, which is not the correct solution, but the one with the least changes.
5. Unfortunately, libdvdread developers cheated when reading AD's from FileInfo data. It will parse them all, and return the last one found. Again, because DVDs are <= 1GB, there is only one AD chained and hence, no problem. For UDF2.50, and larger files, I needed extra patching to fetch the correct chain. Not entirely sure how best to fix this yet.
6. Since I can't really parse BD-ISO with "domain, title, part", I implemented opendir/readdir/closedir API functions. I used POSIX extension dt_type for quick type testing, and hacked in dt_filesize to save on stat() API calls. But perhaps, stat() should also be implemented.
7. Added DVDOpenFilename() to allow opening of a direct filename instead of "domain, title, part".
8. DVDFileSize() will return very strange values, and I find it hard to believe that it will ever return the correct number. (Generally only used for .IFO files). Anyone actually used it?
9. Added dvd_input methods for popen()ing "unrar" allowing for direct ISO access inside RAR storage container.
That is all for now.
Lund
and the patch is...?
and the patch is...?
http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/
5. Unfortunately, libdvdread developers cheated when reading AD's from FileInfo data. It will parse them all, and return the last one found. Again, because DVDs are <= 1GB, there is only one AD chained and hence, no problem. For UDF2.50, and larger files, I needed extra patching to fetch the correct chain. Not entirely sure how best to fix this yet.
I decided to do this properly. Previously, libdvdread developers return "lb_start" block number from UDFFindFile(), and the users of the API assumes all the file-blocks are contiguous. I have changed it so dvd_ufd.c's UDFFindFile return a "UDF_FILE" opaque type for dvd_read.c to use instead, and a new UDFFileBlockPos() that translates a file's offset, to actual block number, taking into account of the AD chains (which have gaps it, as it turns out). This completes my task for now, in that my player will happily list the contents of BS-ISO images, and play the m2ts files within. Useless logs follows for amusement. ------------------- # ./disc_ls testfile-bd5.iso /BDMV Found '/BDMV' at 326 (size 588) /BDMV: . (type 3) size 152 /BDMV: AUXDATA (type 3) size 40 /BDMV: BACKUP (type 3) size 332 /BDMV: BDJO (type 3) size 40 /BDMV: CLIPINF (type 3) size 100 /BDMV: index.bdmv (type 5) size 526 /BDMV: JAR (type 3) size 40 /BDMV: META (type 3) size 40 /BDMV: MovieObject.bdmv (type 5) size 278 /BDMV: PLAYLIST (type 3) size 100 /BDMV: STREAM (type 3) size 100 # ./disc_get testfile-bd5.iso /BDMV/STREAM/00001.m2ts libdvdread: Encrypted DVD support unavailable. UDFPartiton found Number 0, Contents , start-end 288-2291200 UDFLogVolume: We found 2 partitions. libdvdread: read block 289 TagID 266 libdvdread: reading AD chain 0 libdvdread: redirect block filetype 250 found at block 289, for location +32 libdvdread: read block 321 TagID 256 libdvdread: reading block 323 TagID 266 libdvdread: reading AD chain 0 libdvdvread: File block 0 -> 320 (chain 3 + offset 0 : 1572861) Found '/' at 320 (size 152) libdvdvread: File block 0 -> 320 (chain 3 + offset 0 : 1572861) libdvdvread: File block 0 -> 320 (chain 3 + offset 0 : 1572861) libdvdread: reading block 325 TagID 266 libdvdread: reading AD chain 0 libdvdread: reading block 337 TagID 266 libdvdread: reading AD chain 0 libdvdread: reading block 355 TagID 266 libdvdread: reading AD chain 0 libdvdread: reading AD chain 1 libdvdread: reading AD chain 2 libdvdread: reading AD chain 3 libdvdread: reading AD chain 4 Openfile said 0x100500 Size 4691957760 libdvdvread: File block 0 -> 438 (chain 0 + offset 0 : 524287) ... libdvdvread: File block 520000 -> 520438 (chain 0 + offset 520000 : 524287) libdvdvread: File block 530000 -> 530438 (chain 1 + offset 5713 : 524287) ... -- Jorgen Lundman | <lundman@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)
On Friday, 19 September 2008 at 09:14, Jorgen Lundman wrote:
and the patch is...?
http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/
That's no patch, that's a space station^W^W^Wan old version. ;) Could you please send a svn diff'd patch against current SVN?
5. Unfortunately, libdvdread developers cheated when reading AD's from FileInfo data. It will parse them all, and return the last one found. Again, because DVDs are <= 1GB, there is only one AD chained and hence, no problem. For UDF2.50, and larger files, I needed extra patching to fetch the correct chain. Not entirely sure how best to fix this yet.
I decided to do this properly.
Previously, libdvdread developers return "lb_start" block number from UDFFindFile(), and the users of the API assumes all the file-blocks are contiguous.
I have changed it so dvd_ufd.c's UDFFindFile return a "UDF_FILE" opaque type for dvd_read.c to use instead, and a new UDFFileBlockPos() that translates a file's offset, to actual block number, taking into account of the AD chains (which have gaps it, as it turns out).
This completes my task for now, in that my player will happily list the contents of BS-ISO images, and play the m2ts files within.
Useless logs follows for amusement.
Nice. Thank you for your work. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
That would be a lot of work*, and usually my patches are just ignored (not here, other work) but if it was wanted, it could be done. It should be only one version behind, I grabbed your tarball as soon as you released it. * not really, just repetitive. ;) Lund Dominik 'Rathann' Mierzejewski wrote:
On Friday, 19 September 2008 at 09:14, Jorgen Lundman wrote:
and the patch is...?
http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/
That's no patch, that's a space station^W^W^Wan old version. ;) Could you please send a svn diff'd patch against current SVN?
5. Unfortunately, libdvdread developers cheated when reading AD's from FileInfo data. It will parse them all, and return the last one found. Again, because DVDs are <= 1GB, there is only one AD chained and hence, no problem. For UDF2.50, and larger files, I needed extra patching to fetch the correct chain. Not entirely sure how best to fix this yet.
I decided to do this properly.
Previously, libdvdread developers return "lb_start" block number from UDFFindFile(), and the users of the API assumes all the file-blocks are contiguous.
I have changed it so dvd_ufd.c's UDFFindFile return a "UDF_FILE" opaque type for dvd_read.c to use instead, and a new UDFFileBlockPos() that translates a file's offset, to actual block number, taking into account of the AD chains (which have gaps it, as it turns out).
This completes my task for now, in that my player will happily list the contents of BS-ISO images, and play the m2ts files within.
Useless logs follows for amusement.
Nice. Thank you for your work.
Regards, R.
-- Jorgen Lundman | <lundman@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)
On Friday, 19 September 2008 at 14:23, Jorgen Lundman wrote:
Dominik 'Rathann' Mierzejewski wrote:
On Friday, 19 September 2008 at 09:14, Jorgen Lundman wrote:
and the patch is...?
http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/
That's no patch, that's a space station^W^W^Wan old version. ;) Could you please send a svn diff'd patch against current SVN?
That would be a lot of work*, and usually my patches are just ignored (not here, other work) but if it was wanted, it could be done.
Nico expressed interest when you first mentioned this last month, so yes, I believe it is wanted. Also it'd save *us* the work.
It should be only one version behind, I grabbed your tarball as soon as you released it.
4.1.2 is 5 months old. In the meantime, libdvdread was split from libdvdnav into separate directory, so please checkout http://svn.mplayerhq.hu/dvdnav/trunk/libdvdread/ and send a patch against that. Regards, R. PS. I've fixed your quoting this time. Please don't make me do that again. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
4.1.2 is 5 months old. In the meantime, libdvdread was split from libdvdnav into separate directory, so please checkout http://svn.mplayerhq.hu/dvdnav/trunk/libdvdread/ and send a patch against that.
PS. I've fixed your quoting this time. Please don't make me do that again.
Thank you, this tells me all I need to know. Lund -- Jorgen Lundman | <lundman@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)
On Mon, Sep 22, 2008 at 11:27:36AM +0900, Jorgen Lundman wrote:
4.1.2 is 5 months old. In the meantime, libdvdread was split from libdvdnav into separate directory, so please checkout http://svn.mplayerhq.hu/dvdnav/trunk/libdvdread/ and send a patch against that.
PS. I've fixed your quoting this time. Please don't make me do that again.
Thank you, this tells me all I need to know.
Are you complaining about the quoting habits expected around here? Diego
On Friday 19 September 2008 14:23:30 Jorgen Lundman wrote:
That would be a lot of work*, and usually my patches are just ignored (not here, other work) but if it was wanted, it could be done.
they aren't just ignored: it's just that I have very little time and my horrible headaches have come back in full force. I didn't abandon the code, I'll be more committed to reviewing patches when I have more time. In the meantime the repository is available to the other guys: I didn't barricade the code :)
participants (4)
-
Diego Biurrun -
Dominik 'Rathann' Mierzejewski -
Jorgen Lundman -
Nico Sabbi