[Live-devel] What to do when fNumTruncatedBytes > 0

[Matt Schuckmann]

Ross Finlayson wrote:
>> I'm wondering what I can do when fNumTruncatedBytes is > 0 on either 
>> the client or server side.
>
> I don't really understand this question.  "fNumTruncatedBytes" is a 
> variable that is *set* (not queried) by each "FramedSource" subclass 
> (including any new "FramedSource" subclass that you define and 
> implement yourself.  (See, for example, the comments in 
> "DeviceSource.cpp".)
>
>
Lets see if I can describe this right.
For my server it's my H264Source class (derived from 
H264VideoStreamFramer) that sets fNumTruncatedBytes to tell the 
framework that a NAL packet is too big for the buffer who's size is 
fixed (I can't currently remember where it set). I'm really not sure why 
the framework cares about this since it appears to do nothing with the 
information.

On the client side fNumTruncatedBytes is set by the framework and passed 
to my afterGettingFrame method (of my videoSink class), again this is 
set as a result of a NAL packet or frame that is to large for a fixed 
sized buffer (again I can't remember where this buffer size is set). 
Again there appears to be nothing useful I can do with information so 
why am I told about it.

In both cases it appears that the data is just lost you provide no way 
to recover (or send) the bytes that didn't fit in the fixed size buffer. 
And I wanted to know if that is really true that there is nothing I can 
do about the lost data or if I missed something and there is in fact a 
way to recover.

It seems odd to me that in a dynamic system like this with so many 
unknowns that there is no way to recover or adapt to what amounts to 
buffer overflow problems like this.

Ideally, I'd like a way to send or receive those bytes that didn't fit. 
At a minimum I'd like a way for my application to say hey I just had a 
frame that didn't fit, oh well that frame is messed up but I'd better 
make my buffers a bit bigger so that I don't complete hose the users 
experience.

>> Is there anything I can do here other than just make the buffers 
>> really big when things startup?
>
> If you're referring to the buffer that each "FramedSource" (subclass) 
> object provides to its upstream object, then the answer is no: The 
> downstream object needs to provide a buffer that's sufficiently large 
> for its upstream object to write into.
How does one know how big to make these buffers? This is especially true 
of client implementations because I as a programmer have no idea how big 
of a pipe a user is going to point my application at.


Matt S.