[Live-devel] Sending lots of NAL's problem

[Yedidia Amit]

Hi All,

I am using the LIVE555 to stream h.264 bitstream 
My source is making NALS with limited size so each frame may contain
more than 1 NAL.( I recived all of them together from the HW).
After I received them I am creating small descriptors describing each
NAL (pointer, size) and send ALL of them to a socket that was assigned
to a  turnOnBackgroundReadHandling 
This should wake up the the scheduler to call the deliverFrame. 
In the mysource::deliverFrame I am reading only one descriptor each time
from the socket and passing it forward up to the discreteFramer.
In the discreteFramer I check if this is the last NAL in the frame, and
if NOT, I set the fDurationInMicroseconds to 0 so the doGetNextFrame
will be called immediately again (there are more descriptors in the
socket) so the fIsCurrentlyAwaitingData will be set to TRUE.

I see that the schedualer is launching my deliverFrame about  every
1-2msec, when I got multiple descriptors in the socket.
The problem is that when I got lost of descriptors (~80)  this can take
up to 160 msec which is way beyond my frame size which is 40 msec (PAL)

1. Am I doing this wrong?
2. Is there are a way to make the schedualer launch the the deliverFrame
faster?
3. Is the schedualer launching the task again when data is left at the
socket?
4. what is the tick resolution of the schedualer?

Thanks.

Amit Yedidia

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091230/48c0b068/attachment.html>