|
Thank you all for your help. It looks like the problem is on my side. One engineer, before he left, started implementing Forward Error Correction and it looks like the new code is causing the loss of packets. A modified ReorderingPacketBuffer::storePacket was rejecting the incoming packets when there were too many of them. I disabled all the FEC code and it is much more stable. I apologize for any inconvenience this may have caused. As for very large buffers, it seems to work very well. I modified currentNALUnitEndsAccessUnit to return false unless it is sending the last chunk of the compressed frame. That was before I set the global variable OutPacketBuffer::maxSize to a larger value. On the client side, the destination buffer is large enough to hold the largest compressed frame. Georges Patrick White wrote: I just fixed this issue in our code last night -- the I-frame from the H.264 encoder was getting truncated because it was too big to fit into the stock OutPacketBuffer buffer (only ~60000 bytes).The short answer is that the entire outgoing packet must fit into a buffer -- there's no way for the LIVE555 code to output the correct packets if it doesn't. Matt's idea of having the codec produce smaller NALs has a good channe of working.. but I just upped the buffers for now: On the server end, before you instantiate RTSPServer, set the global variable OutPacketBuffer::maxSize to your desired output buffer size. The output buffer(s) will be automatically allocated. On the client side you have to call getNextFrame() with a big enough buffer -- that call happens from code we've written, so I don't know what you might have to do to make it work, or even if you need to do anything. I upped both buffers because I'm in a hurry -- perhaps only the outgoing buffer is sufficient. Long answer: Over in H264FUAFragmenter::doGetNextFrame(), it uses case 2 to send the initial FU-A packet after it gets a new buffer full, then case 3 to send the balance of that buffer via FU-B packets. Near as I can tell, there's no way to jump back into case 3 with another buffer full.. ergo, the entire frame must fit into a single buffer full to be sent out as the proper sequence of FU-A/FU-B packets. At least, that's the state of the code as of a month or two ago when we last updated... Ross, the code's a little convoluted down there, is my interpretation correct?, did I misunderstand the logic flow? or have you made recent changes down there to fix it? Regardless, upping the buffer sizes fixed the issue for us. Hope that helps. patbob On Thu Mar 19 12:56:08 2009, Georges Côté wrote: |
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
