[DVDnav-discuss] [PATCH] "dvdnav_jump_to_sector" as an alternative to "dvdnav_time_search" (REV 5: combined args to structs)

[gnosygnu]

On Thu, Apr 19, 2012 at 3:50 AM, Joakim Plate <elupus at ecce.se> wrote:
> The first data at a vob unit is a NAV packet. This contains time
> information for requested vob unit, AS WELL as back time skip
> information both back and forward in time, contained in the vobu_sri_t
> structure.

Ok. Thanks. This helps.

> Doing a read of this single sector won't hurt much I think
> (you are going to read it the moment you request playback anyway).

One other note. The time map is not precise, and my methodolgy of
interpolating VOBUs may be less so.

In theory, the time I get should be within 1 sector of the actual
time. However, it could be 2+ sectors away. My concern is that I may
end up having to read multiple sectors and this would be noticeable
from a performance perspective.

> I think a tmap search to a vobunit close to the requested time, read
> NAV packet, use the info in vobu_sri_t to figure out how to get a more
> exact location jump there is what is the best approach.

I agree. This is the best approach. I'll look at the vobu_sri_t later
this week, and see what can be done.

> But i'd like to add that i think it's better we add the parameter to
> the API even if it's currently won't be implemented. That way the API
> won't need to be changed to add support.

I have no objections. How about the following?:

An int32_t parameter called "mode" which can be any of the following

0: normal. same as current behavior
1: always jump to a time > than requested time. For example, if time
"15.00" is requested, and the nearest vobus are "14.90" and "15.40",
pick "15.40" (even though "14.90" is closer)
-1: always jump to a time < than requested time. Similar to above, but
pick "14.90"