TDA4VM: Gstreamer Decode YUV Data Problem

Kevin Peng

Part Number: TDA4VM

Hi TI Experts,

Customer is using TDA4VM SDK8.6. They are currently using Gstreamer for the encode & decode applications.

They are using the below command to decode the YUV data.

gst-launch-1.0 filesrc location=big-264.mp4 ! qtdemux name=demux demux.video_0 ! queue ! h264parse ! v4l2h264dec ! video/x-raw,format=NV12 ! filesink location=test.yuv

There is also no warnings or errors shown below.

However, the result of the output data seems not normal as below.

The data can be found in the following link.

183.63.174.35:807/.../

Could you help to provide some suggestions for this problem please?

Another problem related to it is that we found the CPU loading of using Gstreamer is pretty high shown below. We have learned that from SDK 8.5, edgeai is introduced to use tiovx within gst pipeline. May I know if edgeai plugins is helpful to reduce the CPU loading?

Thanks a lot!

Kevin

over 2 years ago

0 Brandon Brnich over 2 years ago

TI__Expert 3830 points

Hi Kevin,

Is the encoded video being used in that pipeline generated from the encoder found on the TDA4VM? Or is it just a generic 264 file that they are using for testing purposes?

Gstreamer will have a high CPU load as there is a lot of memory copying that is occurring between the elements in the pipeline. From my experience, I have not noticed the tiovx plugins to help reduce memory load too significantly from the decoder perspective.

Thanks,

Brandon

0 Kevin Peng over 2 years ago in reply to Brandon Brnich

TI__Expert 4198 points

Hi Brandon,

Thanks for your reply!

For question 1, customer is using a generic 264 filed downloaded from the below link.

http://183.63.174.35:807/video/

Customer has tested to use ffmpeg to decode this same file previously, & there is no problem. As we know from SDK8.x we moved to Gstreamer, customer tried to use the following command to decode, but has the problem described in this thread post.

gst-launch-1.0 filesrc location=big-264.mp4 ! qtdemux name=demux demux.video_0 ! queue ! h264parse ! v4l2h264dec ! video/x-raw,format=NV12 ! filesink location=test.yuv

May I know if there is any restriction on the format of 264 file using Gstreamer?

For question 2, thanks for your explanation, may I know if there is anything we could have a try? As mentioned in the below thread, the DMABuf import has been discussed but there seems no clear result of using it.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1175943/tda4vm-high-cpu-cost-of-a72-using-gstreamer-encodes-h264-stream/4573023?tisearch=e2e-sitesearch&keymatch=Gstreamer%252525252525252520cpu%252525252525252520loading#4573023

Kind Regards,

Kevin

+1 Brandon Brnich over 2 years ago in reply to Kevin Peng

TI__Expert 3830 points

Hi Kevin,

There is no restriction on the format of 264 in regards to gstreamer. It is a standard that gstreamer handles well.

I know what the issue is. Due to hardware requirements, we have to align the resolutions to certain boundaries. In this case, the height of the video is 1088 instead of the 1080 that is given from the input. If you display the video specifying the height as 1088, you will not see this issue of color alignment. This is a bug that I am currently exploring and should have a fix in upcoming 9.1 release.

DMA-Buf import is a great tool that reduces buffer copies between components in a gstreamer pipeline. However, I don't believe that it works well when writing to an output file. If the customer were writing to display buffers, they would notice a significant decrease in CPU load because they were would be 0 copy between decoder and the display. I am not familiar with other means of helping lower CPU load for a file write case.

Best,

Brandon