Re: [VCDImager] vcdimager dies with error

[Herbert Valerio Riedel]

On Fri, 18 May 2001, Mike wrote:

> Hi,

> Sometimes when I generate an MPEG-2 video stream to feed to VCDImager, it
> generates the following error:

> --DEBUG: initializing libvcd 0.6.2 [linux-gnu/i586]
>    INFO: scanning mpeg track #0 for scanpoints...
> ++ WARN: mpeg stream will be padded on the fly -- hope that's ok for you!
> --DEBUG: timecode seen smaller than max timecode... (54.934268 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (55.433767 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (55.934268 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (56.433767 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (56.934268 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (57.433767 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (57.934268 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (58.433767 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (58.934268 < 36487.868535)
> --DEBUG: timecode seen smaller than max timecode... (59.433767 < 36487.868535)
> --DEBUG: playing time 36488.335669
> --DEBUG: track# 0's detected playing time: 36488.34 seconds
>
> vcdimager: vcd.c:612: _finalize_vcd_iso_track: Assertion 
> `_vcd_salloc_get_highest (obj->iso_bitmap) + 1 == 225' failed.



> Now, the video clip in question is not actually 36488 seconds long, it's
> only 60 seconds.  I did find the following at line 612 in vcd.c:
>
>   assert (_vcd_salloc_get_highest (obj->iso_bitmap) + 1 == 225); /* fixme --
>                                                                 momentary
>                                                                 limitation */
>

> I haven't gone through enough of the code to understand what's going on at
> this point.  Can anybody shed some light as to what this limitation is,
> why my MPEG files *SOMETIMES* cause this, why vcdimager thinks my playing
> time is 36488 seconds, and if any of this is related?
that 'limitation' has gone away in the latest development source, it was
just an assumption, to make implementation easier in the 0.6.x series...

the playing time is determined by looking at the timecodes in the GOP
headers, and taking the largest and smallest seen ones... so if there are
some bogus values, the calculation breaks...
(I will switch to PTS based calculation in the development series, which
should be more accurate)

and yes, they are related, since if the playing time is _too_ large, the
search.dat file grows that much, that the boundary assumption gets
broken...

-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: address@hidden       /    Finger address@hidden for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142