good afternoon,
background:
==========
I'm trying to burn a video-dvd using udf. for testing, I used
(1) a loopback image (2) a DVD-Rewriteable (3) a write-only dvd.
all tests showed the same behaviour: "it does not work" ;-)
using udf, I'm not able to play video-dvds, neither (1) via software
("ogle") nor (2) via a dvd-player connected to a TV.
on the other hand, using iso9660 (via mkisofs -dvd-video) , ogle and
the dvd-player work and display my small testmovie.
what exactly does not work:
==========================
the dvd-player always complains about "no disc inserted", just to
mention, anyway, the dvd-player is not a practicable debugging device ;-)
the better debugging source is libdvdread. ogle complains that it
cannot find "VIDEO_TS.IFO", allthough it _is_ there. I used the "printf"
-debugger on libdvdread and found that it behaves differently when
using a commercial DVD, opposed to the loopback-image I formatted with
mkudffs.
how to reproduce the "bug":
==========================
well, I'm not 100% sure if the problem exists because I don't understand
how to use all these software (with the right options, in particular when
using mkudffs) or if there's really a bug.
(1) I created an udf-formated loopback image without extended file entries.
"Why no extened file entries?", I hear you ask. Answer: because libdvdread
doesnt like them, I'm afraid. Have a look in
libdvdread/dvdread/dvd_udf.c, look for "UDFMapICB", somewhere around
line 500. The do { } while loop checks for TagID 261 and ignores all
other Tags. TagID 261 means "TAG_IDENT_FE", and when using "EFE"s, then
UDFMapICB() will always see TagID = 0x10a (TAG_IDENT_EFE).
Since I'm not really sure if the problem is related to FE vs. EFE, I
used a filesystem with EFEs one time, and one without another time: both
file systems showed the same behaviour (="VIDEO_ITS.IFO not found")
ok, here we go:
bash-2.05# dd if=/dev/zero of=24M bs=1M count=24
24+0 records in
24+0 records out
bash-2.05# mkudffs 24M
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=16, type=PVDS
start=273, blocks=1, type=LVID
start=274, blocks=11757, type=PSPACE
start=12031, blocks=1, type=ANCHOR
start=12032, blocks=239, type=USPACE
start=12271, blocks=16, type=RVDS
start=12287, blocks=1, type=ANCHOR
or:
bash-2.05# mkudffs --noefe 24M
I also used various other options like --bridgea --media-type etc.,
but it didn't help.
(2) next I created the dvd-structure using "dvdauthor":
bash-2.05# mount -o loop 24M /mnt
bash-2.05# dvdauthor -o /mnt -x foo.xml
DVDAuthor::dvdauthor, version 0.6.11.
...
INFO: dvdauthor creating table of contents
INFO: Scanning /mnt/VIDEO_TS/VTS_01_0.IFO
...
"foo.xml" just contains:
bash-2.05# cat foo.xml
<dvdauthor>
<vmgm />
<titleset>
<titles>
<pgc>
<vob file="foo.mpg" />
</pgc>
</titles>
</titleset>
</dvdauthor>
"foo.mpg" is just a sequence of random pictures converted from /dev/urandom
with mplex, mpeg2enc, et al.
(3) to be sure the data has been written to the image, I unmount it (shouldn't
be neccessary, right?), and then ogle will fail and say:
bash-2.05# ogle 24M
libdvdread: Can't open file VIDEO_TS.IFO.
ERROR[ogle_nav]: faild to read VIDEO_TS.IFO
DVDSetDVDRoot:: Root not set
but:
bash-2.05# find /mnt -name VIDEO_TS.IFO
/mnt/VIDEO_TS/VIDEO_TS.IFO
bash-2.05# ls -li /mnt/VIDEO_TS/VIDEO_TS.IFO
1097 -rw-r--r-- 1 root root 6144 Jun 5 14:14
/mnt/VIDEO_TS/VIDEO_TS.IFO
in fact, the file *is* there. or, to be a bit more precise: libdvdread cannot
find the file, while the udf-fs driver does. of course it does - it should
be able to find files it has created itself (via dvdauthor in (2)).
the printf debugger:
===================
Since I'm still not used to using fullscreen-debuggers, I've added some
printf()s to libdvdread/dvdread/udf.c and saw that a particular length-field
is always zero when using the image, and non-zero using a commercial dvd.
here's what I get:
commercial DVD:
# ogle /dev/hdc
> UDFFindFile filename=/VIDEO_TS/VIDEO_TS.IFO
UDFFindFile 841
> UDFMapICB
> UDFFileEntry
ad->Length=0
L_EA=132 L_AD=8
before switch: ad->Length=0
flags=0230
after switch: ad->Length=292
< UDFFileEntry, ad->Length=292
howebrew loopback image:
bash-2.05# ogle ~/src/24M
libdvdread: Using libdvdcss version 1.2.9 for DVD access
> UDFFindFile filename=/VIDEO_TS/VIDEO_TS.IFO
UDFFindFile 841
> UDFMapICB
> UDFFileEntry
ad->Length=0
L_EA=0 L_AD=188
before switch: ad->Length=0
flags=0003
after switch: ad->Length=0
< UDFFileEntry, ad->Length=0
527: return 1
872: File.length=0 token=VIDEO_TS
> UDFScanDir (1) Dir.Length=0 (2) FileName=VIDEO_TS
UDFScanDir:592
enter while: Dir.Length=0
X UDFFindFile 880
"the X UDFFindFile" means that libdvdread did not find the file.
you'll probably notice that Dir.Length remains zero always, which is the
reason that UDFFindFile fails.
one (big?) difference is that "L_EA=132 L_AD=8" in the first case
and "L_EA=0 L_AD=188". I don't know if this should be that way. I've just
downloaded ecma-167 and then decided to file this report without further
looking into the problem.
conclusion:
==========
the udf-fs-driver and libdvdread (and my dvd-player as well) seem to have a
different idea on how to interpret udf. I can only guess why (= I have no
proof).
or is the source of the problem rather myself and I'm missing a crucial
option?
kind regards,
h.rosmanith
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
