GNOME Bugzilla – Bug 734983
fbdevsink: make it work with autovideosink
Last modified: 2016-01-07 18:06:19 UTC
Raise GstRank to make it an eligible autovideosink candidate. Testing is easy using: $ GST_DEBUG='playbin:6' gst-launch playbin uri=file:///path/file.mp4
Created attachment 283716 [details] [review] Patch v1
If you want this, you need to guaranty it will perfectly cooperate with the other automatic videosink (xvimagesink, glimagesink). That basically mean, the element should cleanly fail in conditions where it cannot be used (e.g. no FB device node permission, when running in X an device is already in use). Personnally, I think FB dev for it's nature, and because it's not bound to a window system, might not be an ideal fit for autovideosink support, but if you can prove it cooperate well, then I guess there would be nothing about this change. My other cons for this is that FB devices are being deprecated at kernel level.
I known that this is quite obsolete, but it's still used on low cost hardware. However I quite agree than fbdev isn't mature enough for GST_RANK_MARGINAL. Could you do a short list of lacks? I could suggest patches for you to review. How about adding support for GstVideoCropMeta, would you be agree?
My comment was not as much about code quality or features (I must say I have no idea), but mostly about the concept. So far autovideosource seems to only use sink that do actually sit on top of a windowing system and implements GstVideoOverlay.
I'm testing using 1.2.x, autovideosource relies only on RANK: so fbdevsink, dfbvideosink (which does not implement GstVideoOverlayInterface) are selected. Now, I fully understand your choice. This would have been a good sandbox for me. Anyway, you can close this issue. Thanks for your time.
Thanks, closing as per comment #5.