> >>+ #ifdef DVD_VIDEO
> >>+ /*
> >>+ * There're rumors claiming that some players assume VIDEO_TS.IFO
> >>+ * to be the first file in VIDEO_TS catalog. Well, it's basically
> >>+ * the only file player has to actually look for, as the whole
> >>+ * video content can be "rolled down" from this file alone.
> >>+ * <[EMAIL PROTECTED]>
> >>+ */
> >>+ if (dvd_video) {
> >>+ if (!strcasecmp (lpnt,"VIDEO_TS.IFO")) return 1;
> >>+ if (!strcasecmp (rpnt,"VIDEO_TS.IFO")) return -1;
> >>+ }
> ...
>
> >I believe that any drive that likes to find more than VIDEO_TS.IFO through
> >UDF will have a more or less complete UDF implementation. For this reason,
> >it seems to be sufficient to make VIDEO_TS.IFO the first entry in VIDEO_TS/
>
> Just a reminder as I believe that there was no answer.....
>
> Do you believe this is OK?
^^^ Well, nobody else has spoken on the matter so I assume the
question is addressed to me personally.
If I believed that having VIDEO_TS.IFO first in the direcory list is
more than sufficient, I would never implement the omitted code. The one
that sorts *all* file entries as they [files] are laid down on media. So
that you didn't have to ask as you basically had my vote/opinion all the
time:-)
But that just *an* opinion. The catch is that I basically can not
provide a *definitive* vote on this matter, as I haven't experienced the
problem *myself*. As already mentioned the only solid argument I can
present in favor of the omitted code is that most DVD-Video titles I've
examined were mastered this way (i.e. *all* file entries were sorted in
order of appearance on the disk, not just VIDEO_TS.IFO). I can add now
that I has an opportunity to examine couple of disks mastered with NERO
and could observe that NERO *also* sorts file entries in the very same
manner (again, *all* file entries in the order of appearance, not just
VIDEO_TS.IFO).
So that I have no choice but to leave the actual/final decision to you!
Unless somebody else speaks up... I myself am fine with VIDEO_TS.IFO
being the only one first as I'm going to keep my eyes open in either
case:-)
Now something not exactly related to this particular issue.
udf.c has following comment:
> - Read performance would probably be improved by placing the File Entry
> for each file just before the file itself, instead of at the beginning
> of the disc. But this would not work for DVD-Video files, which have
> to be stored contiguously. So there would have to be an override
> mechanism to handle this case. I don't know if it's worth the trouble.
DVD-Video files don't have to be stored contiguously. I mean
*theoretically* it's possible to have gaps at least between .IFO and
.VOB, between .VOB and .BUP and between .BUP and .IFO (not sure about
between .VOBs). The real problem here is that practically all programs
preparing .IFO files *assume* that there won't be any gaps between
either of files in question. This means that *if* mkisofs was to inject
gaps between DVD-Video files, then it would also have to fix up the
.IFO/.BUP files! But I'm *not* saying that it should do that! As you
probably would run into a player that wouldn't tolerate such gaps, so
that *in practice* it's simply safer to leave it as it is, i.e. not have
gaps between DVD-Video files. Yes, one can wonder what was my point
then? The point is that comment in question explains "The Right
Thing(TM)" *slightly* incorrectly:-)
Cheers. A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
