Skip to main content
1 of 5

Should playing uncompressed RGB video files consume strictly less resources than encoded files?

I don't know much about video, but to play an h264 encoded file into a screen, don't you have to decode it first? I would expect playing a video that is in RGB format to skip the decoding step, therefore being strictly faster than a video that has to be decoded (even if I decode it with hardware acceleration, as I did). That doesn't seem to be the case, but I can't tell whether that is due to a software issue, like the RGB file being played inefficiently. I must be very wrong about something.

I've been playing around all day with GStreamer trying to smoothly play video files on my Raspberry Pi 3. I finally managed it in an almost fresh install of Jessie (after apt-get update, apt-get upgrade and apt-get install gstreamer1.0-tools).

I have an uncompressed (8-bit RGB) .mov version of the video I want to play, and an h264-encoded .mov version. I played both of them:

gst-launch-1.0 filesrc location=h264_test.mov ! qtdemux name=demuxer ! h264parse ! omxh264dec ! ximagesink

gst-launch-1.0 filesrc location=uncompressed_test.mov ! qtdemux ! videoparse format=GST_VIDEO_FORMAT_RGB height=800 width=480 ! glimagesinkelement

Honestly, I expected the uncompressed version would play faster, but it's slow. The h264-encoded version, which omxh264dec decodes with hardware acceleration, plays at the correct speed (which in this case is 25 FPS), but the other one lags and I get GStreamer warnings about buffers being dropped and the computer being slow. I used different sinks for each one (ximagesink and glimagesink) because neither file would play correctly on the other one, which I'm not sure makes a difference.

I think I would've preferred that the uncompressed version was faster, because that means I don't have to bother with fixing banding issues. Really, though, I'm asking this question because I feel like I have a misconception about how this works.