GNOME Bugzilla – Bug 723364
deinterlace: add RGB16 and BRG16 support
Last modified: 2014-02-04 15:42:50 UTC
Created attachment 267726 [details] [review] deinterlace: add RGB16 / BGR16 support * actual result: an avi file generated with gst-launch-1.0 videotestsrc num-buffers=200 ! "video/x-raw, format=RGB16" ! avimux ! filesink location=rgb16.avi just fails to play with playbin (with default flags) * see https://bugzilla.gnome.org/show_bug.cgi?id=723357 and https://bugzilla.gnome.org/show_bug.cgi?id=723358 * with the attached patch the rgb16.avi can be played with playbin but I guess deinterlace enter in passthrough mode. Because if I do: gst-launch-1.0 videotestsrc ! interlace ! videoconvert ! deinterlace ! "video/x-raw, format=RGB16" ! videoconvert ! ximagesink there are some artefacts around the ball curve I guess this is because I did not create dedicated deinterlace_frame_rgb16 functions :)
Comment on attachment 267726 [details] [review] deinterlace: add RGB16 / BGR16 support Yes, you need to add special RGB16/BGR16 processing functions. Also RGB16... really?! :)
(In reply to comment #1) > (From update of attachment 267726 [details] [review]) > Yes, you need to add special RGB16/BGR16 processing functions. > > Also RGB16... really?! :) And even implementing them it would be very slow on RPI :) Would it be possible that deinterlace just always work in passthrough when it does not know how to deinterlace ? Because it fails right now if input is RGB16 (interleaved or even if progressive): gst-launch-1.0 videotestsrc ! "video/x-raw, format=RGB16, interlace-mode=progressive" ! deinterlace mode = 2 ! fakesink ERROR:gstdeinterlace.c:426:gst_deinterlace_set_method: assertion failed: (method_type != G_TYPE_INVALID) Aborted
There could be such an auto mode, yes. Mateo is working on that currently, there's another bug for that.