[Live-devel] Problem streaming continuous H.264 video over Transport Stream

[Ross Finlayson]

>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/