> 1. Grab video > mp1e -v -G 352x240 -s 352x240 -b 1.152 -a 0 -B 224 -S 44.1 > foo_mpe1.mpg > (Get error ``Bit rate is too low, dropping frames'') If you're dropping frames then jumpiness is, alas, inevitable. Also, don't xawtv and/or bcast2000 do reasonable real-time mjpeg capture? There is a lot less work to do than mpeg and thus it should run (in theory) be able to reduce the load on your machine. In practice, mp1e is very efficiently coded and I use a hardware mjpeg capture card so I have no idea how well software MJPEG capture works these days. I more or less gave up on software-only capture - it was far cheaper to buy an 2nd hand Buz than beef up my capture PC to the spec I suspected would be needed for capturing movies reliably. Indeed, even with hardware compressing capture reducing data-rates down to the 1-6M/sec mark it is surprisingly difficult to tune a machine to capture movie-length video 100% reliably (i.e. < 20 frames lost). I believe the "bttvgrab" package supports some nifty fast lossless compression schemes design to give a good speed/space trade-off for capture. Personally, using software compression, I suspect the margins are so low on affordable equipment that really reliable capture is damn near impossible. ****PLEA FOR INFORMATION - Can anyone give me reliable info on how well software-compress MJPEG capture using bt<whatnot> capture cards can be made to work? I'd like to put some decent hard info in mjpeg FAQ (which needs updating). > 2. Demultiplex audio for re-encoding > mpeg1demux foo_mp1e.mpg -a "cat > foo.mp2" -v "cat > /dev/null" > > 3. Uncompress video for re-compression > AUDIO_PIPE=`mktemp -u /tmp/audio.XXXXXX` > mkfifo $AUDIO_PIPE > VIDEO_PIPE=`mktemp -u /tmp/video.XXXXXX` > mkfifo $VIDEO_PIPE > ( qtmux foo.mov $AUDIO_PIPE $VIDEO_PIPE & mpeg1demux foo.mpg -a "buf | \ > mpg123-stream - > $AUDIO_PIPE" -v "buf | mpeg2decode | \ > yuvrgb > $VIDEO_PIPE" ) > rm $AUDIO_PIPE $VIDEO_PIPE > 4. Re-compress video so that it is VCD-friendly > mpeg2enc foo.mov -o bar.mpg You definately want as high a quality original as possible if you're transcoding. So the bit-rate you're setting for mp1e is really *very* low. I suspect you'd need to go to *at least* 3 times the data-rate to avoid really heavy quantisation losses in the mpeg encode and decode. Explanation: MPEG adjust compression to suit the specified data rate by adjusting the precision to which brightness/colour information is held. 1152Kbps is very much at the low end of MPEG-1's feasible data-rates and *very very* low if you don't have much motion compensation going. > 5. Multiplex video and audio > vcdmplex bar.mpg foo.mp2 final.mpg > (Get error ``BUFFER underrun!'' after about 40 seconds of video have > been processed) Bad sign. This is saying that a VCD player with a standard data buffer would not be able to keep up with the videa data-stream when played at the standard bit-rate. Possibly a rate-control deficiency in mpeg2dec. Which version are you using - the MSSG original from lavtools-1.2, one of the "MSSG+" tarball snapshots on mjpeg.sourceforge.net or the latest cvs version from there or some other? You *should* get very reliable results with the latest "MSSG+" (a few bugs have been fixed) and its a load faster and mildy better quality than the original (caveat: I'm the guy who did the programming ;-)). Also, vcdmplex is known to (on some systems, for some people) generate audio drift in the multiplexed original. You might (if you're feeling brave) want to try the latest version of "mplex" from the mjpeg cvs. Its recently been heavily updated and now has a nice flag that *should* generate VCD compliant streams. I can't test it myself direct as my player (dxr2 board) is extremely omnivorous - I'm very keen to get feedback and promise to fix any remaining deficiencies double-quick if some kind soul gives me some feedback ;-) > ================================================================================ > > Here are some problems, questions, and comments: > > o Colors become washed out between step foo_mp1e.mpg and final.mpg. Quantisation loss. > o Image quality could be improved. Perhaps I could grab with mp1e at > a bit rate above 1152Mb/s since I am recompressing anyway. I have a > feeling mpeg2enc may be able to create higher quality low bitrate streams, > as it does not have a real time requirement. MPEG-1 isn't designed to support bit-rates below 1Mb/s for the kind of resolution/frame-rate you're capturing at. Worse, the VCD format is extremely restrictive (fixed bit-rate, small decoder buffers, small GOP) so you can't even get even close to the best MPEG can do and still stay hardware VCD player compatible. mpeg2dec in its current incarnation should do markely better than mp1e when you turn on a big motion compensation search radius. However, < 1M bps will still look pretty poor. Bear in mind also that capture from broadcast sources is almost a worst-case scenario for compressors due to the rather poor signal/noise ratio. If compressing hard you should definately filter first. mpeg2dec now has some (very rough and ready) smoothing filters which help a lot when you need to squeeze rought raw material hard. One day I'll replace them with something decent ;-) It should (sometime this year) do a better job still once I implement a decent look-ahead bit-allocation algorithm. However, if you're really needing to squeeze hard a software decoder with its far greater flexibility will allow you to achieve far better results. (Most of the gains people trumpet for "MPEG-4" codecs under windows are actually a combination of a decent implementation by microsoft, excellent source material (ripped DVD's), and the tricks you can play when you have a whole PC doing the decoding. > o After about four minutes the video becomes extremely jumpy when I play > it on my DVD player. This happens whether I fast forward to the four > minute point or not. Unfortunately, I have not been able to try my disc > in any other DVD player than my own. This could well be related to the buffer underflow... > o How could I reduce the process I use? I would really like to skip > the recompression phase, but mp1e seems to be unable to generate VCD > compliant streams at this point. mpe1 is the ONLY grabbing program I > have found with which I am able to grab syncronized audio and video from > my Win TV PCI card. Can't help on the Win TV thing. Andrew
