[Live-devel] DeviceSource Translate large frames (fNumTruncatedBytes)
Ross Finlayson
finlayson at live555.com
Mon Oct 14 22:59:02 PDT 2013
> I try translate H264 video stream by Live555. The hardware video source is the video camera (USB).
> Class for Live555 video source derived from DeviceSource.
> The problem in function DeviceSource::deliverFrame :
> When the newFrameSize > fMaxSize i set fNumTruncatedBytes, but only result is the message:
>
> “The input frame data was too large for our buffer size ….. bytes of trailing data was dropped!”
>
> This mean (as I understand) that the truncated part of frame is dropped.
> Is this mean that the truncated frame is dropped?
Yes. If the input frame is larger than the buffer space that the downstream object provides, then you will *not* be able to deliver all of the data. The remaining data will be truncated (i.e., dropped, lost).
> In message we have recommendation:
>
> “Correct this by increasing \"OutPacketBuffer::maxSize\" to at least”
>
> Is any way to sending large frames (H264 key frames , or other), except the HUGE fMaxSize?
No. The downstream object's buffer must be large enough to receive the frame.
However, this shows why very large H.264 key frames are a bad idea. Even if you have a large enough buffer to stream these frames, each one will be packed into many outgoing RTP packets. If *any* of these packets gets lost, the receiver will be unable to reconstruct the frame.
Instead, it is much better if you can break up each 'key frame' into several 'slices' (each of which would be its own H.264 NAL unit). Each of these slices (NAL units) would be delivered separately.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131014/4b78e845/attachment.html>
More information about the live-devel
mailing list