Of courese, providing a large enough buffer is always the practical solution. However, it is unreasonable to predict how large is an incoming video frame for a general streaming client. That is, a practical streaming client should be smart enough to enlarge its buffer on the detection of a truncated frame. But how to?
<br><br>Take MPEG4 ES video for example and assume the client is able to adjust its buffer size. The video frame size may range from 15KB to 110KB or more which depends on the streaming source. In the registered MultiFramedRTPSource::fAfterGettingFunc(), the client has numTruncatedBytes and presentationTime as the key clues to adjust its buffer size and drop the remaining part of a truncated frame.
<br><br>If the client is unable to change its buffer size(just limited), it still has a chance to drop the remaining part of a truncated frame delivered from MultiFramedRTPSource by itself with the duplicated presentationTime. Actually, a streaming client is made by human rather than God, so it can not predict its buffer size exactly well :-)
<br><br>One more question: Is the argument 'durationInMicroseconds' provided in MultiFramedRTPSource::fAfterGettingFunc() believable for live recording?<br><br><div><span class="gmail_quote">2006/12/21, Ross Finlayson <
<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>In MultiFramedRTPSource.cpp
, I note if the provided<br>>SubsessionIOState::fBuffer is not large enough to hold a complelte<br>>frame, the MultiFramedRTPSource will call its afterGetting() to<br>>deliver the truncated frame due to fNumTruncatedBytes > 0. However,
<br>>the remaining packets of this frame is not skipped or dropped but<br>>delivered as the next frame with the same timestamp.<br>><br>>Is it acceptable in reality?<br><br>Well, if incoming frame data is getting truncated (due to
<br>insufficiently large buffers at the client), then things are broken -<br>you should really fix that, rather than worryng about what else the<br>code is doing at that point.<br>--<br><br>Ross Finlayson<br>Live Networks, Inc.
<br><a href="http://www.live555.com/">http://www.live555.com/</a><br>_______________________________________________<br>live-devel mailing list<br><a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com
</a><br><a href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a><br></blockquote></div><br>