DM365 MPEG4 latency between two units

any thoughts?

bump!

So I'm still looking for answers to this question, i found the following wiki page:

http://wiki.davincidsp.com/index.php/Networked_encode_and_decode_demos

and it says

"Two options for reading, one from file and another from the network are introduced, the video thread would read from the file using the functions 'loaderPrime' and 'loaderGetFrame' while on the other hand if you are trying to read from the socket descriptor use the readTCP function defined in the network_utils.c file. As readTCP require the size of the buffer to be read, so before reading the actual buffer one has to read the size of the next transmitted buffer."

Does this mean that I don't have to use the loaderPrime and loaderGetFrame functions? That would fix some of my problems, because the loaderPrime function wants to read somewhere around 691K bytes of data, which is quite a delay when running at slower bit rates.

I still need to find out how to make the decoder more forgiving to underrun conditions, at least I think that is the problem.  I get the "failed to decode video buffer" error when I am streaming video and audio from unit to unit.  I can run the audio by itself and the video by itself pretty well, but the when I try to run both the decoder becomes unstable. 

Please help me with this!  I know the answers are out there somewhere, since there are plenty of video network appliances out there that do exactly what I am doing!!!

Thank you in advance

I am not sure how much help I can be but will give you my two cents.

Just did a quick search in DM365 DVSDK tree and did not find references to readTCP or loaderGetFrame functions, and I am not really familiar with them.  The wiki article you are referring to was based on dvsdk 1.20 (really old) and may not apply to dvsdk 2.10 provided with DM365.

That said, based on the information you provided, my guess is that you may be running into a DDR2 bandwidth issue.  For the most part, MPEG4 tasks are done primarily by the hardware MJCP offloading the ARM to do other things.  MJCP can access DDR2 directly and not much can be done about the way it needs to use memory to satisfy MPEG 4 encode/decode requests (except for reducing bit-rate or resolution of video); depending on the video resolution you are using, this can have a  big impact on your DDR2 bandwidth consumption. 

That said, you can try reducing DDR2 bandwidth in other stages of the system; are you using previewer, resizer.., video capture or display?  Are you managing buffering the best way (our dvsdk demos were written to show functionality and are not necessarily optimized).  Unfortunately, I do not have too specific advice for you, but just some general things to consider.

The readTCP function from that wiki page I'm assuming was just a generic TCP socket read.  The Loader_getFrame and Loader_prime functions are located under the dmai directory in the Loader.c file.

Right now my main concern isn't even system latency as the post originally states, it has turned into a concern about stability.  I've had the encoder running for a couple of days now pretty well, but the decoder can't run for more than a couple minutes without the dreaded "failed to decode video buffer" message.  I've been all over the dvsdk trying different things, but just can't seem to get it running any better.  I will continue to look through documents and code looking for a solution. 

Thanks Jaun for suggesting something and if anybody else has anything that would also be greatly appreciated.

update:

This is the error I get when running it with CE_DEBUG=1

@337,528,478us: [+7 T:0x419b6490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() failed with error (-1 ext: 0x8802)
Error: Failed to decode video buffer
@337,961,321us: [+6 T:0x419b6490] OM - Memory_contigAlloc> Warning: non-default alignment not supported for pool-based allocations, using default 0xffffffff.

Where can I find info on figuring out what exactly that extended error means?

Extended errors include some XDM-specific- and some Codec-specific-bits.  XDM-specific details are described in the XDAIS API guide under XDM_ErrorBit section.

That particular error has both 0x8000 and 0x0800 bits set, indicating XDM_CORRUPTEDDATA and XDM_FATALERROR.  You may be able to find what bit 0x2 is from the codec-specific data sheet(?).

Chris

I found the following when looking for codec specific errors corresponding to bit 0x2

    IVIDEO_FRAME_ERROR = 2,     /**< The output buffer is available and
                                 *   corrupted.
                                 *
                                 *   @remarks   For example, if a bitstream
                                 *              is erroneous and
                                 *              partially decoded, a
                                 *              portion of the decoded
                                 *              image may be available
                                 *              for display.  Another
                                 *              example is if the
                                 *              bitstream for a given
                                 *              frame decode may be
                                 *              decoded without error,
                                 *              but the previously
                                 *              decoded dependant
                                 *              frames weren't
                                 *              successfully decoded.
                                 *              This would result in
                                 *              an incorrectly decoded
                                 *              frame.
                                 */

I am sure that I am getting corrupted data now.  Found a few issues in my driver that handles the sending and receiving of data to and from my application.  I still must have an issue somewhere because I still get the dreaded failed to decode frame error message.  If I play back the file with MPlayer, it shows errors but continues to run at the same spot where the decoder fails.  Is there a way to make the decoder ignore bad data and just go on to the next frame?  Clearly I want to fix my corrupt data, but if a decoder is on a network, there is a chance of getting bad data or missing a packet, and it would be nice if the decoder could handle some data loss.

Any thoughts on this?