[Bug 780682] New: compositor: corrupts output when input caps change while running

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=780682

            Bug ID: 780682
           Summary: compositor: corrupts output when input caps change
                    while running
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: gkiagia at tolabaki.gr
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Consider the following pipeline:

gst-launch-1.0 -v videotestsrc is-live=true !
video/x-raw,width=10,height=20,format=I420  ! compositor name=c ! glimagesink 
multifilesrc location=%04d.bmp loop=true caps=image/bmp,framerate=10/1 !
avdec_bmp ! videoconvert ! videorate ! c.

...where the .bmp files have been created with:
gst-launch-1.0 videotestsrc num-buffers=10 ! video/x-raw,width=320,height=240 !
avenc_bmp ! multifilesink location=%04d.bmp
gst-launch-1.0 videotestsrc num-buffers=10 ! video/x-raw,width=640,height=480 !
avenc_bmp ! multifilesink location=%04d.bmp index=10
(so there should be a total of 20 images, 10 at 320x240 and 10 at 640x480)

Now at the beginning, the caps of avdec_bmp::src have width=320,height=240 and
therefore the output of compositor is configured to be at 320x240 as well. As
soon as the 11th image is loaded, the caps now have width=640,height=480 and
compositor is reconfigured to output @ 640x480. As soon as this happens, the
output becomes corrupt (!) momentarily, while valgrind shows a couple of
invalid reads around video-converter code:

==26291== Thread 4 c:src:
==26291== Invalid read of size 16
==26291==    at 0x4028AC0: ??? (in /run/user/1000/orcexec.x2M1gv (deleted))
==26291==    by 0x72DAA68: do_unpack_lines (video-converter.c:2785)
==26291==    by 0x72DABF5: gst_line_cache_get_lines (video-converter.c:617)
==26291==    by 0x72DAD03: convert_generic_task (video-converter.c:3072)
==26291==    by 0x72D6658: gst_parallelized_task_runner_run
(video-converter.c:297)
==26291==    by 0x72D93E6: video_converter_generic (video-converter.c:3170)
==26291==    by 0x7A290D5: gst_compositor_pad_prepare_frame (compositor.c:572)
==26291==    by 0x7E439BA: gst_aggregator_iterate_sinkpads
(gstaggregator.c:380)
==26291==    by 0x7C382A9: gst_video_aggregator_do_aggregate
(gstvideoaggregator.c:1364)
==26291==    by 0x7C382A9: gst_video_aggregator_aggregate
(gstvideoaggregator.c:1582)
==26291==    by 0x7E46784: gst_aggregator_aggregate_func (gstaggregator.c:824)
==26291==    by 0x4EE29F8: gst_task_func (gsttask.c:335)
==26291==    by 0x5B3DAED: g_thread_pool_thread_proxy (gthreadpool.c:307)

The problem seems to be that compositor chooses input buffers from its queue
based on timestamps and never checks if the buffer it has chosen actually
matches the configured format, so momentarily it picks a 320x240 frame,
thinking that it is a 640x480 one, and sometimes also vice versa when the
resolution drops.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.