GNOME Bugzilla – Bug 754495
videoaggregator: No protection from receiving interlaced and non-interlaced content
Last modified: 2016-04-18 17:25:51 UTC
+++ This bug was initially created as a clone of Bug #754291 +++ See the original bug. It seems that it is possible to set caps to two sink pads in compositor to interlaced and non-interlaced and it will accept it. Need to make sure that it only accepts of one type. Unit tests are highly appreciated.
Why is this a blocker bug? Should we make sure to fix it before 1.6?
Sorry, not a blocker.
Created attachment 324890 [details] [review] videoaggregator: lift restriction on interlaced-mode The internal converters can handle it
Comment on attachment 324890 [details] [review] videoaggregator: lift restriction on interlaced-mode No, GstVideoConverter can't deinterlace or interlace content.
Created attachment 325029 [details] [review] videoaggregator: properly handle interlace-mode restrictions You're right, I got confused with videotestsrc not putting interlace-mode in its caps (which implicitly means progressive) and using a capsfilter after it that would filter to 'interleaved'. That seemed to be working nicely but was all a lie. One downsize for this change is that caps queries from compositor will now return interlace-mode in its caps which will become yet another required field for video caps for subset checks to work.
commit 641bb44226f6b12dbe8fb5a3b3f76d76ff720aa1 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Mon Mar 28 15:44:27 2016 -0300 videoaggregator: properly handle interlace-mode restrictions videoaggregator can't handle interlace-mode changes so it must always restrict itself to the first interlacing mode it receives. Tests included https://bugzilla.gnome.org/show_bug.cgi?id=754495