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.

H264 and MPEG-4 HDVICP compatibility on DM368 question...

I'm using DVSDK 4_00_00_22 and have recently installed the latest codecs.  At the same time I switched from MPEG-4 MJCP to MPEG-4 HDVICP because I couldn't get the non-HDVICP decoder to decode the MPEG-4 stream.

My product streams up to 2 streams and decodes 1.  I was able to stream both H.264 and MPEG-4 MJCP at the same time with no problems.  However since changing the MPEG-4 to HDVICP the device locks up when I turn on the second stream using H264.  I can't even telnet into Linux.  It's frozen solid.

I am using the DMAI interface to control the codecs.  I have been using two H264 codecs at the same time so I didn't think there would be an issue of having 2 simultaneous codecs.  But now I'm not sure.

Also, I recently added the ability of streaming MPEG-2 but didn't have any issues.  But on reflection I'm not sure if I tested it with the H264 streaming at the same time. (note to self... try first thing in morning :) ).  Does the MPEG-2 codec use HDVICP or MJCP?

In addition, when I use MPEG-4 Decoder MJCP to decode the MPEG-4 MJCP encoded streams I kept getting a non-fatal bit error.  The funny thing is I was able to decode an MPEG-4 stream from another MPEG-4 encoder chip (different manufacturer).

JohnA

  • Encoder test...

    1 - H264 and 1 - MPEG-2 = OK

    2 - H264 = OK

    2 - MPEG-4 HDVCIP = OK

    1 - MPEG-4 HDVCIP and 1 - MPEG-2 = OK

    1- H264 and 1 - MPEG-4 HDVCIP = Frozen

  • Hi John,

    When system is frozen? I mean at very 1st frame or after processing some frames?

    Please share CE_DEBUG =2 level log.

  • Veeranna Hanchinal said:
    When system is frozen? I mean at very 1st frame or after processing some frames?

    Looks like during the first frame.  I have the H264 encoder active and running, then activate and start the MPEG-4 encoder.  The listing below shows the H264 encoder begin processing a frame and then the MPEG-4 encoder starts to process a frame.

    @27,147,176us: [+0 T:0x44df9490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x25ecf0, inBufs=0x44df8bc8, outBufs=0x44df8bbc, inArgs=0x44df8bac, outArgs=0x44df8b34)
    @27,147,556us: [+5 T:0x44df9490] CV - VISA_enter(visa=0x25ecf0): algHandle = 0x25ed28
    @27,147,711us: [+0 T:0x44df9490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x25ed28)
    @27,147,930us: [+0 T:0x44df9490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit
    @27,148,701us: [+2 T:0x4788f490] ti.sdo.dmai - [BufTab] Allocating BufTab for 4 buffers
    @27,150,736us: [+4 T:0x4788f490] OM - Memory_contigAlloc> CMEM_alloc(529920) = 0x47890000.
    @27,151,721us: [+4 T:0x4788f490] OM - Memory_contigAlloc> CMEM_getPhys(0x47890000) = 0x8c7a0000.
    @27,151,938us: [+2 T:0x4788f490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 529920 at 0x47890000 (0x8c7a0000 phys)
    @27,152,346us: [+4 T:0x4788f490] OM - Memory_contigAlloc> CMEM_alloc(529920) = 0x4792c000.
    @27,152,722us: [+4 T:0x4788f490] OM - Memory_contigAlloc> CMEM_getPhys(0x4792c000) = 0x8c704000.
    @27,152,943us: [+2 T:0x4788f490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 529920 at 0x4792c000 (0x8c704000 phys)
    @27,153,359us: [+4 T:0x4788f490] OM - Memory_contigAlloc> CMEM_alloc(529920) = 0x479c8000.
    @27,153,747us: [+4 T:0x4788f490] OM - Memory_contigAlloc> CMEM_getPhys(0x479c8000) = 0x8c668000.
    @27,153,991us: [+2 T:0x4788f490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 529920 at 0x479c8000 (0x8c668000 phys)
    @27,154,367us: [+4 T:0x4788f490] OM - Memory_contigAlloc> CMEM_alloc(529920) = 0x47a64000.
    @27,154,590us: [+4 T:0x4788f490] OM - Memory_contigAlloc> CMEM_getPhys(0x47a64000) = 0x8c5cc000.
    @27,154,989us: [+2 T:0x4788f490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 529920 at 0x47a64000 (0x8c5cc000 phys)
    @27,156,338us: [+5 T:0x44df9490] CV - VISA_exit(visa=0x25ecf0): algHandle = 0x25ed28
    @27,156,552us: [+0 T:0x44df9490] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x25ed28)
    @27,156,773us: [+0 T:0x44df9490] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit
    @27,157,108us: [+0 T:0x44df9490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Exit (handle=0x25ecf0, retVal=0x0)
    @27,157,269us: [+2 T:0x44df9490] ti.sdo.dmai - [Venc1] VIDENC1_process() ret 0 inId 0 outID 1 generated 4646 bytes
    @27,157,569us: [+2 T:0x44df9490] ti.sdo.dmai - [Buffer] Set user pointer 0x4409e000 (physical 0x8c134000)
    @27,157,798us: [+2 T:0x44df9490] ti.sdo.dmai - [Buffer] Set user pointer 0x4409e2e0 (physical 0x8c1342e0)
    @27,158,522us: [+0 T:0x44df9490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x25ecf0, inBufs=0x44df8bc8, outBufs=0x44df8bbc, inArgs=0x44df8bac, outArgs=0x44df8b34)
    @27,158,727us: [+5 T:0x44df9490] CV - VISA_enter(visa=0x25ecf0): algHandle = 0x25ed28
    @27,158,862us: [+0 T:0x44df9490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x25ed28)
    @27,159,074us: [+0 T:0x44df9490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit
    @27,160,057us: [+2 T:0x46eed490] ti.sdo.dmai - [Buffer] Set user pointer 0x43d8e000 (physical 0x8c444000)
    @27,160,321us: [+0 T:0x46eed490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x260d70, inBufs=0x46eecb28, outBufs=0x46eecb1c, inArgs=0x46eecb0c, outArgs=0x46eeca94)
    @27,160,561us: [+5 T:0x46eed490] CV - VISA_enter(visa=0x260d70): algHandle = 0x260da8
    @27,160,943us: [+0 T:0x46eed490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x260da8)
    2-MPEG4>@27,161,956us: [+2 T:0x466ed490] ti.sdo.dmai - [Capture] Checking video standard
    @27,163,687us: [+5 T:0x44df9490] CV - VISA_exit(visa=0x25ecf0): algHandle = 0x25ed28
    @27,163,878us: [+0 T:0x44df9490] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x25ed28)
    @27,164,329us: [+0 T:0x44df9490] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit
    @27,164,498us: [+0 T:0x44df9490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Exit (handle=0x25ecf0, retVal=0x0)
    @27,496,268us: [+2 T:0x44df9490] ti.sdo.dmai - [Venc1] VIDENC1_process() ret 0 inId 0 outID 1 generated 11019 bytes
    @27,496,722us: [+0 T:0x44df9490] ti.sdo.ce.video1.VIDENC1

    JohnA

  • I just tried putting a global mutex around the Venc1_process call for each encoder.  It froze again.  It was 3rd call on the MPEG-4 process after the H264 started when it froze.

    JohnA

  • Hi John,

    From log couldn't find any reason to hang, here whole system is getting hang(not sure about HDVICP state).

    We don't have this setup ready, we will try to have and run at our end.

    Can you provide some more level logs with below setup.

                         1: create MPEG4 process1,2,3 .. create H264 with debug lib and process both

                         2: create H264(debug lib), process1,2,3.. create MPEG4, process both.

       

    Thanks,

    Veeranna                

  • Hi,

    Are you using base or extended params, if extended, can you check the value of resetHDVICPeveryFrame? It should be set to 1.

    regards

    Yashwant  

  • Hi John,

    System with  MPEG4_hdvicp + H264Enc combination, getting hang.  And we are able to route cause the issue, its issue with h264 encoder.

    We will fix it make the release it may take 1-2 weeks. If you are blocked with this hang we can suggest some work around.

    And you also mentioned that MPEG4_ MJCP version decoder has issue to decoder TI's MPEG4_MJCP version Encoder's stream. Can you please share the stream?

    Thanks,

    Veeranna

  • It would be nice if I could implement a workaround.  This is a released product and it doesn't look good to go backwards.  I upgrade to the latest H264 codec to fix a problem with the codec crashing my app.  Unfortunately I don't have time right now to deal with the MJCP version of the MPEG-4 decoder.  The latest H264 encoder is causing other problems with my application.  It is generating poor quality streams where corruption builds up in the decoder only to be removed by restarting the decoder.

    <deleted some incorrect stuff>

    JohnA

  • I'm finding that running the latest H264 codec in interlaced mode is causing corrupted images in the decoder.  Both the DM368 decoder and VideoLan client.  This is code that worked fine on the H264 encoder that originally came with DVSDK 4.00.00.22.  After changing my application to tell the encoder to use progressive mode the corruption has gone away.

    It's a strange kind of corruption.  Horizontal lines start accumulating in the decoded image.  They aren't in the encoded stream, but build up in the decoder.  IOW, you can run another decoder on the same stream and not see the lines until they build up.  They aren't "stuck" in the decoder display buffer because if you move the camera the lines move with the image.

    JohnA

  • Right now I'm checking the encoder settings and disallowing both H264 and MPEG-4 at the same time.

    JohnA

  • Hi John,

    Here attaching one function, you need to call this function just before h264 encode process call. This function based on Physical address,  please convert "0x1C40000" address to virtual and use it.

    Regarding corruption, can you please share the stream and codec parameters.

    7522.temp_fix.txt

    Thanks,

    Veeranna 

  • Hi Veeranna,  I don't think I'm going to pursue worrying about the corruption as non-interlaced encoding is producing acceptable results.  This darn encoder has been my curse every since I found out the support software and drivers didn't support interlaced capture of 420 semi planer.

    I did implement chained capture of interlaced 420SP but the decoder displays strange vertical lines in the image during certain kinds of motion especially in the color red.  It's a fleeting entrainment like affect but very noticable. There are no lines in a still frame.  There must be motion to see them.  And they aren't apparent in VLC, only the DM368 decoder.  I've always been suspicious about the order that fields are captured being the cause of this because the first line captured is the second field (I.E. the even/bottom field), but haven't been able to get conclusive results.

    JohnA

  • Hi,

    Is work around solves MPEG4 + H264 problem?

    You mean DM36x decoder giving problem while decoding interlace sequence? and this visible when motion is there am I right?

    If this is the case I guess something wrong with Reference buffer management, there might be less number of buffers or wrong reference buffer feeding to decoder.

    You have posted this query earlier also http://e2e.ti.com/support/embedded/multimedia_software_codecs/f/356/t/96270.aspx?PageIndex=2

  • Hi Veeranna,  I haven't implemented the MPEG-4/H.264 fix yet.  Currently limit to one or other type of stream.  May wait for TI fix with new codec of if that takes too long then add the fix.  Mainly an issue of priority as they want me to look into the decoder lines.

    The other thread issues I have solved. But I think the problem with the lines I'm seeing does stem from that solution.  At this point I'm not thinking it's the decoder as I can decode MPEG-4 from another one of our products with a Micronus/WIS encoder and don't see the line.  I really think it has to do with the drivers that I've modified to get interlaced 420SP.

    JohnA

  • I finally know the reason why my MP4 can not be player, that's because of the wrong codec ...