[Live-devel] Why not skip(or drop) the remaining packets of a truncated frame?

[Brain Lai]

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?

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.

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 :-)

One more question: Is the argument 'durationInMicroseconds' provided in
MultiFramedRTPSource::fAfterGettingFunc() believable for live recording?

2006/12/21, Ross Finlayson <finlayson at live555.com>:
>
> >In MultiFramedRTPSource.cpp, I note if the provided
> >SubsessionIOState::fBuffer is not large enough to hold a complelte
> >frame, the MultiFramedRTPSource will call its afterGetting() to
> >deliver the truncated frame due to fNumTruncatedBytes > 0. However,
> >the remaining packets of this frame is not skipped or dropped but
> >delivered as the next frame with the same timestamp.
> >
> >Is it acceptable in reality?
>
> Well, if incoming frame data is getting truncated (due to
> insufficiently large buffers at the client), then things are broken -
> you should really fix that, rather than worryng about what else the
> code is doing at that point.
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20061220/2ba6100b/attachment.html