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.

1920x1080 H.264 encode demo on DM6467

Other Parts Discussed in Thread: TVP7002

Hi, I'm a new user of the 6467 DVEVM.

I've been trying to modify the "encode" demo that is included with the DVSDK to allow encoding of 1080 video.  Simply changing the maxHeight and maxWidth parameters in the VIDENC1_Params struct is apparently insufficient, as the Venc1_create() call keeps failing to create the encoder.  I've also tried rounding these to the nearest multiple of 16, with similar lack of success.  What else is required to successfully create the encoder for 1920x1080 video?  I was under the impression that the DM6467 was capable of encoding and decoding HD video at 1080 resolution, but the demos all seem to restrict to <= 720.  The Venc1_create() call just fails without much useful information.

Has anyone had any success in encoding 1080 video on this platform?

I appreciate whatever help you can provide,

Doug Reher

 

  • Do you do any effort about HDVICP subsystem?

    ---

    Wang

  • As you pointed out, the demos are written to support up to 720p; if you like to support 1080i, you would certainly need to modify more  than just the VIDENC_params... what comes to mind is all the video buffers required by the drivers as well as the demo application would need to be adjusted to support 1080i capture

  • For our modification, we actually just read in a 1080 YUV video file, we haven't used the capture yet.  What, specifically, would need to be changed in the driver code?  Do the drivers not already support 1080 encoding and output?

  • We didn't do anything with HDVICP, only modified the "encode" demo application to read in a 1080 YUV video file and attempt to create the encoder to do H.264 encoding on it.

  • Douglas Reher said:

    For our modification, we actually just read in a 1080 YUV video file, we haven't used the capture yet.  What, specifically, would need to be changed in the driver code?  Do the drivers not already support 1080 encoding and output?

    The Linux drivers support capture and display, the encoding (optional) is done at the user application layer (e.g. encode demo calls on codec engine APIs to do this).  That said, I just looked at the PSP documents included with DVSDK 1.40 where you will find documents describing the capabilities and contraints of capture and display drivers.  It appears that 1080i is supported by the drivers.  But we still need to take into account the application (encode demo). 

    Have you modified the encode demo to allocate the correct size buffer for 1080 resolution and pass it along to encode algorithm (via codec engine APIs) for encoding? 

  • Yes, we used BufTab_create to create a buffer table of 1920x1080 buffers, and got the output buffer handle from this table.

    Thanks for your help, by the way, we've been trying to navigate the many documents included with the SDK to try to make sense of all of the interfaces, but that's an extremely long process.  It's very nice to have someone point us in the right direction!

  • So I guess no one's actually successfully encoded 1080 video using h.264 on this platform?  So far, I have not received any concrete suggestions for creating the encoder object to allow this.

  • Hi,

    Try below: (i have not tested yet.)

    ===========================================================================

    DM6467 - Encoding in 1080i with DMAI

    change the source code of  "capture.c" as shown below to make encoder of
    DM6467 demo working for 1080I as shown below and compile it.

        /* Calculate the dimensions of a video standard given a color space */
    #if RES_720
        if (BufferGfx_calcDimensions(VideoStd_720P_60,ColorSpace_YUV422PSEMI,&gfxAttrs.dim) < 0) {
    #else
        if (BufferGfx_calcDimensions(VideoStd_1080I_30, ColorSpace_YUV422PSEMI,&gfxAttrs.dim) < 0) {
    #endif
            ERR("Failed to calculate Buffer dimensions\n");
            cleanup(THREAD_FAILURE);
        }

        /* Calculate buffer size needed of a video standard given a color space*/
    #if RES_720
        bufSize = BufferGfx_calcSize(VideoStd_720P_60, ColorSpace_YUV422PSEMI);
    #else
        bufSize = BufferGfx_calcSize(VideoStd_1080I_30, ColorSpace_YUV422PSEMI);
    #endif

        if (bufSize < 0) {
            ERR("Failed to calculate size for capture driver buffers\n");
            cleanup(THREAD_FAILURE);
        }

        /* Create a table of buffers to use with the device drivers */
        gfxAttrs.colorSpace = ColorSpace_YUV422PSEMI;
        hBufTab = BufTab_create(NUM_DRIVER_BUFS, bufSize, BufferGfx_getBufferAttrs(&gfxAttrs));

        if (hBufTab == NULL) {
            ERR("Failed to allocate contiguous buffers\n");
            cleanup(THREAD_FAILURE);
        }

        /* Create capture device driver instance */
        cAttrs.numBufs = NUM_CAPTURE_BUFS;
        hCapture = Capture_create(hBufTab, &cAttrs);

        if (hCapture == NULL) {
            ERR("Failed to create capture device, 720P component input connected?\n");
            cleanup(THREAD_FAILURE);
        }

        videoStd = Capture_getVideoStd(hCapture);

        /* We only support 720P capture */
    #if RES_720
        if (videoStd != VideoStd_720P_50 && videoStd != VideoStd_720P_60) {
    #else
        if (videoStd != VideoStd_1080I_30 && videoStd != VideoStd_1080P_30) {
    #endif
            ERR("Need 720P composite input to this demo\n");
            cleanup(THREAD_FAILURE);
        }

     

    Then you should change the memory configuration of the encoder to work for
    1080I. So please change the loadmodules.sh script as shown below before
    running the encode demo.

    # insert cmemk, tell it to occupy physical 120MB-200MB and create enough
    # contiguous buffers for the worst case requirements of the demos.
    rmmod cmemk.ko
    # one times 4MB, 10 times 3.5 MB,10 times 1.5MB etc
    #insmod cmemk.ko phys_start=0x87800000 phys_end=0x8ba00000 pools=1x4147200,10x3458400,10x1434240,11x663552,4x60000

    # 10 times 4MB, 1 times 3.5 MB,10 times 1.5MB etc
    insmod cmemk.ko phys_start=0x87800000 phys_end=0x8ba00000 pools=10x4147200,1x3458400,10x1434240,11x663552,4x60000

    # insert dsplinkk, tell it that DSP's DDR is at physical 250MB-254MB
    rmmod dsplinkk.ko
    insmod dsplinkk.ko

    # alter dma queue mapping for better visual performance
    if [ -f mapdmaq-hd ]
    then
        ./mapdmaq-hd
    fi

    # make /dev/dsplink
    rm -f /dev/dsplink
    mknod /dev/dsplink c `awk "\\$2==\"dsplink\" {print \\$1}" /proc/devices` 0


    This should make it working for 1080.


    Currently the encoder will not encode at 30 frames persecond. I do not
    remember exactly how many frames per second it can encode.

    ==========================================================================

  • Hi Tai Cheng.  I found that portion of code online as well, but that does not work.  Still there is an error "Failed to open codec engine encode".

    Although the specs indicate that the CE can encode 1080 H.264 video, there appears to be an error somewhere that prevents it from being used for this resolution.  It seems that this Davinci platform does not actually support 1080 encoding.  Is there an alternate platform that anyone can verify does actually encode 1080 video?  Or can anyone send verified code that allows for 1080 encoding?

    This is getting extremely frustrating.

  • Sorry to butt in, but should the "levelIdc" in struct "IH264VENC_Params" be changed as well?

    I'm really frustrated as well and I badly need to encode 1080 video on this platform, so please anyone can tell us whether it's possible ?

    thanks

  • Well, it's now been over a month, and still no response, so I have to conclude that the DM6467 is not capable of 1080 H.264 video encoding at any frame rate.  This is extremely disappointing.  It's very frustrating that the codec engine simply fails to open, without any indication of what the problem is or if there is an invalid parameter.  According to the documentation, it should be possible, and everything else seems to work properly.  The codec engine just fails silently.

     

    Is there another support channel available through TI to attempt to get some help with this issue?

  • Well these guys in Ingenient seem to have achieved 1080p encoding on DM6467...

    http://www.youtube.com/watch?v=b-KtLDBE9zM

    So it looks like either we start upgrading the default encoder on our own or pay for a new one capable of 1080p encoding.

     


  • Hi everyone,

    I apologize for the delayed response on this; between my business travel and other tasks, I am just starting to catch up again with some of the forum threads.  I have gone thru the corresponding codec data-sheets and user guides (where I would expect to see more detailed information on a particular codec version), but unfortunately, I have not been able to verify max supported resolution.  The User Guide does mention that x resolution must be multiple of 16; this is due to 32-byte alignment required by the underlying hardware; aside from that, I do not see any clear reason why the call to open codec engine or create the codec instance would fail.  From a hardware processing power point of view, it should certainly be possible to use 1080 resolutions at lower frame rates; so we just need to ensure the software is in place to do this. 

    To this end, I have asked our internal codec team to provide feedback on the codec capabilities of supporting 1080 resolutions and we will post that information as soon as we get it.

    That said, the codec is only part of the equation, the software drivers (if planning of displaying or capturing) and the demo application also need to support 1080 resolutions; otherwise, how do you plan on testing once we get past codec engine issues...  Well, I can confirm that our drivers and demos support up to 720p resolutions only.  Therefore, you will need to modify source code to support 1080 resolutions.  Just a heads up of the additional work that may be required; at the moment, it seems we first need to figure out if the codec(s) can support 1080.

  • Juan/Everyone,

    The codec which is released with DVSDK can support only 720p resolution. It is not a matter of changing the MaxWidth and MaxHeight.; there need to be changes in the codec library to enable 1080p encode.

    TI is developing a 1080p@30 fps encoder on DM6467 (675 MHz part), and the codec will be available by 30th September, 2009. I will have to check on the plans as to when the new DVSDK with this codec will be available. Will post an update on that. But I want to confirm that DM6467 is indeed capable of doing1080p 30fps encode and TI internally is developing this codec. Note that this codec is different from the current 720p encoder that has been released witht he DVSDK. The Motion Estimation algorithm is different between the 2 encoders, and the 1080p 30 encoder also supports H.241 feature (multiple slices based on fixed number of bytes).

    Please do let me know if you have any questions on this.

    Regards,

    Kapil

     

  • Is the 675Mhz part a new one?

    As far as I know there  are two different orderable parts (594Mhz and 729Mhz)

     

    BTW, Thank you very much Kapil for your update.

  • Will the EVM shown in

    http://focus.ti.com/docs/toolsw/folders/print/tmdsevm6467.html

    support 1080p@30 fps encoding if the new codec is available?

  • Sergi Creus said:

    Is the 675Mhz part a new one?

    Yes and No; this is a new part but is NDA and will likely not be available for the mass market.  Depending on the performance level you are looking for, the choices are 594 MHz and 729 MHz for all practical purposes.  The current DM6467 EVM supports both these speed grades (includes 729 MHz part).

    We plan on taking out a 1GHz version of DM6467 to the mass market probrably by year end; a new EVM will be available to support this part.

  • The 1080p30 H264 encoder will be real time on the 729 MHz  DM6467 

    Regards,

    Kapil

  • boron said:

    Will the EVM shown in

    http://focus.ti.com/docs/toolsw/folders/print/tmdsevm6467.html

    support 1080p@30 fps encoding if the new codec is available?

    This EVM supports 594 MHZ and 729 MHz DM6467.  With 594 MHz, you will likely reach a max of 1080p @ 25 fps.  With the 729 MHz, we should have a codec soon (if we do not already) that can handle h.264 1080p BP @ 30.  This codec will likely not appear in any DVSDK release yet and will probrably make it into the next one.  If you need h.264 encoding of 1080p @ 60 fp, then you will likely need to wait for 1 GHz version of DM6467, although it is too early to tell as codec testing on the 1 GHz version are not complete yet.

  • Hello.  Just saw this and wanted to comment.  ingenient does have a 1080i H264 decoder and encoder that runs using DVSDK 2.00.00.22 (for what it's worth, we also have 1080i MPEG-4 encode/decode and 1080i MPEG-2 encode/decode in xDM packages available).  Evaluation versions (watermarked, limited to 2 minutes) which run on a 594MHz DM6467 EVM are available for evaluation free of charge.   If you're interested, just let me (or, alternately, sales@ingenient.com) know.

    We did have to modify the Codec Engine framework to support 1080i capture and display.  We found it was pretty easy -- just a matter of changing a few parameters (the people that wrote Codec Engine had already done all the heavy lifting on this -- we just had to change some parameters to specify what we wanted, and make a mod to loadmodules to increase buffer sizes a bit).  These modifications are included in the evaluation version so that codecs can be run "out of the box."  (It may be possible that the latest DVSDK already includes support for 1080i capture/display with *no* mods -- we were working with the "early adopter" version 2.00.01.15).

          -Robert

     

     

  • rchen said:
    We did have to modify the Codec Engine framework to support 1080i capture and display.  We found it was pretty easy -- just a matter of changing a few parameters (the people that wrote Codec Engine had already done all the heavy lifting on this -- we just had to change some parameters to specify what we wanted, and make a mod to loadmodules to increase buffer sizes a bit).  These modifications are included in the evaluation version so that codecs can be run "out of the box."

    Any way we could get some more details on what you had to change in Codec Engine?  If there are changes we need to make to the mainline, I'd like to understand them (and integrate them!).

    Feel free to contact me privately if you like.

    Thanks.

    Chris

  •  

    Chris,

    Absolutely!  The changes weren't a real big deal.  I'll contact you off-line about this.

        -Robert

  •  

    For the record, no changes were needed for 1080i display (that was already supported).  The 1080i capture support was simply a matter of changing the buffer size calls to use 1080i instead of 720p as the reference point and modifying the buffer sizes in loadmodules.sh to accommodate the larger capture buffers.

       -Robert

  • Hi,

    Is there an update as to the availability of this encoder?  We would very much like to use the DM6467 in a new product.  1080p realtime encode is a design requirement.

    Thanks!

  • Jim Klingshirn said:
    Is there an update as to the availability of this encoder?

    Currently I would recommend working with your local TI contact to gain access to the 1080p30 encode codec.

    Please keep in mind that though the codec can support 1080p30 the DM6467 EVM hardware cannot (specifically the TVP7002 cannot capture 1080p30), so testing out this capability in real time is not easy to do out of the box.

  • Just wanted to clarify whether you meant that the current hardware cannot capture 1080p30, though it can capture 1080i30.

         -Robert

  • rchen said:
    Just wanted to clarify whether you meant that the current hardware cannot capture 1080p30, though it can capture 1080i30.

    This is correct, the TVP7002 is not able to operate on a VSYNC frequency less than 40Hz so for progressive formats that have a single VSYNC period per frame one cannot capture less than 40 fps with TVP7002, however interlaced content effectively doubles the VSYNC frequency so it is fine.

  • I meet the same problem too. The engine can not be opened! Ti

    has not a instruction how to use the codecs.

  • The hardware (DM6467) can support 1080P30, however the EVM has a daughter card interface with which you need to use the VPIF in order to allow for frequencies up to 99 Mhz, our team has created a daughter card and is trying to rewrite some of the dvsdk in order to do 1080p30. Hopefully this new sdk that came out in september? helps.

  •  

    Hi,

    Could anyone post de reference part and the manufacturer of the daughter card Brian is talking about.

     

    Thank you veery much

  • Douglas Reher said:

    Has anyone had any success in encoding 1080 video on this platform? 

    The following article was written from a DM365 perspective, but if you are using DVSDK 2.0, it should apply to DM6467 as well

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

    I have not tried this myself, but I think it will give you a better understanding of the various places affected when adding 1080i support.

    [EDIT]: never mind, I think I jumped the gun here.  It appears you already soved the 1080i support issue.

  • The daughter card that I am refering to was done in house by university enterprise team.

    Kapil, Where is that new dvsdk that was to come out for the dm6467? All I see is the new dvsdk for the 1 Ghz platform.

    Brian

  • Brian,

    I believe that this DVSDK 3.10 beta also applies to DM6467, at least the PSP (aka. linux kernel) release notes would appear to indicate this

  • Small comment on the DVSDK 3.10 for DM6467, though the PSP does appear to be tested, currently many of the components of the 3.10 DVSDK are not currently validated on the DM6467, but rather just on the DM6467T and DM365. This being said, in general I would not recommend the DVSDK 3.10 beta for the plain DM6467 just yet (though it may work in some capacity), you can expect more complete DM6467 support as well as DM355 for DVSDK 3.10 in the coming months.

  • Bernie, thanks for the info about DVSDK 3.10 stabilizing for the plain 6467 over the coming months. I've been reading this thread hoping to discover as much as I can about 1080p30 support for the two 6467(T) DVEVM boards.

    The specs for the DVEVM for the T part indicate that its DVSDK contains "TIs H.264 1080p60 decoder". The specs for the older part (no T) indicate an encoder and decoder. Do you know whether the encoder example for DM6467T DV EVM supports capture of live (say from a PS3) 1080p30 to h.264 out of the box?

     

  • I see from the SpectrumDigital docs that the dm6467t DVEVM has the same input video part, the TVP7002, which was discussed on the previous page. I think that clearly indicates that it will be incapable of doing 1080p30. That's okay since our board will have a different device up front.

    But I would feel much more comfortable if I could prove to my boss that there exists a decent 1080i60 h.264 encoder for the 6467, with or without a 't'. If not we may be forced to change products.

    I saw the exchange last October between Robert Chen of Ingenient and TI's own Chris Ring about putting the 1080i changes on to TI's mainline. Did that happen?

    I'm a relative newb to TI's video architecture, so I apologize if I've missed something really obvious. Is there a place to download updates to the DVSDK that would include the 1080i encoder?

    Many thanks.

     

  • Doug,

    I'm another Doug in the same position, looking for verification that TI can provide a 1080p30 codec (without TOO much work on my part) by checking 1080i60 on the dm6467t DVEVM.

    Did you ever get a resolution to this? Did you ever make contact with, or receive contact from, Ingenient?

    Doug

     

  • Doug,

    TI has a 1080p30 H264 encoder on 729 MHz DM6467 which is avalable for download frpm: http://software-dl.ti.com/dsps/dsps_public_sw/codecs/DM6467/index_FDS.html

    Regarding the 1080i60 encoder, we currently do not have the support for interlaced encoding in the H264 encoder. The DM6467 729 MHz  part is capable of doing 1080i60  encode, but we currently do not have the codec for this.

    Regards,

    kapil

  • Kapil,

    Thank you so much for your reply.

    I've definitely downloaded that codec, h264fhdvenc, and I've got it installed in my codec server (I removed everything else). Just for the record, here's what I've got installed:

      dvsdk_3_10_00_11, codec_engine_2_25_01_06, cs2dm6467_1_00_00_03, dmai_2_10_00_05, dvsdk_demos_3_10_00_09 

    I've gotten to the point where Doug Reher was - modifying the encode application that comes with the DVSDK to the point where Venc1_create() returns NULL. My next step was to dig into the ARM-side libraries. I was hoping to avoid mucking with the DSP-side code. I also modified (small) portions of the DMAI library and got rid of the register dumps from the TVP7002 Linux driver (for whatever that's worth).

    Are you sure the interlaced encoding is not supported? Robert Chen from Ingenient says it works with some simple mods. I see in h264_encoder_dm6467_userguide.pdf, page 4-25 section 4.2.2.2 IH264FHDVENC_DynamicParams, that ME1080iMode is "Not supported in this version of H264 Encoder". Similarly in Chapter 5, the very first answer gives the settings necessary for 1080i, but it goes on to say that it doesn't support one of them.

    Is it possible that the 720P encoder (h264enc with DVSDK 3.10) is the one that needs tweaking? At least with the new DVSDK bundle, 1080I_30

    If it really isn't supported, then we'll have to move on.

    BTW, I've noticed some inconsistency in how the scheme is written in some of the documentation and code. In some places it is called 1080i60, in others 1080i30. I think it should be the 1080i60 or 1080i/30. See http://en.wikipedia.org/wiki/1080i. I admit I'm a novice; I bought a 1080p TV last year, but until a month ago that was the extent of my exposure to the names!

    I will keep trying unless you're 100% sure that it is a futile effort.

    Chris Ring, did the buffer size changes, etc., from Ingenient ever make it onto the mainline?

    Thanks again.

    Doug

  • Hello,

    This is with reference to the DM6467 Demo Beta release uploaded in September 2009.

    Is it feasible to run the demo on DM6446 ?

  • I wanted to respond to some of the questions regarding 1080p/30 (apologies for the late response -- I've been on a few business trips recently).

    First, regarding:

        Are you sure the interlaced encoding is not supported? Robert Chen from Ingenient says it works with some simple mods. I see in h264_encoder_dm6467_userguide.pdf, page 4-25 section 4.2.2.2 IH264FHDVENC_DynamicParams, that ME1080iMode is "Not supported in this version of H264 Encoder". Similarly in Chapter 5, the very first answer gives the settings necessary for 1080i, but it goes on to say that it doesn't support one of them.

    I wanted to point out the difference here between the Codec Engine framework and the encoder running within it.  The mods we made were to the Codec Engine framework.  That, coupled with an encoder that supports 1080i, should be able to handle 1080i.  It is possible to do the mods and still not support 1080i if the underlying encoder does not support this.  My guess is this is what might have been encountered.  I wanted to reiterate that ingenient (now Sasken Inc) has a 1080i H264 encode xDM evaluation package available for those interested that does run on the EVM (also 1080i MPEG-2, 1080i MPEG-4).  We also have a 1080i MJPEG encode/decode package that maintains 1080i/30fps as a closed system (not yet integrated into Codec Engine, though ...).   TI might also have 1080i H264 now.  You might want to check with them.

    Regarding 1080p/30, I wanted to point out that it is important when demonstrating this that the capture engine capture 1080p/30 content (rather than capture 1080i/60 and attempt to encode one field as progressive to simulate 1080p/30 performance).  We've found that a 1GHz DM6467 (the version with the 150MHz video clock) is necessary for this -- the reason is 150MHz is needed for 1080p/60 capture, which is the only way to get the 1080p/30 input.  We do have a demonstration using a board we designed that takes in 1080p/60 through HDMI, encodes it at 1080p/30, and then plays the resulting content via HDMI which can be used to evaluate 1080p/30 quality and performance (I think the results look pretty good, though I admit some bias in this regard :) ).  If anyone is interested in seeing this, let me know.

    Hope this helps.

        -Robert

     

     

  • rchen said:
    I wanted to point out the difference here between the Codec Engine framework and the encoder running within it.  The mods we made were to the Codec Engine framework.

    A minor note, since mods to Codec Engine typically aren't required, and general statements like this can lead to uncertainty.  I think in this case, the changes I heard about off thread were the following:

    • DMAI's capture.c required some additional support to handle 1080i Buffer size calculations
    • The CMEM driver's configuration (command line params provided during insmod) required appropriate config for larger buffer sizes.

    The first would be a nice enhancement to DMAI.  The second is an expected customization that each system integrator will have to make based on their system needs.

    If there were other mods required, please post them here for clarity.  Thanks.

    Chris

  • Chris is absolutely right.  When I was thinking "changes to Codec Engine" those were the 2 changes I was thinking of.  Thank you Chris for the clarification.

        -Robert

     

  • Robert and Chris,

    Thanks for your replies.

    We have gone through our TI local rep to get access to the 1080p encoder demo application. It runs and encodes 1080p30 from a live 1080i60 signal on the component inputs using the h264fhdvenc encoder. While it is not ideal (DVSDK 1.40), it will suffice as an extreme sort of fallback position. I can imagine it is a lot of work for TI to keep all the software up-to-date for each platform, but hopefully we'll see the h264fhdvenc encoder integrated into the 3.10 DVSDK soon. I set aside some time to work on it myself, but I need to move off to other development tasks and I doubt that I'll get it working in the limited time I have.

    Thanks again.

    Doug

     

  •  

    Doug,

    Glad to hear you were able to find a solution that works for you.

       -Robert

     

  • Can I download 1080p encode/decode demo some whrere?  Thanks.

  • I'd also like to get hold of this if possible....