> 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/

_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to