[gstreamer-bugs] [Bug 372797] Seek on DVD not performed relative to title

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=372797

  GStreamer | gst-plugins-ugly | Ver: 0.10.4





------- Comment #5 from Jason Gerard DeRose  2006-11-09 23:45 UTC -------
Okay, I see what the problems is.  It seems that ifoOpen() is loading the tmap
for *every* title that has one regardless of the title specified.  I'm not sure
if that is always the case or just something particular about the DVD's I've
been testing (TV serials with several episodes per DVD).  So in the iteration
through src->vts_tmapt->tmap:

  for (i = 0; i < src->vts_tmapt->nr_of_tmaps; ++i) {
    for (j = 0; j < src->vts_tmapt->tmap[i].nr_of_entries; ++j) {
    ...
    }
  }

It always finds the correct time in the first title.  In the case of this
particular DVD, it seems that it might be sufficient to only iterate one deep,
through src->vts_tmapt->tmap[src->title], but I don't know if that will work in
all cases.  Will a single title ever have more than one tmap?

So I guess, in the one tmap per title case:

 * select appropriate tmap (would it always be
src->vts_tmapt->tmap[src->title]?)
 * iterate through tmap.map_ent[] for above tmap

And in the multiple tmap per title case:

 * interate through all tmap, acconting for vts_tmapt->tmap_offset[i]
 * for each above tmap, iterate through tmap.map_ent[]

And as long as I'm at it, it would be much nicer to do all this with an
O(log(n)) algorithm, which from what I'm starting to understand about the tmap
structures, would be cake.

But really, since you know the time unit (vts_tmapt->tmap[i].tmu) and the
number of entries, there is really no reason to do any sort of iteration (or
binary search) through the tmap, is there?

I'll see what I can cook up.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email