Thanks for the feedback! I reply inline below. On Fri, Nov 11, 2011 at 1:07 PM, Roger Pack <[email protected]> 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 > [email protected] > https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss > _______________________________________________ DVDnav-discuss mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
