[Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream

[Markus Schumann]

Ross,

Thanks for your answer.

I tried it and I still get a stack overflow.


1)      I had to modify the buffer size in liveMedia\MPEG2TransportStreamFromESSource.cpp(198) due to the following error message

MultiFramedRTPSource::doGetNextFrame1():
The total received frame size exceeds the client's buffer size (99961).

41451 bytes of trailing data will be dropped!
MPEG2TransportStreamFromESSource: input buffer too small;
increase "MAX_INPUT_ES_FRAME_SIZE" in
"MPEG2TransportStreamFromESSource" by at least 41451 bytes!


2)      My overflowed stack look like this:
FramedSource::afterGetting
MPEG2TransportStreamMultiplexor::doGetNextFrame
FramedSource::getNextFrame
FileSink::continuePlaying
FileSink::afterGettingFrame
FileSink::afterGettingFrame
FramedSource::afterGetting
MPEG2TransportStreamMultiplexor::doGetNextFrame
FramedSource::getNextFrame
FileSink::continuePlaying
FileSink::afterGettingFrame
FileSink::afterGettingFrame
FramedSource::afterGetting
MPEG2TransportStreamMultiplexor::doGetNextFrame
FramedSource::getNextFrame
FileSink::continuePlaying
FileSink::afterGettingFrame
FileSink::afterGettingFrame
FramedSource::afterGetting
MPEG2TransportStreamMultiplexor::doGetNextFrame
FramedSource::getNextFrame
FileSink::continuePlaying
FileSink::afterGettingFrame
FileSink::afterGettingFrame
FramedSource::afterGetting
MPEG2TransportStreamMultiplexor::doGetNextFrame
MPEG2TransportStreamMultiplexor::handleNewBuffer
InputESSourceRecord::deliverBufferToClient
MPEG2TransportStreamFromESSource::awaitNewBuffer
InputESSourceRecord::afterGettingFrame1
InputESSourceRecord::afterGettingFrame
FramedSource::afterGetting
MultiFramedRTPSource::doGetNextFrame1
MultiFramedRTPSource::networkReadHandler1
MultiFramedRTPSource::networkReadHandler
BasicTaskScheduler::SingleStep
BasicTaskScheduler0::doEventLoop


3.) I saw the following comment in the code:
liveMedia\MultiFramedRTPSource.cpp(198)
// Call our own 'after getting' function, so that the downstream object can consume the data:


if (fReorderingBuffer->isEmpty()) {
// Common case optimization: There are no more queued incoming packets, so this code will not get
// executed again without having first returned to the event loop.  Call our 'after getting' function
// directly, because there's no risk of a long chain of recursion (and thus stack overflow):
afterGetting(this);

I am definitely going through this code path.

Do you have any advice?

Thanks
Markus.


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, April 18, 2013 2:00 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream

Do I call [...]sink->startPlaying(

Yes, of course.  All LIVE555-based applications call "startPlaying()" on one or more 'sink' objects (subclasses of "MediaSink").  (For "testRTSPClient" and the "*Streamer" applications, this is done just before entering the event loop; for the RTSP server applications, this is done when handling an event within the event loop.)

The big difference between "testRTSPClient" and your proposed application is that "testRTSPClient" creates several "DummySink" objects (one for each subsession), and calls "startPlaying()" on each one.

Your application, on the other hand, will have just one 'sink' object - a "FileSink" - and you will call "startPlaying()" on it (just once!), with the "MPEG2TransportStreamFromESSource" object as source parameter.

I suggest that your "continueAfterSETUP()" function call "addNewVideoSource()" or "addNewAudioSource()" (depending on the media type) on the "MPEG2TransportStreamFromESSource" object (using the corresponding subsession's "readSource()" as parameter).  Then, for the *final* "continueAfterSETUP()" call only, call "startPlaying()" on the "FileSink" object.

How Do I feed a MPEG2TransportStreamFromESSource into the file sink?

By calling "startPlaying()" on it (just once).

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130418/f401b71e/attachment-0001.html>