[Live-devel] A question about live555's support on mp4‏

[xiaoyiz_2 at codeaurora.org]

Hi ,
 I have the following question :

We currently use the live555 code to run a RTSP server source from a
camera. The camera generates H264 content as two streams (with different
resolutions high-res & low-res). There is no audio. We stream the low-res
on RTP, and optionally store the high-res to file. We would like to use
the live555 to store the high-res content locally as mp4 container file.
This is on a linux system.

Although we were partially successful with QuickTimeFileSink, the approach
is not clean. We don’t have a complete rtpSource built for the high-res
stream. Hence we had to skip the dereference to that object for RTPSeqNum
as below. Attached was my example code to generate the mp4 file.



void SubsessionIOState::afterGettingFrame(unsigned packetDataSize,

                                    struct timeval presentationTime) {

  // Begin by checking whether there was a gap in the RTP stream.

  // If so, try to compensate for this (if desired):

  unsigned short rtpSeqNum = 0;



  if (fOurSubsession.rtpSource()) {

    rtpSeqNum = fOurSubsession.rtpSource()->curPacketRTPSeqNum();

  }

  if (fOurSink.fPacketLossCompensate && fPrevBuffer->bytesInUse() > 0) {

    short seqNumGap = rtpSeqNum - fLastPacketRTPSeqNum;

    for (short i = 1; i < seqNumGap; ++i) {

      // Insert a copy of the previous frame, to compensate for the loss:

      useFrame(*fPrevBuffer);

    }

  }

  fLastPacketRTPSeqNum = rtpSeqNum;


.



Please let us know whether you will be able to support a mp4 container
file generation from this library. Whether the change we made above is
acceptable for the time being? If you do not plan to support this, but
have different suggestions about the approach or another alternate
library, we would really appreciate your feedback.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Source1.cpp
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160129/5242e829/attachment.ksh>