Hello list, I prefer to keep libdvdread as a library that can read all versions of UDF filesystem (Up to 2.60) and ISO files. I find it very unattractive to use multiple libraries, one to test if it is a "VIDEO_TS" style UDF, and if not, use a whole different library to handle this type of UDF device/file. (which also interfaces with libdvdcss and/or libaacs) I decided to take a look at libdvdread again, with regards to reading generic UDF devices and ISO images. libdvdread already could handle DVD UDF levels, and I already did some work to enable higher UDF levels like that of blurays. But it generally mostly worked for images created with ImgBurn, and not always for retail blurays or generic UDF. (Linux mkudffs or OsX Newfs_udf). So, with that in mind I made the following changes: * Proper LogVolume parsing, and scan the defined partitions + Handle Sparing Table + Handle Metadata partition; main, mirror and bitmap locations. * Handle ExtFileInfo 250,251,252 (Metadata; Main file, mirror file and bitmap file) * Fix math to find logic block for FSD, based on FSD for metadata not partition start, and/or influenced by Metadata entry. It no longer "loops" looking/hoping for the right TagID. * Fixed "ICBTag.flags&7 = 3" type, "file content data" is stored at AD! (In the same block) The ICBTag logic in dvdread, for flags type = 3, is completely wrong. But this sort of "data compression", to store content in the actual ExtFileInfo block, is probably not used for media volumes normally. * File location (as opposed to Directory location) are from partition.start, not FSD location. (Of course, for DVDs the FSB is at +0 offset.) * Tested IO export functions to (still) work with libdvdcss and libaacs. Now since dvd_udf.c is nearly "unrecognisable" to the original (although backwards compatible), and our past history, I feel it is probably not worth working with patches any more. Perhaps it is better if I simply spin off my own fork of libdvdread. I'm sure we all agree here. Should I take a new library name, dvdread.plus or dvdreadX or libudfread, something, or just different version strings? Let me know what You think so we can come to something everyone is happy with. Lund Optional TODOs. * If metadata-mail-file fails, use metadata-mirror-file. * Ignores freetable bitmap too, but then, it is a readonly library -- 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 Fri, Jan 13, 2012 at 02:40:22PM +0900, Jorgen Lundman wrote :
Now since dvd_udf.c is nearly "unrecognisable" to the original (although backwards compatible), and our past history, I feel it is probably not worth working with patches any more. Perhaps it is better if I simply spin off my own fork of libdvdread. I'm sure we all agree here.
Why not create a small library or just a set of headers to just read UDF volumes? Something similar to libiso9660(, but actually portable). And see if other libraries can use it, like libdvdread or libbluray... Using libdvdread to read Blu-Ray hierarchies seems a bit weird, as a concept, but also since it would take with it, some of the DVD cruft; and, sorry to say, many of the crashes... Best regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
Jean-Baptiste Kempf wrote:
Why not create a small library or just a set of headers to just read UDF volumes? Something similar to libiso9660(, but actually portable). And see if other libraries can use it, like libdvdread or libbluray...
DVDs are UDF, all first 8 revisions. Blurays are just 4 more revisions (or whatever the revisions numbers are). So out of the 6100 lines in dvd_udf.c, I really only needed to add another 30 lines. To make a whole new library, to be able to read all UDF filesystems, when 99% of the sources will be identical seems crazy. In your fine program, do you really want to have to cycle through "more than one" UDF library to be able to read an ISO? Now the libdvdread library was only written for DVDs (hence the name) and took some shortcuts. I have spent time to fix these problems, add more error checking and extend it to be more of a libudfread. But it also has the ability to change IO methods. In particular, to use libdvdcss (and I added libaacs). So all that would have to be duplicated (or added if you went with a whole new UDF library).
Using libdvdread to read Blu-Ray hierarchies seems a bit weird, as a concept, but also since it would take with it, some of the DVD cruft; and, sorry to say, many of the crashes...
What is weird, is writing a UDF reading library, then hamstringing it to ONLY be able to read "one specific kind" of UDF, ie, DVDs. Then doing a poor job is actually being UDF compliant, so that whenever they add new "anti piracy" hacks, like corrupting the UDF structure, libdvdread falls over. :) I tried to play a bluray.ISO with VLC the other day, and it couldn't. If only you had used my libdvdread and it would have just worked :) 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 Fri, Jan 13, 2012 at 05:49:17PM +0900, Jorgen Lundman wrote :
DVDs are UDF, all first 8 revisions. Blurays are just 4 more revisions (or whatever the revisions numbers are). So out of the 6100 lines in dvd_udf.c, I really only needed to add another 30 lines.
Great.
To make a whole new library, to be able to read all UDF filesystems, when 99% of the sources will be identical seems crazy. In your fine
Maybe I am wrong, but dvdread is a bit more than dvd_udf.c.
I tried to play a bluray.ISO with VLC the other day, and it couldn't. If only you had used my libdvdread and it would have just worked :)
Sure, libbluray does not support .iso. But I would prefer to use your new udf code in libbluray directly, than link libbluray to libdvdreadX Best regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
To make a whole new library, to be able to read all UDF filesystems, when 99% of the sources will be identical seems crazy. In your fine
Maybe I am wrong, but dvdread is a bit more than dvd_udf.c.
Absolutely correct, but I only needed to change dvd_udf.c to make it fully UDF compatible. Everything else remains the same.
Sure, libbluray does not support .iso. But I would prefer to use your new udf code in libbluray directly, than link libbluray to libdvdreadX
So then, you WOULD prefer if you have 2 UDF reading libraries, one with libbluray for all UDFs, as well as libdvdread with libdvdnav? That is what you are saying, rather than libbluray using libdvdread for all UDF access. -- 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 Fri, Jan 13, 2012 at 05:59:03PM +0900, Jorgen Lundman wrote :
So then, you WOULD prefer if you have 2 UDF reading libraries, one with libbluray for all UDFs, as well as libdvdread with libdvdnav?
I don't understand what you mean... I would prefer one UDF reading codebase.
That is what you are saying, rather than libbluray using libdvdread for all UDF access.
Yes, I don't think it is a good idea for libbluray to use libdvdread, because of the reasons already said before. Best regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
I don't understand what you mean... I would prefer one UDF reading codebase.
Then I would put you down as someone supporting the extra UDF code. :)
Yes, I don't think it is a good idea for libbluray to use libdvdread, because of the reasons already said before.
That it has "DVD cruft" seems beneficial in some cases like when using libdvdnav, but I hear you about the crashes. That is another reason I decided to learn UDF and re-do the guts of libdvdread. -- 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 Fri, Jan 13, 2012 at 07:38:21PM +0900, Jorgen Lundman wrote :
I don't understand what you mean... I would prefer one UDF reading codebase.
Then I would put you down as someone supporting the extra UDF code. :)
Consider me as someone who would prefer UDF code to be splitted or at least being easier to integrate into another project (a header and a few .c)
Yes, I don't think it is a good idea for libbluray to use libdvdread, because of the reasons already said before.
That it has "DVD cruft" seems beneficial in some cases like when using libdvdnav, but I hear you about the crashes. That is another
Unfortunately, dvdnav/dvdread are one of the biggest sources of crashes of VLC (around 50k crashes/day); but the situation has improved dramatically lately :) There is also the question of the licence. Libbluray is LGPL, not the UDF code of dvdread. Best regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
participants (2)
-
Jean-Baptiste Kempf -
Jorgen Lundman