GNOME Bugzilla – Bug 767921
videoscale: artifacts on still video
Last modified: 2017-12-27 14:14:34 UTC
It seems that using videoscale to downscale interleaved still video, I420 format, would produce artifacts. The original image does not have any artifacts. I can reproduce it with this pipeline: gst-launch-1.0 -v v4l2src norm=NTSC device=/dev/video0 ! videoconvert ! video/x-raw,format=I420,width=720,height=480 ! videoscale ! video/x-raw,width=360,height=240 ! jpegenc ! multifilesink location=bad-%d.jpg Where as these pipelines produce no-artifacted frames: gst-launch-1.0 -v v4l2src norm=NTSC device=/dev/video0 ! videoconvert ! deinterlace method=weave ! video/x-raw,format=I420,width=720,height=480 ! videoconvert ! videoscale ! video/x-raw,width=360,height=240 ! jpegenc ! multifilesink location=good-%d.jpg gst-launch-1.0 -v v4l2src norm=NTSC device=/dev/video0 ! videoconvert ! video/x-raw,format=YUY2,width=720,height=480 ! videoconvert ! videoscale ! video/x-raw,width=360,height=240 ! jpegenc ! multifilesink location=good-%d.jpg
Created attachment 330157 [details] Image with artifacts
Created attachment 330160 [details] Image without artifacts
please check if this fixes it: commit 5e752f4edad15cb090608f45c10161398ba58fee Author: Wim Taymans <wtaymans@redhat.com> Date: Wed Jun 22 16:02:37 2016 +0200 video-converter: fix interlaced scaling some more Fix problem with the line cache where it would forget the first line in the cache in some cases. Keep as much backlog as we have taps. This generally works better and we could do even better by calculating the overlap in all taps. Allocated enough lines for the line cache. Use only half the number of taps for the interlaced lines because we only have half the number of lines. The pixel shift should be relative to the new output pixel size so scale it. Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=767921
I backported the commit into my 1.8.1 build, and the result is better. However, a pipeline that scales YUY2 frames still produces better results than a pipeline scaling I420. Pipelines being used to compare: gst-launch-1.0 -v v4l2src norm=NTSC device=/dev/video0 num-buffers=3 ! videoconvert ! video/x-raw,format=I420,width=720,height=480 ! videoscale ! video/x-raw,width=360,height=240 ! jpegenc quality=100 ! multifilesink location=i420-%d.jpg gst-launch-1.0 -v v4l2src norm=NTSC device=/dev/video0 num-buffers=3 ! videoconvert ! video/x-raw,format=YUY2,width=720,height=480 ! videoscale ! video/x-raw,width=360,height=240 ! jpegenc quality=100 ! multifilesink location=yuy2-%d.jpg
Created attachment 330211 [details] I420 scaled image, with Wim's first fix
Created attachment 330212 [details] YUY2 scaled image with Wim's first fix
Any news about this? I'm about to give up and hack v4l2src plugin to allow forcing the caps to progressive. So far, progressive frames don't have this artifact (even if there isn't a proper deinterlacing). This makes sense because this issue has nothing to do with deinterlace, given it's present on still images. If there isn't anything better, this fix should be merged, as it mildly improves the situation.
Closed for lack of activity. I've added a patch to force caps to progressive.