I am struggling for some while now, what happens if your sources
receives a complete frame larger than the maximum that can be
passed into an UDP packet.
That's not a problem. The RTP payload format (and our implementation
of the RTP payload format) for each codec takes care of fragmenting
frames across RTP packets, if necessary. You don't need to worry
about this; just pass the complete frame into the appropriate
"RTPSink" subclass.
Intuitively I would say it gets split up into multiple packets and
merged again on receiver side.
Yes.
From one of my last messages here, I learned that making the buffer
fTo in a source large enough to hold my largest discrete frames is
the way to avoid frame truncation and
droping of partial frame data. I currently do this by calling
"setPacketSizes(preferredSize, maxPacketSize)" just after the
instantiation of the MultiFramedRTPSink.
No, that's not the right way to do this. Calling "setPacketSizes()"
changes the sizes of the outgoing RTP/UDP packets. You usually don't
need to do this; the default packet sizes work for most networks.
Instead, you want to set the size of the *buffer* that the RTPSink
uses to receive incoming frames. To do this, add (e.g., to set a
buffer size of 150000 bytes)
OutPacketBuffer::maxSize = 150000;
*before* creating your RTPSink.
I am unsure about how to pass a rather large frame (e.g. 140K) from
my source to a MultiFramedRTPSink
See above.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
