Re: [VCDImager Bugs/Devel] vcdimager progress info...

[Matto Marjanovic]

 >> quick fix unless the new mjpeg tools get released: just remove the last
 >> 2324 bytes from that mpeg file...
 >
 >Should now be fixed in CVS.  No error messages when applied to freshly muxed 
 >system stream. I'll be uploading a new tarball to sourceforge tonight.

Cool, thanks.  Now, I can once again try compiling from CVS.  (I've been
 using the binaries from Arne Schirmacher's dvgrab site --- I can actually
 go from DV camcorder --> Video CD now.  Amazing.)

 >ASIDE: Anyone remind what mpeg_encode in Gimp's GAP tools actually is?
 >Is it the latest mjpegtools in a script?

There's a choice:  
   o for MPEG1, mpeg_encode from the ucbmpeg package.
   o for MPEG2, mpeg2encode from "http://www.mpeg.org/MSSG";, the original,
                 which no longer seems to bear any relation (i/o-wise) to
                 mjpegtools' mpeg2enc.

Do you know if anyone has anything in the works to go from GAP -> mpeg2enc?
That would make it a lot easier to create tracks for PBC menus.

 >> >   - mpeg_encode used to create the video stream
 >> >   - toolame used for audio stream
 >> >   - vcdmplex used to create system stream (and it bitched about some
 >--------^
 >
 >This is not the mjpegtools mulitplexer... but it sounds like Rainer made the 
 >same (wrong) guess as me about stream end markers ;-)

mjpegtools' mplex has the annoying feature of creating a system stream as
 long as the longest input stream, as opposed to the shortest.  For testing,
 I was just trying to use any old audio track --- I had a 3 second video
 stream and 60 second audio stream, and vcdmplex is kind (dumb?) enough to
 create a 3 second system stream.

 >> >      potential buffer underruns; i guess i need to play with bitrates?)
 >
 >Buffer under-runs occur when the (peak) bit-rate required for timely delivery 
 >of the video exceeds that available in the multiplexed stream.  Fix: reduce 
 >the rate you're encoding at or increase the mulitplexed data rate.  There is 
 >possibly some tuning required to mpeg2enc's rate control.  In CVS I've set it
 >slightly more conservatively (the penalty is a slight decrease in utilisation
 >overall).

Yep.  The conclusion I've come to is that UCB's mpeg_encode seems to just be
 a pretty sucky MPEG encoder, since it misses the bitrate parameters even for
 quite simple text-graphics animations.

-matt m.