[Live-devel] Please help: I have difficulties implementing the right classes

[Fabrice Triboix]

Hi Ross,

Thanks a lot for your answers.

I have some comments/additional questions, inline in green below.

Many thanks for your help!

  Fabrice

________________________________
From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com]
Sent: 04 September 2014 18:35
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Please help: I have difficulties implementing the right classes

Could it be that calling deliverFrame() multiple times might be wrong?

Yes, that's wrong.  Your "doGetNextFrame()" function should deliver one, and only one, H.264 NAL unit (note, not a H.264 'frame') each time it's called.
[Fabrice] All right, that's good to know. From time to time, the encoder sends an SPS and a PPS NALU before the data NALU (all in one "frame"). So when that's the case, I need to somehow have the doGetNextFrame() method being called a 2nd and a 3rd time... What's the best way to do this?

Note that if - at the time that "doGetNextFrame()" is called - no H.264 NAL unit is currently available, your "doGetNextFrame()" implementation should return immediately, and your "deliverFrame()" function must not get called again until later, when a new H.264 NAL unit becomes available.
[Fabrice] All right. This is what I am doing now; my deliverFrame() method is called only from doGetNextFrame().

I suggest reviewing the "DeviceSource" demo code, and note how it uses an 'event trigger' (signaled from a separate thread) to do this.
[Fabrice] Yes, I carefully went through it. However, I am using a scheduleDelayedTask() with a "period" of 10ms because I wanted to get something working quickly. I will implement a proper monitoring thread which will signal a trigger once I get this implementation working.
BTW, what would happen if the monitor thread signal the trigger twice because 2 frames arrived almost simultaneously (and doGetNextFrame() hadn't been called yet for the first frame)?

Also, because you're delivering discrete H.264 NAL units (i.e., one at a time), your "OnDemandServerMediaSubclass::createNewStreamSource()" implementation should be feeding your input source object into a "H264VideoStreamDiscreteFramer", not a "H264VideoStreamFramer".  (Note that, in this case, the H.264 NAL units from your input source must *not* begin with a 'start code' (0x00 0x00 0x00 0x01).)
[Fabrice] I am using an MPEG4VideoStreamDiscreteFramer, as in wis-streamer. Is that wrong? Should I discard the start code if I use MPEG4VideoStreamDiscreteFramer? Same question if I use H264VideoStreamDiscreteFramer?
Here is the implementation of my createNewStreamSource() method:
FramedSource* CVideoSubsession::createNewStreamSource(unsigned clientSessionId,
        unsigned& estimatedBitRate)
{
    // TODO: This is a leak, the CAvSource object should be a property
    CAvSource* src = CAvSource::createNew(envir(), "vid_h264_hd", "output");
    if (NULL == src)
    {
        return NULL;
    }

    return MPEG4VideoStreamDiscreteFramer::createNew(envir(), src);
}

Finally, because you're delivering from a live source (rather than a prerecorded source like a file), you don't need to set "fDurationInMicroseconds".
[Fabrice] Is is bad if I do?

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/20140905/649cf897/attachment-0001.html>