> 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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
