[DVDnav-discuss] dvdnav_sector_search()

[Marcel J.E. Mol]

No interest?

I found another issue. When a dvd has BLOCK_TYPE_ANGLE_BLOCK cells
dvdnav_sector_search() may end up doing the wrong calculations.
It starts by calling dvdnav_get_position() which calculates the 
current position by adding up the sectors per cell.
Then dvdnav_sector_search() tries to determine the a proper vobu sector
by again looping through the list of cell and using sectors for each cell.
BUT it now it skips the BLOCK_TYPE_ANGLE_BLOCK cells (probably because the
sector ranges overlap the previous cell ...). 
So when having BLOCK_TYPE_ANGLE_BLOCK cells the get_position will
gradually deviate from sector search.

For now I changed dvdnav_get_position() to take angle blocks into account:

--- src/searching.c.org 2012-09-02 17:28:11.799419113 +0200
+++ src/searching.c     2012-09-02 17:28:18.274498770 +0200
@@ -530,6 +530,8 @@
   *len = 0;
   for (cell_nr = first_cell_nr; cell_nr <= last_cell_nr; cell_nr++) {
     cell = &(state->pgc->cell_playback[cell_nr-1]);
+    if(cell->block_type == BLOCK_TYPE_ANGLE_BLOCK && cell->block_mode != BLOCK_MODE_FIRST_CELL)
+        continue;
     if (cell_nr == state->cellN) {
       /* the current sector is in this cell,
        * pos is length of PG up to here + sector's offset in this cell */



Regards,

-Marcel

On Tue, Aug 28, 2012 at 12:32:47PM +0200, Marcel J.E. Mol wrote:
> Hi List,
> 
> I'm exploring the dvdread/dvdnav libraries to optimise dvd playback on
> the OpenPli stb receivers. So first of all maybe openpli could be added
> to the list of 'related projects'...
> 
> OpenPli uses the dvdnac_sector_search() function to forward/backward skip.
> It firsts uses dvdnav_get_position(), does some calcs and 
> calls dvdnav_sector_search with SEEK_SET.
> But dvdnav_sector_search() already does a call to dvdnav_get_posisition().
> so I like to use SEEK_CUR instead of SEEK_SET.
> However the offset parameter to dvdnav_sector_search is an uint64_t.
> This is no problem for forward skips, but backword skip won't work...
> Is there a reason for the uint64_t? Otherwise I would suggest changing
> it to int64_t so we can pass negatve values for offset.
> 
> thanks
> 
> -Marcel
-- 
     ======--------         Marcel J.E. Mol                MESA Consulting B.V.
    =======---------        ph. +31-(0)6-54724868          P.O. Box 112
    =======---------        marcel at mesa.nl                 2630 AC  Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
 They couldn't think of a number,           Linux user 1148  --  counter.li.org
    so they gave me a name!  -- Rupert Hine  --  www.ruperthine.com