[Live-devel] OPUS encoded stream via SimpleRTPSink

Ross Finlayson finlayson at live555.com
Sat Feb 4 06:47:56 PST 2017


> I did not fully get the part about the RTP packet assembly. The RTP
> packet (12-byte header) is created by the RTPSink, right?

Yes, we fill this in automatically.  All you need to provide is the payload (in this case, one OPUS ‘packet’ each time).

> So after
> digging through the RFCs and the code, is there any more information
> that I actively have to provide in addition to the frame itself? Right
> now I also set fFrameSize, fNumTruncatedBytes, fPresentationTime,
> fDurationInMicroseconds, although I don't know if this is mandatory?

Because you are streaming from a ‘live’ source (rather than pre-recorded media such as a file), you should *not* set “fDurationInMicroseconds”.  (It will then remain at its default value, 0, which is appropriate when streaming from a live source.)


> 
> I know you don't look at codes :-) , however, here it is:
> 
> void deliverFrame()
> {
>    if((!isCurrentlyAwaitingData()))
>        return;
> 
>    if(!m_queue.empty())

OK, but what if the queue *is* empty?  In this case, you’ll need to (somehow) arrange for the code to get called again in the future, when an OPUS packet becomes available.

Note that you are doing event-driven programming.  If no OPUS packet is immediately able to be delivered, then you should not ‘block’, waiting for one to come available.  Instead, you must arrange for an event to get handled when a packet later becomes available.  One common way to do this is to have a separate thread for you encoder; this thread would call no LIVE555 library function *except* “triggerEvent()”.  See, for example, the comments in “DeviceSource.cpp”.


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




More information about the live-devel mailing list