This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Invalid 'chnId' when calling MCFW Vdec_requestBitstreamBuffer()

Good Afternoon,

I've been using MCFW to implement a h.264 decoder using Vdec_requestBitstreamBuffer() and Vdec_putBitstreamBuffer(). Unfortunately, there seems to be a problem where sometimes?  Vdec_requestBitstreamBuffer() returns invalid buffers ... which means that we can't display anything. Furthermore, sometime it returns with a list of (eg 64) buffers but only one of them has a valid chId, meaning we only display 1 of our (4) channels.

After verifying our application follows the general flow of 'mcfw_demo', it seems that I can "reproduce" it using the 'mcfw_demo' (please see code below). 

At any rate, I'm unsure how to proceed to fill the bitstream buffers if the 'chnId is invalid. Perhaps someone could verify that I'm calling Vdec_putBitstreamBuffer() correctly?

Regards,

--Leon | Vocal Technologies 

MCFW_DEMO EXAMPLE:
-->/opt/DM8168_DVRRDK_V03.00.00.00/dvr_rdk/demos/mcfw_api_demos/mcfw_demo/demo_vcap_venc_vdec_vdis_bits_rdwr.c
-->VcapVencVdecVdis_ipcBitsQueEmptyBitBufs() -- LINE ~565 -- (i.e. close to 'Vdec_requestBitstreamBuffer()')
Vdec_requestBitstreamBuffer(&reqInfo, &emptyBufList, 0);
for (i = 0; i < emptyBufList.numBufs; ++i) {
printf("[VDEC] request:%02d/%02d| chnId:%02u, strmId:%u, seq:%03u, dND:%u, size:%06u, filled:%06u, timestamp:%04u, w:%d, h:%d \n", i+1, emptyBufList.numBufs, emptyBufList.bitsBuf[i].chnId, emptyBufList.bitsBuf[i].strmId, emptyBufList.bitsBuf[i].seqId, emptyBufList.bitsBuf[i].doNotDisplay, emptyBufList.bitsBuf[i].bufSize, emptyBufList.bitsBuf[i].filledBufSize, emptyBufList.bitsBuf[i].timestamp, emptyBufList.bitsBuf[i].frameWidth, emptyBufList.bitsBuf[i].frameHeight);
}
# Example output 
[VDEC] request:01/64| chnId:1782236035, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:1824191379, w:792804460, h:566312044
[VDEC] request:02/64| chnId:3533849900, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:3172565730, w:760847043, h:223976131
[VDEC] request:03/64| chnId:1640313964, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:818229356, w:-2041445485, h:-868694125
[VDEC] request:04/64| chnId:760847059, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:3532014644, w:1117930780, h:-567917267
[VDEC] request:05/64| chnId:3424306098, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:3325740947, w:843328620, h:331689064
[VDEC] request:06/64| chnId:331684908, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:760847043, w:760847043, h:760847043
[VDEC] request:07/64| chnId:3531875624, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:1386637080, w:-1925528685, h:-871185997
[VDEC] request:08/64| chnId:2486879635, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:545537124, w:-760848124, h:-794679980
[VDEC] request:09/64| chnId:760912515, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:630823619, w:283475052, h:860171884
[VDEC] request:10/64| chnId:835001452, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:3425338263, w:762698467, h:760780995
[VDEC] request:11/64| chnId:3229639700, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:3534112060, w:-432848237, h:1698204299
[VDEC] request:12/64| chnId:473482171, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:398556512, w:851517548, h:834997372
[VDEC] request:13/64| chnId:761108675, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:779737793, w:1353606456, h:-803068628
[VDEC] request:14/64| chnId:549458024, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:1278919315, w:-332766309, h:-988118633
[VDEC] request:15/64| chnId:3534120252, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:3500548156, w:701018819, h:1828821059
[VDEC] request:16/64| chnId:3423781651, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:4085585260, w:319106124, h:1674394860
[VDEC] request:17/64| chnId:746428931, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:744069825, w:-2085206724, h:-756652612
[VDEC] request:18/64| chnId:853883940, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:3425346515, w:1153155991, h:-869252461
[VDEC] request:19/64| chnId:3526763900, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:4071028020, w:760847075, h:222927555
[VDEC] request:20/64| chnId:1210761874, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:860306508, w:-1312412436, h:868490348
[VDEC] request:21/64| chnId:760847043, strmId:0, seq:000, dND:0, size:414720, filled:000000, timestamp:760781315, w:-660118212, h:-744069828
  • Can you pls share the following info:

    What is the value of :

    -- ipcBitsOutHostPrm.bufPoolPerCh

    -- ipcBitsOutHostPrm.numBufPerCh

    Can you pls paste your code where you invoke

    Vdec_requestBitstreamBuffer(&reqInfo, &emptyBufList, 0);

    Mainly what values are you setting for reqInfo

    ALso can you check for return status of Vdec_requestBitstreamBuffer if it is not in error

  • Hi Badri,

    In my application, the values are as follows, and indeed I already do check that Vdec_requestBitstreamBuffer() returns with (a) ERROR_NONE and (b) with at least 1 ".numBufs".

    VDEC_BUF_REQUEST_S vbuf_request;
    VCODEC_BITSBUF_LIST_S vbuf_list;
    vbuf_request.numBufs = VCODEC_BITSBUF_MAX;
    vbuf_request.reqType = VDEC_BUFREQTYPE_BUFSIZE;
    for (i = 0; i < VCODEC_BITSBUF_MAX; ++i) {
    vbuf_request.u[i].minBufSize = 800 * (600 / 2); // YUV4:2:0 of 800x600
    }
    ...
    vbuf_list.numBufs = 0;
    status = Vdec_requestBitstreamBuffer(&vbuf_request, &vbuf_list, 0);
    ...
    example_fill_dec_buffer(vbuf_list.bitsBuf[i]); 

    Vdec_putBitstreamBuffer(&vbuf_list);


    As for your question about 'ipcBitsOutHostPrm.bufPoolPerCh + .numBufPerCh', These seem to set internally by the MCFW usecase (i.e.  'progressive 16ch vcap venc vdec vdis') and so I've left them unaltered. 

    --Leon | Vocal Technologies 

  • When request type is VDEC_BUFREQTYPE_BUFSIZE, the channelId returned by Vdec_requestBitstreamBuffer are not meaningful. The buffers are allocated from a common empty buffer pool and channel number are not populated.The application should not refer to the channelId.It is expected that application populates the channelId before invoking Vdec_putBitstreamBuffer.