ishmael1985
commented
6 years ago Theoretically, both gst-mfx and sample_multi_transcode should perform the same. Joined sessions are used by gst-mfx as well, but this would require that MFX sessions are created for one GStreamer pipeline instance. There are also IO differences to consider, sample_multi_transcode takes fixed chunks while filesrc and parser elements will read data in variable chunks, affecting the performance. You could manually try to invoke multiple instances of the encode pipeline you used, and check out the GPU utilization and time. I think the performance difference would be smaller even though in this case, join operations are not being used by gst-mfx.
arbishop
Going through the process of proving out performance of an Atom E3950 for transcoding I found a huge discrepancy between sample_multi_transcode and gstreamer.
Scaled tests (several more transcodes at once) with sample_multi_transcode and proved out good (faster than real time). Unfortunately, gstreamer when ramped up did not perform nearly as well. I have below the most simple example I could think of and it shows a 223% performance delta with respect to transcode time.
I'm not sure where to go from here, perhaps someone has advice on how to make gstreamer-media-SDK a viable option.
One thing that I noticed is that gstreamer-media-SDK doesn't seem to call the "JoinSessions" API while sample_multi_transcode does. I'm not sure if architecturally gstreamer doesn't need to. Another is that gstreamer doesn't seem to utilize as much of the GPU.
It's also very likely I'm doing something incorrect with the pipeline, not sure. Are the results below expected, surprising?
Intel: sample_multi_transcode
GStreamer: gst-launch-1.0
Results