[Live-devel] DeviceSource Translate large frames (fNumTruncatedBytes)

Tue Oct 15 00:53:38 PDT 2013

Hi!

Thanks for the answer.

"*any* of these packets gets lost,"

Some questions:

Does it mean that RPT protocol is  unreliable?

So, if  'slices' (NAL units) would be delivered through RPT,  can they be
lost too? 

Why the 'slices' way is more reliable? 

Is a unreliable transmission normal (reality)?

In what object I must realize 'slices' technology?

Nick

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Tuesday, October 15, 2013 8:59 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] DeviceSource Translate large frames
(fNumTruncatedBytes)

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 >
<http://www.live555.com/liveMedia/doxygen/html/classFramedSource.html#7f4137
643c61539e313e3a92085efc08> fMaxSize i set
<http://www.live555.com/liveMedia/doxygen/html/classFramedSource.html#337ad4
9493202c89afd93564cc6263da> 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/ 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 8913 (20131014) __________

The message was checked by ESET NOD32 Antivirus.

????????? ??????????? ????? - - O?
????????? ??????????? ????? - - O?
???????? ??? ????? 00026.txt - - O?

http://www.esetnod32.ru/.ml

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131015/a024b5a1/attachment.html>