Threads

Chris Tapp opensource at keylevel.com
Sun Jul 20 16:04:52 PDT 2014


I've got an application running which used GLES to render the screen at 20 fps.

Part of the application uses GStreamer 1.2.3 to capture video frames so they can be converted to textures and rendered.

The system has a quad core CPU and the application easily runs at 20 fps when the pipeline is not running and also runs correctly when I run the pipeline at the same time using gst-launch. However, if I run the pipeline within the application I only see about 5 fps. When this happens, it looks as if only one core of the CPU is being used.

I actually use two pipelines within my code, both started using parse_launch.

Pipeline 1: decodebin uri=... video-sink="fakesink sync=true"
Pipeline 2: appsrc ! videoconvert ! videoscale ! <caps> ! appsink"

Pipeline 1 is used to stream the video. I then use last-frame to grab the most recent frame and push this through pipeline 2 to set the format and size needed for texture uploading.

Some videos do work as expected. When this happens, the total CPU load is less than 100% of one core. This shows that the problem isn't related to the GLES texture uploads blocking as they are always the same size/format, regardless of the video source.

Why are these pipelines stopping my application running at its target frame rate? I was expecting them to run in their own threads, but it looks as if they're causing the main thread to block. I could understand if my effective video (texture upload) rate was lower, but I don't understand why the rest of the application is running slow.

Chris Tapp

opensource at keylevel.com
www.keylevel.com





More information about the gstreamer-devel mailing list