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.

dm365 h264dec buf usage problem



hi, guys.

we have been working with Framecopy but we get serious problem that frames sometimes get lost from the internet which comes form an other device capture who puts h264 frames in internet, so we are going to check if the problems comes form the Framecopy implement....

Problem of h264dec in source code vdec2.c in dmai see 3364.Vdec2_process.rar

 Problem here:

Sometimes entries of outArgs.outputID[] are all zero, that means no decoded output.

 

If this happened, the hDstBuf will never be released, and all the buffers will be used until there are no free buffers, and the display and decode thread will be blocked. There are always 21 fames which have been decoded and displayed successfully, then stop.

 

 

     Question:

Why did this happen? One encoded buffer input should make one decoded buffer output, isn't it?

 

That's what I'm facing exactly and I found the thread here, but I cannot find it works with which has point out there. Here is what I had done indeed:

 

Call dm365_dec_init, dmai_Vdec2_init and dmai_Display_init to init the codec (see 2678.init.rar) and then pass h264 buff to dm365_vdec2_frame (see 6607.dm365_vdec2_frame.rar) with buf and size of buf.

 

We have enabled the print of the two buffs, say, hInBuf, hOutBuf_ch1,before Vdec2_process and the dami debug. This is what we got:

 

[0] @ 0x428cf000 (0x8675b000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 704, Height 480, LineLength 704

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 0 (524288) useMask 0 (1) ref no vSize 0

@0x022994b4:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 0 inUse 0 consumed 36192

[1] @ 0x42971000 (0x866b9000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 704, Height 480, LineLength 704

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 36192 (524288) useMask 0 (1) ref no vSize 0

@0x022a342d:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 1 inUse 0 consumed 6300

[2] @ 0x42a13000 (0x86617000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 704, Height 480, LineLength 704

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 6300 (524288) useMask 0 (1) ref no vSize 0

@0x022ad928:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 2 inUse 0 consumed 10672

[3] @ 0x42ab5000 (0x86575000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 704, Height 480, LineLength 704

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 10672 (524288) useMask 0 (1) ref no vSize 0

@0x022b1a70:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 3 inUse 0 consumed 4276

[4] @ 0x42b57000 (0x864d3000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 704, Height 480, LineLength 704

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 4276 (524288) useMask 0 (1) ref no vSize 0

@0x022b6cfd:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 4 inUse 0 consumed 7512

[5] @ 0x42bf9000 (0x86431000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 704, Height 480, LineLength 704

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 7512 (524288) useMask 0 (1) ref no vSize 0

@0x022bb969:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 5 inUse 0 consumed 9668

[0] @ 0x428cf000 (0x8675b000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 9668 (524288) useMask 0 (1) ref no vSize 0

@0x022bf2ca:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 0 inUse 0 consumed 4320

[1] @ 0x42971000 (0x866b9000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 4320 (524288) useMask 0 (1) ref no vSize 0

@0x022c2eec:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 1 inUse 0 consumed 7232

[2] @ 0x42a13000 (0x86617000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 7232 (524288) useMask 0 (1) ref no vSize 0

@0x022d3d52:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 2 inUse 0 consumed 13336

[3] @ 0x42ab5000 (0x86575000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 13336 (524288) useMask 0 (1) ref no vSize 0

@0x022d897b:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 3 inUse 0 consumed 3404

[4] @ 0x42b57000 (0x864d3000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 3404 (524288) useMask 0 (1) ref no vSize 0

@0x022dc597:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 4 inUse 0 consumed 5612

[5] @ 0x42bf9000 (0x86431000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 5612 (524288) useMask 0 (1) ref no vSize 0

@0x022ecb34:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 5 inUse 0 consumed 9804

[0] @ 0x428cf000 (0x8675b000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 9804 (524288) useMask 0 (1) ref no vSize 0

@0x022f06cb:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 0 inUse 0 consumed 4208

[1] @ 0x42971000 (0x866b9000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 4208 (524288) useMask 0 (1) ref no vSize 0

@0x022fa52f:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 1 inUse 0 consumed 7172

[2] @ 0x42a13000 (0x86617000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 7172 (524288) useMask 0 (1) ref no vSize 0

@0x023055ae:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 2 inUse 0 consumed 9376

[3] @ 0x42ab5000 (0x86575000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 9376 (524288) useMask 0 (1) ref no vSize 0

@0x0230f381:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 3 inUse 0 consumed 4256

[4] @ 0x42b57000 (0x864d3000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 4256 (524288) useMask 0 (1) ref no vSize 0

@0x0231a1d5:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 4 inUse 0 consumed 7436

[5] @ 0x42bf9000 (0x86431000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 7436 (524288) useMask 0 (1) ref no vSize 0

@0x02324ad7:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 5 inUse 0 consumed 9344

[0] @ 0x428cf000 (0x8675b000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 9344 (524288) useMask 0 (1) ref no vSize 0

@0x02328929:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 0 inUse 0 consumed 3936

[1] @ 0x42971000 (0x866b9000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 3936 (524288) useMask 0 (1) ref no vSize 0

@0x02338c0c:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 1 inUse 0 consumed 7060

[2] @ 0x42a13000 (0x86617000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 7060 (524288) useMask 0 (1) ref no vSize 0

@0x0233f3fd:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 2 inUse 0 consumed 9604

[3] @ 0x42ab5000 (0x86575000 phys) numBytes 506880 (506880) useMask 0 (1) ref no vSize 0

        Width 768 (704) Height 576 (480) Pos 32x48 LineLength 768 (704)

[0] @ 0x4282d000 (0x867fd000 phys) numBytes 9604 (524288) useMask 0 (1) ref no vSize 0

@0x0234910f:[T:0x455ad490] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret 0 inId 3 inUse 0 consumed 4276

 

thread id: 1546

Error: signal 11:

./xxx[0xa4f0]

/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0x40575610]

 

libdec.so(Buffer_getUserPtr+0x34)[0x402845c4]

libdec.so(Vdec2_process+0x678)[0x4028814c]

libdec.so(dm365_vdec2_frame+0x160)[0x40282c6c]

libxxx.so(_ZN19CPlayVideoOut_Ti36516DecodeVideoFrameER16__ANA_FRAME_INFO+0x60)[0x4010cdb8]

libxxx.so(_ZN9CRtvPanel20RealVideoPlayOutTaskEv+0x2c0)[0x40106508]

libxxx.so(_ZN9CRtvPanel17tVideoPlayOutTaskEPv+0x5c)[0x401065b8]

 

/lib/libpthread.so.0[0x4002c5f4]

/lib/libc.so.6(clone+0x88)[0x4060d368]

 

Any help will be appreciate~~~!

Regards, mike

Thanks.


  • Hi Mike,

    Look at the attached file  5722.video.c.gz   how i handled decoding from network.
    It is based on DVSDK DMAI decode demo.
    It's been a while since i was working on that issue, and i pretty much forget details, but i think it worked well in that way.

    Regards,
    Marko.

  • hi, Marko

    i saw you are using extnParams which is very different with VIDDEC2_Params i heard form some clip of e2e, they said it's an other thing.

    i dont know how much time will be used if i change to use extnParams, i do know i have many things to debug, say, each one in the params. i worry about that.

    btw, have you ever tried to pass NULL to Display_create? like Display_create(NULL, &dAttrs) ? i faced with  the data abort oop from the kernel and i dont konw what's going on.

    Regards, Mike

    Thanks, Marko.

  •  Hi Mike,
     
    It's not about codec parameters, as along as your decoder works good, so you don't have to change them.
    The problem you have is probably about lost frames(network packets), that's why decoder can not decode certain frames.
    You have to be able to deal with incomplete stream, when you work with network.
    So better look at how to handle buffers after bad decode, since you have to free them manually.

    I forgot there is a new  function "Vdec2_process_2"  that is used for decoding in DMAI.
    It is in /dvsdk_4.01.00.09_2/dmai_2_20_00_14/packages/ti/sdo/dmai/ce/Vdec2.c   8322.Vdec2.c.gz  . Also add the declaration of this function to  to "Vdec2.h" file.

    I haven't used display in the way you mentioned.

    Regards.

  • hi, Marko.

    there are frame lost even we have two device connected directlly by network cable.

    after test, if we just disable display layer, say form display_get, framecopy_exec to display_put, there is no frame lost (the decode is enabled).

    so i just wander, is it any problem cames form the display layer? or it's connect to the network layer ? in the kernel space ?

    i will also need to check the 2D copy i heard form the e2e website... any ideas ?

     

    i really appreciate your replay here since no one have any thing put here except us.

    regards, Mike

    thanks .

     

  • Hi,

    Maybe your display rate is lower then input stream rate.
    PAL display is 25fps, NTSC 30fps.
    Instead of completely disablw  display, try to skip, say every second frame from displaying, and see if it helps.
    Or try input stream with lower frame rate.
    Your framecopy should be DMA - in DMAI  fcAttrs.accel = TRUE, memcpy is too slow.

    Even if some frames are lost or incomplete, with code change from those two attached files, program should work fine. 

     Regards.

     

     

  • hi, Marko

    The frame is set in vpbe_encoder, see bellow:

    static struct vid_enc_mode_info vpbe_encoder_modes :

     

    .name = VID_ENC_STD_800x480,

    .std = 1,      

    .if_type = VID_ENC_IF_PRGB,

    .interlaced = 0,

    .xres = 800,   

    .yres = 480,   

    .fps = {50, 1},

    .left_margin    = 48,

    .right_margin   = 20,

    .upper_margin   = 20,

    .lower_margin   = 8,

    .hsync_len      = 1,

    .vsync_len      = 1,

    .flags = 0

     

    I realized that fps is the frame rate, right ? I had even tried with 60 i saw in avnetlcd_encoder..

    I have checked the input source form network, it is just 25 frame/second.

     btw, i had tried with 13/20 fps in vpbe_encoder, but nothing changed.

    i had changed the Priority of the interrupt with EMAC = 2 and venc =6.but still.. there are frames lost.

     

    regards, Mike

    thanks .