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.

DM8168 - H.265

We use DM8168 with DVRRDK software platform and Udworks based hardware design.

For future developments it is interesting for us to know if H.265 codec will be provided.

Will DVRRDK support H.265 software codec in future ?

 

  • It is not possible to support H265 (HEVC) on 8168 as the HDVICP IP that accelerates encode/decode is not capable of supporting H265 standard.

  • Thanks, for the information.

    Will any other platform from TEXAS INSTRUMENTS support H.265 for DVR application ?

  • HEVC implementation is available on c6678 which is a Multicore TI DSP  part of the Keystone family of devices.

     http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprt661&fileType=pdf

    http://www.advantech.in/products/News.aspx?doc_id=21FD1283-5962-487F-834F-5387143FE6A7

    c6678 can connect to 816x via PCIe with c6678 as EP . I am not sure though whether you can meet the high channel densities required for DVR .

  • Thanks for this information, Best regards.

  • hi

    i am working on 8168+pcie+6678,i want to use 8168 capture or read video frames,then send to 6678 by pcie interface,6678 process the video frames with video process alg,then 6678 send the processed video frames to 8168.

    i want to ask should i use the mcfw in the dvr or use the video examples in the ezsdk?which is better for develop the 8168+pcie+6678 video process system?if i use the mcfw in the dvr,i feel that it is diffcult to modify and add codes related with pcie to 6678.if use the video examples in the ezsdk,i feel that i can use the examples to add codes related with pcie to 6678,it clear.

    and a important thing is that 8168 DMA transmit to 6678 by pcie,it use physical address,how to ensure alloced physical address is continue and have a size of 1080p video frame,then ensure the processed video display fluencily。

    do you have some experience or advices?

    thanks。best regards。

  • We have integrated 816x running DVRRDK with 6678 via PCIE for a internal evaluation project. The DVRRDK sends raw YUV frames via PCIe to 6678 and 6678 does analytics on the frame and 816x will use the analysis results to indicate motion detection,trip zone, object counting etc.

    Whether to use ezSDK or DVRRDK is upto you based on  your familiarity. The changes in DVRRDK itself is minimal. We ported mcsdk to 816x which implements user space samples to exchange frames with 6678.The Linux kernel on 816x already supports the  required PCIe driver .

    The physically contiguous buffers were allocated from SharedRegion by mcfw links.

  • thanks

    i have done the work,i use the demo_vedc_vids,in the ipcoutM3 link,i send the phyaddr of video frame to IPCbitsouthost link,the phyaddr of video frame is in the video frames section of memory map of DVR,all the video frames are in this section,phyaddr of every video frames is continue,is it?

    IPCbitsouthost link recieve this phyaddr of video frame,i use it to DMAwrite to 6678‘s DDR,after process,A8 DMAread from  6678‘s DDR,and A8 use original the phyaddr write to video frames section,the M3 go on its work.

    i want to know is my work right?

    can i get your example project?

  • You data flow for decode display should be:

    ipcBitsOutHost -> ipcBitsInVideoM3 -> decLink -> ipcFramesOutVideoM3 -> ipcFramesInHost

    assuming you want to export decoded video frames.

    You cannot use ipcOutM3 or ipcBitsIn link to export video frames to cortex A8.

    ipcFramesInHost will receive phyAddr of the frame.

    Each individual buffer will be physically contiguous.

    Video Frames will be allocated from SR2

    You are right about DMA in and DMA out of 6678 DDR. We also used same method.

    I didn't understand your point "and A8 use original the phyaddr write to video frames section". Once the frame is received back to A8, it is freed back to ipcFramesInLink using IpcFramesIn_putEmptyFrames API.

    I can share the DVRRDK code changes but I am not sure how useful it is to you as you have already created the usecase and data flow.The DVRRDK changes are mainly to create a  new usecase to export video frames to A8.

    Most of the changes were in c6678 mcsdk video to make sdk suitable for use in realtime embedded host environment and the code changes cannot be shared in forum.I am not aware of plans to include these changes in future mcsdk releases.

     

  • thanks very much.

    can you share your  DVRRDK code changes?ma mail is  2231578519@qq.com.

    if you cannot share your changes in c6678 mcsdk video,can i get the docs about your thinking.

    best regards.

  • hi

    you say you can share changes in the DVR about the project 816x pcie to 66x.can you share with me,my email is

     2231578519@qq.com.and in the c66x,how do you that,if you can not share,can you give your docs about your thinking or other help.

    thanks.best regards.

     

  • FYI MCSDK video release with support for Video Analytics is now available at http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk_video/02_02_00_39/index_FDS.html