All
We're looking in to a problem with playback of our transport streams. From
looking at the code in the liveMedia library, we think that it's primarily
handled by MPEG2TransportStreamFramer.cpp. So that we don't interfere too
much with a playback, we've added a few debugging print statements.
Ross
Your advice was very helpful. We found the place in our code where we
meant to drop a frame but instead stopped calling the afterGetting()
function.
-=- Mike Miller
SW Engineer, Govt. Systems
Rockwell Collins, Inc.
Cedar Rapids, IA ___
live-deve
Ross
Thanks for the quick reply and the advice.
Just a note about the MultiFramedRTPSource class we're using. The first
time doGetNextFrame() is called, it starts the network read handler. This
handler continues to run, pulling packets off the network and buffering
them, until the object is d
All
We've inserted a custom filter into our transport stream recording chain.
Almost all the time it works (and has been working pretty well for many
months), but lately we've seen this problem:
data is being streamed towards our unit, and RTP packets are being
buffered;
when our problem occu
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
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.
All
The mention of "properly-synchronized presentation time" sounds like it
might be related to a problem we are having.
We have an application using the live555 library running on an embedded
processor that record a digital audio/video stream to a file. The stream
is generated by a separate
Roland
Thanks for the suggestion. We've confirmed that the large frames contain
only a single picture by searching for the MPEG-2 start codes.
We're working on a filter that will truncate a frame when it exceeds a
given size, so that excessively large frames are not written to the file.
What
All
We're working with an embedded system that receives an MPEG-2 transport
stream from a TI DSP. We've built an application that uses the live555
libraries to write this stream out to disk. Every once in a while a very
large P-frame, on the order of four times the size of a typical P-frame in
10 matches
Mail list logo