On 3/28/2011 10:38 AM, Diogo Andrade wrote:
how to modify this behavior so it will freeze the frame instead of stopping the streaming
The muxer is expecting a constant stream of data, because digital cable TV (QAM) is a CBR system. Ideally, a QAM muxer wants CBR streams. Your particular muxer may have some limited ability to cope with VBR codecs by padding its output, but that doesn't extend quite to the point of handling 0 bps gracefully.
For the muxer to do that, it would have to be decoding the video on the fly, then when it sees the video stream disappear, it would have to start re-encoding the last frame at the same bit rate it used to get from the stream and sending that out instead.
Surely it is clear to you already that this would be a very stupid way to design a muxer. Adding real-time decoding and re-encoding would increase its cost quite a lot.
I point it out despite this hope that it is already obvious to you because the next step is to start tracing things back up the stack to find a piece that *could* do such a thing.
That next step is Live555. Do you see MPEG decoding and encoding in the library? No? So, not on topic here, yes?
One possible way to get the behavior you ask for is at your encoder. Instead of telling Live555 to pause the stream, you should be asking your encoder to freeze-frame.
If you are trying to build DVR-like functionality where un-pausing the stream resumes it at the pause point instead of re-joining the live stream, you need to build a layer between Live555 and the encoder which does the store-and-forward. But this is also not on-topic here.
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
