1. The short answer is "not likely". Multiple frame processing in a single process() call is not addressed in the xDM spec, so most codecs don't support it, and only pay attention to the first input buffer passed in. Codecs could technically and support this usage model - after all, up to XDM_MAX_IO_BUFFERS (16!) buffers can be passed in inBufs/outBufs for each process() call - but since it's not defined the xDM spec, most codecs don't support this.
[ That said, it could be perceived as a codec differentiator if a codec could mange multiple "channels" of data at a time... ] 2. This will again likely be codec specific. Some codecs (like simple speech codecs) may be able to process arbitrary buffer sizes. More complex codecs with clear frame boundaries (most) will only process a single frame at a time regardless of how much data is provided for processing. Good questions - and ones that we (the DaVinci developer community) should be sure to clarify in our documentation, both from our frameworks and codec-specific points of view. Chris > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > ] On Behalf Of Anil > Sent: Sunday, September 03, 2006 11:03 PM > To: Anderberg, Niclas; [email protected] > Cc: Pitney, Gilbert > Subject: RE: Question on DaVinci EVm Demo apps > > > Hi Niclas, > > Thank you so much for the prompt response. I've > couple of more > questions on the same issue. > > 1. Can the application request the algorithm to decode > multiple frames at > the same time (assuming the inputBuff contains data for > multiple frames). > > 2. In the demo application, the buffer allocation is done > based on some > pre-determined sizes (especially for audio and speech > decoders). Can this > take care of samples/frames of varying sizes ? > > > Warm Regards, > Anil > > > > -----Original Message----- > From: Anderberg, Niclas [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 02, 2006 2:57 AM > To: [EMAIL PROTECTED]; > [email protected] > Cc: Pitney, Gilbert > Subject: RE: Question on DaVinci EVm Demo apps > > > Anil, > > The reason why XDM_GETBUFINFO is used in vidoe decode is to figure out > what the worst case size of a video buffer is. We are decoding > elementary streams with no headers so there is no way knowing ahead of > time what the size of the next encoded frame is. Instead we > pass down a > buffer of size X and the decode algorithm returns how many bytes Y it > actually used using outArgs.bytesConsumed. We have to make that *at > least* one frame is passed to the decode algoritm for each > process call, > otherwise the decoder will fail and we will have to drop a frame or > possibly quit the app. To make sure we pass at least one full > frame, the > decoder is asked what it's worst case encoded frame size is. > This value > is used in X above. > > If you are using a transport stream where you know the size > of the next > encoded frame this logic is not needed, as you know the exact > amount of > data to pass to the VIDDEC_process() call every time. > > As to why this isn't done for audio, it's basically because > audio frames > are a lot smaller and we are pretty sure we'll give the > decoder at least > a frame every time. But perhaps we should for consistency. > > Best regards, > Niclas > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Anil > Sent: Friday, September 01, 2006 8:38 AM > To: [email protected] > Subject: Question on DaVinci EVm Demo apps > > > Hi, > > I have got a question on Codec Engine demo application in > DaVinci-Linux. I was reading through the decoder application > source code > to get an idea about the buffer allocation schemes. The demo > application > has support for audio, speech and video decoder. For audio decoder and > speech decoder the inputBuf size is decided by the application itself, > whereas for the video decoder the inputBuf size is > decided/queried using > the VISA function "VIDDEC_control" > with the cmd_id "XDM_GETBUFINFO". Why is this not done for > the other two > decoders (audio and speech) ?? > Also the from the header file "xdm.h" it is evident that in the > structure "XDM_AlgBufInfo", minOutBufSize field can give the outputBuf > size, then why is not being used in any of the decoders ?? > > Warm Regards, > Anil > > > -------------------------------------------------------DISCLAI > MER------- > ----------------------------------------------- > The information transmitted herewith is confidential and proprietary > information intended only for use by the individual or entity to which > it is addressed. If the reader of this message is not the intended > recipient, you are hereby notified that any review, retransmission, > dissemination, distribution, copying or other use of, or taking of any > action in reliance upon this information is strictly > prohibited. If you > have received this communication in error, please contact the > sender and > delete the material from your computer. > -------------------------------------------------------------- > ---------- > -------------------------------------------------------- > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > -------------------------------------------------------DISCLAI > MER------------------------------------------------------ > The information transmitted herewith is confidential and > proprietary information intended only for use by the > individual or entity to which it is addressed. If the reader > of this message is not the intended recipient, you are hereby > notified that any review, retransmission, dissemination, > distribution, copying or other use of, or taking of any > action in reliance upon this information is strictly > prohibited. If you have received this communication in error, > please contact the sender and delete the material from your computer. > -------------------------------------------------------------- > ------------------------------------------------------------------ > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
