<br><font size=2 face="sans-serif">All</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the earlier advice. We think
that our earlier problem with large frames in a recorded video stream was
due to insufficient socket buffer space on the receiving end during a recording.
("Large frames" were 2x-5x the size of a normal I-frame or P-frame,
but only a fraction of that was really picture data.) </font>
<br>
<br><font size=2 face="sans-serif">Now that we have improved recordings
of our video stream, we are working to make playback of those stream files
from our storage media look better. A lot of our playback problem stems
from sending data to our DSP decoder slightly faster than it can handle.
This leads to stutters in the playback (dropped frames) and a sort of digital
splatter (blocky video until the next I-frame). We have tried a couple
of ways to reduce the rate at which we send data to the decoder, including
slowing our system clock down a bit. (Our CPU has no real time clock, and
our DSP is not clocked at the same rate as the CPU.)</font>
<br>
<br><font size=2 face="sans-serif">We are looking at controlling the bit
rate used during a recording and playback rather than adjusting system
time. In our system, we can set a target bit rate used by the DSP when
encoding analog to digital, but that seems to work by dropping frames.
This makes our recordings look a little worse than before when played back
on a PC, since we're missing some frames. </font>
<br>
<br><font size=2 face="sans-serif">Is there a mechanism in the live555
library that allows us to control the bit rate in a playback from our CPU
to our DSP without dropping entire video frames? </font>
<br>
<br><font size=2 face="sans-serif">Thanks!</font>
<br>
<br><font size=2 face="sans-serif">-=- Mike Miller<br>
Rockwell Collins, Inc.<br>
Cedar Rapids, IA </font>