GNOME Bugzilla – Bug 645587
[dvdspu] Add a request sink pad to disable dvdspu blending and output the supictures on a seperate YUV buffer
Last modified: 2012-08-13 16:57:45 UTC
Created attachment 184148 [details] [review] Adds a request sink pad to disable dvdspu blending and output the supictures on a seperate YUV buffer This is made to enable hardware blending of supictures on platforms with hardware decoding (such as with flugdlsink on the Intel CE platforms). The behavior stays the same as before if the request pad is not created. Pipeline to test using a DVD with SPUs gst-launch-0.10 -v dvdreadsrc device=/dev/cdrom ! queue ! dvddemux name=d d.current_video ! queue ! flumpeg2vdec ! queue ! dvdspu name=s ! ffmpegcolorspace ! queue ! xvimagesink d.current_subpicture ! queue ! identity ! s.subpicture s.subpicture_src ! queue ! ffmpegcolorspace ! xvimagesink async=false
So this is doing the same as the dvdsubdec element then?
Comment seems to have been deleted by bugzilla going wrong the other day. Some things cannot be done by the dvdsubdec element because we need to have the video as an entry (in DVD menus especially). I believe this is actually the main reason dvdspu was developed initially. This work was done to support H/W acceleration on the Fluendo DVD player.
Created attachment 184560 [details] [review] Make supicture buffer on request pad not be sent at video framerate as in dvdsubdec
Created attachment 184561 [details] [review] Adds an ARGB mode for the request pad This is done because hardware decoders usually want overlays in ARGB, this is the case in gdlsink for Intel ISMD platform and for vdpau avoiding a colorspace conversion.
I understand why you want to do this, but I'm not convinced it's the right approach in general. We'll have to solve this issue more generically at some point, but in a way that's efficient, works well for all kinds of overlay elements, is scalable and will work well in complex autoplugging situations such as playbin2. I think the best solution for now would be to use playbin2's "text-sink" property and do the SPU work application-side. Have you tried that yet?
Thanks for taking the time to respond, the problem with using "text-sink" is the same that we ran into when using dvdsubdec, we have no access to the video stream, therefore we can't render the SPUs perfectly. While I agree it's not ideal for playbin2 this is just meant to be an extra feature that i'm sure some will find useful, it does not change the default behaviour of the dvdspu element in any way. As for the doing the SPU work application side, we have all the gstreamer elements to do the decoding/blending of SPUs in our Gstreamer pipeline, bringing the SPU work out of the Gstreamer framework would be alot of extra work.
Why don't you have access to the video stream when using text-sink? I still don't see what advantage this change has over using dvdsubdec and how the same couldn't be implemented with special text and video sinks
So are the provided patches rejected and this bug WONTFIX?
I believe this use case is now covered in a more generic and supportable way by the GstVideoOverlayComposition API, so would consider this bug a WONTFIX. Patches to port dvdspu to that API would be most welcome though (there might be another bug for that too).