Ralph Glasstetter wrote:
>>I think index::indexnr() must be the reason. Frames are actually
>>numbered twice: in file order and in display order. In a regular GOP
>>(with IBBPBB... frames), the sequence numbers are 2-0-1-5-3-4-... due to
>>MPEG's frame reordering rules. Therefore, the display index of the I and
>>P frames is higher than the file index, while it's just the opposite for
>>B frames. And what the slider shows is the display index, not the file
>>index. dvbcut::pictures, on the other hand, is based on the file index,
>>as far as I can tell.
> 
> 
> Hmmmm,... does this really explain why the largest visible display index (an 
> I-frame)
> is SMALLER than 'realpictures' ( =largest usable file index = total number of 
> frames - skipped frames)
> ...?!?

Maybe it also is vice versa - this part of the code is almost impossible
to understand. Anyway, the (display/slider) index of the last frame
should be exactly index::realpictures-1 because we're counting from 0.

Michael.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
DVBCUT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dvbcut-user

Reply via email to