Why Gstreamer encoding takes more cpu load while encoding .yuv than .mp4

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Why Gstreamer encoding takes more cpu load while encoding .yuv than .mp4

Jump to solution
437 Views
Hariharan1
Contributor III

In the case of the i.MX VPU Hantro, while encoding a 1080p video, I considered two different approaches:

  1. MP4 → YUV → H.264

  2. MP4 → H.264

I noticed that the first approach consumes significantly more CPU load compared to the second approach. Is that intermediate conversion required?

 

1) Approach 1

>decode mp4 to yuv

gst-launch-1.0 filesrc location=5MB_1080p.mp4 !     qtdemux !     h264parse !     imxvpudec_h264 !     filesink location=1080p.yuv

CPU load: 90 %

>encode yuv to h264

gst-launch-1.0 filesrc location=1080p.yuv !  videoparse width=1920 height=1080 format=nv12 framerate=30/1 !  imxvpuenc_h264 ! h264parse ! filesink location=1080p.h264

CPU load: 35.9%

2) Approach 2

> Decode and Encode in a Single Pipeline

gst-launch-1.0 filesrc location=5MB_1080p.mp4 !  qtdemux name=demux demux.video_0 ! h264parse ! imxvpudec_h264 ! imxvpuenc_h264 ! h264parse ! filesink location=enc.h264

CPU load: 6.6%

 

 

0 Kudos
Reply
1 Solution
402 Views
pengyong_zhang
NXP Employee
NXP Employee

Hi @Hariharan1 

yes, you are right, At approach 1, The primary causes of high CPU load are: extensive data writes to disk and data shuffling during the decoding process. But approach 2, There are no intermediate disk write and read operations; data is directly transferred in memory. So, in your current scenario, approach 2 is the best choice.

B.R

View solution in original post

0 Kudos
Reply
1 Reply
403 Views
pengyong_zhang
NXP Employee
NXP Employee

Hi @Hariharan1 

yes, you are right, At approach 1, The primary causes of high CPU load are: extensive data writes to disk and data shuffling during the decoding process. But approach 2, There are no intermediate disk write and read operations; data is directly transferred in memory. So, in your current scenario, approach 2 is the best choice.

B.R

0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2193990%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3EWhy%20Gstreamer%20encoding%20takes%20more%20cpu%20load%20while%20encoding%20.yuv%20than%20.mp4%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2193990%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EIn%20the%20case%20of%20the%20%3CSTRONG%3Ei.MX%20VPU%20Hantro%3C%2FSTRONG%3E%2C%20while%20encoding%20a%20%3CSTRONG%3E1080p%20video%3C%2FSTRONG%3E%2C%20I%20considered%20two%20different%20approaches%3A%3C%2FP%3E%3COL%3E%3CLI%3E%3CP%3E%3CSTRONG%3EMP4%20%E2%86%92%20YUV%20%E2%86%92%20H.264%3C%2FSTRONG%3E%3C%2FP%3E%3C%2FLI%3E%3CLI%3E%3CP%3E%3CSTRONG%3EMP4%20%E2%86%92%20H.264%3C%2FSTRONG%3E%3C%2FP%3E%3C%2FLI%3E%3C%2FOL%3E%3CP%3EI%20noticed%20that%20the%20first%20approach%20consumes%20significantly%20more%20CPU%20load%20compared%20to%20the%20second%20approach.%20Is%20that%20intermediate%20conversion%20required%3F%3C%2FP%3E%3CBR%20%2F%3E%3CP%3E%3CSTRONG%3E1)%20Approach%201%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26gt%3Bdecode%20mp4%20to%20yuv%3C%2FP%3E%3CP%3E%3CSPAN%3Egst-launch-1.0%20filesrc%20location%3D5MB_1080p.mp4%20!%26nbsp%3B%26nbsp%3B%26nbsp%3B%26nbsp%3B%20qtdemux%20!%26nbsp%3B%26nbsp%3B%26nbsp%3B%26nbsp%3B%20h264parse%20!%26nbsp%3B%26nbsp%3B%26nbsp%3B%26nbsp%3B%20imxvpudec_h264%20!%26nbsp%3B%26nbsp%3B%26nbsp%3B%26nbsp%3B%20filesink%20location%3D1080p.yuv%3C%2FSPAN%3E%3C%2FP%3E%3CP%3ECPU%20load%3A%2090%20%25%3C%2FP%3E%3CP%3E%26gt%3Bencode%20yuv%20to%20h264%3C%2FP%3E%3CP%3E%3CSPAN%3Egst-launch-1.0%20filesrc%20location%3D1080p.yuv%20!%26nbsp%3B%20videoparse%20width%3D1920%20height%3D1080%20format%3Dnv12%20framerate%3D30%2F1%20!%26nbsp%3B%20imxvpuenc_h264%20!%20h264parse%20!%20filesink%20location%3D1080p.h264%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3ECPU%20load%3A%2035.9%25%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSTRONG%3E2)%20Approach%202%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%26gt%3B%20Decode%20and%20Encode%20in%20a%20Single%20Pipeline%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3Egst-launch-1.0%20filesrc%20location%3D5MB_1080p.mp4%20!%26nbsp%3B%20qtdemux%20name%3Ddemux%20demux.video_0%20!%20h264parse%20!%20imxvpudec_h264%20!%20imxvpuenc_h264%20!%20h264parse%20!%20filesink%20location%3Denc.h264%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3ECPU%20load%3A%206.6%25%3C%2FSPAN%3E%3C%2FP%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2194163%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20Why%20Gstreamer%20encoding%20takes%20more%20cpu%20load%20while%20encoding%20.yuv%20than%20.mp4%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2194163%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F224949%22%20target%3D%22_blank%22%3E%40Hariharan1%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3Eyes%2C%20you%20are%20right%2C%20At%20approach%201%2C%26nbsp%3BThe%20primary%20causes%20of%20high%20CPU%20load%20are%3A%20extensive%20data%20writes%20to%20disk%20and%20data%20shuffling%20during%20the%20decoding%20process.%20But%20approach%202%2C%26nbsp%3BThere%20are%20no%20intermediate%20disk%20write%20and%20read%20operations%3B%20data%20is%20directly%20transferred%20in%20memory.%20So%2C%20in%20your%20current%20scenario%2C%20approach%202%20is%20the%20best%20choice.%3C%2FP%3E%0A%3CP%3EB.R%3C%2FP%3E%3C%2FLINGO-BODY%3E