We have the option in our Linux-based system to adjust the system
time tick to 4 ms or 1 ms. Within the liveMedia library, the
resolution of time is in microseconds. Is the resolution of our
system's time -- 1,000 or 4,000 microseconds -- small enough for
decent playback?
Yes, that should be
Ross and all
Thanks for the earlier advice. We've been able to make improvements.
It turns out that our OS was misconfigured, causing it run 2% faster than
we should.
We've taken these steps:
- corrected OS timing rate
- increased socket send and receive buffer sizes on our end, following the
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?
The best way to control the data rate of a streaming (transmitting)
application is through the "fDurationInMicroseconds" field that yo
All
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
Jerry
> what are the specific roles of the DSP and your GPP (general purpose
processor,
The DSP handles the encoding of an analog input to a digital stream, and
also the decoding of a digital stream to analog output. The GPP handles
control tasks -- set up of streams, working with files, etc.
(I've changed the Subject: line to something more appropriate.)
when reading timestamp info from the recorded file. After timing the
playback of several files, it looks like our embedded processor is
running about 2% faster relative to our DSP. This causes our
processor to send packets and fra
