[Bug 752912] New: Regression: vaapidecode ! glimagesink broken since GL overlay composition
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Sun Jul 26 22:45:45 PDT 2015
https://bugzilla.gnome.org/show_bug.cgi?id=752912
Bug ID: 752912
Summary: Regression: vaapidecode ! glimagesink broken since GL
overlay composition
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: blocker
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: thaytan at noraisin.net
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
gstreamer-vaapi decoding to glimagesink is broken since commit
a7d1b7fcadda78e9a5ad9071634a70606f937d26 adding GstVideoOverlayCompositionMeta
If I've understood properly, the problem is that gstglupload negotiates these
input/output caps:
in:
video/x-raw, format=(string)I420, width=(int)1280, height=(int)720,
interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1,
chroma-site=(string)mpeg2, colorimetry=(string)bt709,
framerate=(fraction)30000/1001
out:
video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition),
format=(string)I420, width=(int)1280, height=(int)720,
interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1,
chroma-site=(string)mpeg2, colorimetry=(string)bt709,
framerate=(fraction)30000/1001
_raw_data_upload_accept() rejects these output caps because the caps features
are not exactly equal to memory:GLMemory
gst-launch-1.0 videotestsrc ! glimagesink still works. That seems to be because
it gets buffers directly from the downstream buffer pool, so it bypasses
_raw_data_upload_accept() and receives GstGlMemory directly, which
gstreamer-vaapi is using an internal buffer pool.
It's also an open question why gstreamer-vaapi isn't negotiating to use
video/x-raw(meta:GstVideoGLTextureUploadMeta)
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list