[DVDnav-discuss] [PATCH] "dvdnav_jump_to_sector" as an alternative to "dvdnav_time_search" (Overview: Source to follow)

[gnosygnu]

Thanks for the feedback! I reply inline below.

On Fri, Nov 11, 2011 at 1:07 PM, Roger Pack <rogerdpack2 at gmail.com> wrote:
>> Currently, dvdnav_time_search is marked "FIXME: right now, this
>> function does not use the time tables but interpolates only the cell
>> times". This method is usually inaccurate: it interpolates using
>> sectors, but one sector does not equal one fixed unit of time. For
>> example, if there is a 10:00 cell and the cell is 1000 sectors long,
>> it assumes that 5:00 is at sector 500. Jumping to sector 500 may
>> actually jump instead to 5:12.
>>
>> My patch jumps to a time using the time map and the vobu address map.
>> I placed it in a new function called "dvdnav_jump_to_sector"
>
> Ok I tried out the new search functionality (in mplayer, as a drop in
> replacement: https://gist.github.com/1358679)
>
> It works well.  Lightning-sharp DVD seeking accuracy.  Thanks!

Glad to hear it! It's good to have confirmation.

> Mplayer "used" to sometimes advance by 15 seconds, when it requested
> it to go forward 10 (or sometimes, it would even go *backward* when
> you attempting to go 10 seconds forward--weird)

I agree. I've noticed strange variances as well.

For example, on one disc, a seek time of 4:53 took me to 4:44 (jumping
*backwards* by 9 seconds). On that same disc, 10:51 took me to 11:16
(jumping forwards by *25* seconds)

> this fixes it right
> up.  Seeking is precise now.
> That being said, it seems to "jerk" (take a little bit longer) when
> seeking.  But I'm ok with that for accuracy sake :) (maybe it could be
> optimized to be faster?)

Okay, I did some investigation, and I have a theory. Are you watching
the DVD directly off the optical disc? For frame of reference, I watch
my DVDs after I've copied them to my local hard drive. There is no
perceptible delay in this setup. However, when I tried seeking off an
optical disc just now I see something that is definitely a second. I
also hear the disc spin up for each seek.

If so, this may be related to the time map. The current reference to
the tmap is null (specifically: this->vm->vtsi->vts_tmapt). I had to
call ifoOpen to get an ifo with a valid time map. It looks like like
calling this proc for each seek becomes noticeable on an optical disc.

I have a HACK that re-loads the ifo once, and caches it in memory for
future seeks (it actually overwrites the current ifo which I hope is
okay). Please try it whenever you get a chance and let me know if it
addresses your issue. You should still see a delay the first time you
do a seek on a disc, but future seeks on that disc should be
imperceptible.

The best fix is to avoid the first delay. However, that requires
getting this->vm->vtsi->vts_tmapt to be not null. I think that
requires changing the ifo load in vm.c, which I'm wary of doing.....

> For the VLC dev's, this maybe helpful in clearing up
> http://trac.videolan.org/vlc/ticket/4 et al.
>
> Some code feedback:
> I think method documentation for "public" api's goes in the .h file.

Thanks. I didn't know that. I moved the documentation for that public
function to the .h file.

> Also I think the method should be declare not at the bottom of the .h
> file but in the middle :)

Good point. I moved the method to just underneath the time_search method.

> Also why not use uint64_t like dvdnav_time_search does?
> And maybe return value for dvdnav_jump_to_sector_by_time should be
> dvdnav_status_t ?

Thanks for the catch. FWIW, I do use uint64_t for time everywhere
else: I just forgot to do it for the main one. I've changed both the
uint64_t and the dvdnav_status_t in the upcoming patch as well.

> Thanks.
> -roger-
> _______________________________________________
> DVDnav-discuss mailing list
> DVDnav-discuss at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
>