On Sat, 23 Sep 2006 12:37:50 JST [EMAIL PROTECTED] (Andrew Church) wrote: > > On the other hand, I have to admit I'd be surprised if you actually > made use of even 10-20 seconds of buffers without ending up with dropped > frames somewhere. What does the buffer status line (the part at the end > of the progress line that reads "( 1| 2| 3) or the like) look like while > you're capturing, i.e. how high do any of the numbers go? >
After experimenting with some command line parameters, I have resolved the issue. It seems that both input and output audio samplerate for the raw capture must be specified in the command line: transcode ... -e 32000,16,2 -E 32000,16,2 ... -u 1024,2 ... Using both of these options, the buffer status line never exceeds "1" in any position and there are no discarded frames. However, using only "-E 32000,16,2" (the output rate) on the command line causes the #3 position of the buffer status line to climb to 1023 over about 30-40 seconds, and the resulting encoded file exhibits audio/video sync problems. (According to the transcode man page, the input audio parameters should be autodetected and that's why I was omitting the option.) As long as both "-e" and "-E" parameters are given I can halt the capture at the desired end point using the Ctrl-C key. There are no more discarded frames and the audio/video sync of the encoded file is perfect. I'm very glad that I just accidentally stumbled upon this solution because the use of two-pass encoding with transcode can greatly reduce the size of the final encoded file. Thanks for the response. Frank Peters
