the hw video acceleration is provided by a v4l2 driver in the kernel. From the user space perspectives, the v4l2 driver (e.g. /dev/videoX) can be used directly through the v4l2 'API'. For an example of how to use v4l2 API, you can check this code: https://github.com/robclark/kmscube/tree/v4l2-video.
The v4l2 API is 'generic' and not tied to any specific SoC, several ARM SoC use it for video acceleration (including Snapdragon). As such there is a Gstreamer plugin (in -good set) called v4l2videodec that implements the v4l2 API, and which can be used with v4l2 compliant drivers.
In fact, with our release v4l2videodec should be the default elements used by Gstreamer, such that
gst-play-1.0 <file> --videosink glimagesink
should work and use video acceleration. To check that video acceleration is being used you can run
cat /proc/interupts | grep venus
and see the count going up.
Even if that works, the 'automatic' pipeline won't be fully optimized, and there are some video buffer copies that are done by Gstreamer, mostly because Gstreamer doesn't figure out how to allocate memory in the most optimized way (which would allow zero-copy pipeline). To allocate memory optimally, you need to tweak the Gstreamer pipeline, for example the following command would run an optimized video pipeline:
GST_GL_PLATFORM=egl gst-launch-1.0 filesrc location=<path to file> ! qtdemux name=m m.video_0 ! h264parse ! v4l2video0dec capture-io-mode=dmabuf ! glimagesink
You will need to adjust the command based on the codec/file you are using, of course.
All of the above applies to both DB410c and DB820c, by the way.
There is currently a bug under investigation and 4K video clips don't work with Gstreamer (but they work with the v4l2 test app mentioned at the beginning).