Re: libdvdread: about pgc_command_tbl_t in ifo_read.c and ifo_types.h

H}kan Hjort wrote:

>Sun Apr 04 2004, Yi-Shin Li wrote:
>  
>
>>Dear All,
>>
>>The data structure pgc_command_tbl_t.zero_1 (line# 266) of
>>ifo_types.h should actually be "last_byte". Am I correct?
>>
>>    
>>
>It would indeed seem so.  We don't really use all the info in
>the IFO files, and the 'last_byte' info is not of much use...
>It should always be equal too (or I guess larger than)
>PGC_COMMAND_TBL_SIZE + total * COMMAND_DATA_SIZE
>where total is the total number of commands (pre+post+cell).
>
>Normaly I have CHECK_ZERO() asserts on all the 'unused' entries
>but obviously missed this one.  All the other last_byte entries
>are 32bit fields also...  
>  
>
Per http://dvd.sourceforge.net/dvdinfo/pgc.html#cmd , the 4th
entry of pgc_command_tbl_t should be "uint16_t last_byte" instead
of "uint16_t zero_1". I've dumped the IFO of MALENA; I think it
supports my point.

Since I don't have DVD-VIDEO spec on my hand, I am not positive
about this. -ysli

> 
>  
>
>>If so, there should be a
>>B2N_16(cmd_tbl->last_byte);
>>in ifoRead_PGC_COMMAND_TBL() of ifo_read.c
>>
>>    
>>
>Adding that should not pose a problem.  I hope one is using the
>zero_1 identifier though.  Anonymous unions would have come in
>handy here.
>
>  
>
>>This might be a minor bug because I don't have problem using
>>xine with it.
>>
>>    
>>
>No, the relevant data is still read as it shoul be, only a simple
>validity check is missed (and for applications that are intrested
>in the last_byte field).
>
>/H嶡an
>  
>