Here's the stack trace:
H264VideoDiscreteFramer::doGetNextFrame() at
H264VideoDiscreteFramer.cpp:35 0x804fbba
InputESSourceRecord::askForNewData() at
MPEG2TransportStreamFromESSource.cpp:191 0x8050e7c
MPEG2TransportStreamFromESSource::awaitNewBuffer() at
MPEG2TransportStreamFromESSource.cpp:138 0x8050ef8
MPEG2TransportStreamMultiplexor::doGetNextFrame() at
MPEG2TransportStreamMultiplexor.cpp:53 0x805e9ba
MultiFramedRTPSink::packFrame() at MultiFramedRTPSink.cpp:215 0x80530bd
MultiFramedRTPSink::sendNext() at MultiFramedRTPSink.cpp:402 0x8053599
AlarmHandler::handleTimeout() at BasicTaskScheduler0.cpp:34 0x8067c33
BasicTaskScheduler::SingleStep() at BasicTaskScheduler.cpp:150 0x8065a31
BasicTaskScheduler0::doEventLoop() at BasicTaskScheduler0.cpp:76 0x8067320
I notice that you're feeding your TransportStream data (from the
"MPEG2TransportStreamMultiplexor") directly into a RTPSink. Although
that *might* work in this case (because you're reading from a live
source rather than from a file), it would be safer to have a
"MPEG2TransportStreamFramer" object sitting between your
"MPEG2TransportStreamMultiplexor" and your RTPSink. This may cause
RTP packets to get sent out at a more even rate.
You also didn't say anything about your H.264 input source
implementation - i.e., the class that feeds into the
"H264VideoStreamDiscreteFramer" - but it's conceivable that the
blockage is happening there. I.e., you should make sure that the
call to "doGetNextFrame()" on your input source object is always
causing data to be delivered to the downstream object (the
"H264VideoStreamDiscreteFramer") without excessive delay.
> If, however, you insist on transmitting Transport Stream data (rather
than raw H.264) over RTP, then I suggest that you first create a
Transport Stream *file*, and then trying to stream that (e.g., using
our existing, unmodified "testOnDemandRTSPServer" or
"live555MediaServer" applications). That might give you some idea
about what's going wrong.
Thank you for you suggestion, I'll try to simulate the problem
creating a big TS file with the estimated time to failure in mind.
It sounds like you're going to want to do this (write incoming data
into a Transport Stream File) in the future anyway, because you
mentioned that you eventually want to support 'trick play'. ('Trick
play' operations are only for pre-recorded data, not for live
streams.) So you might as well get used to recording files.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
