GNOME Bugzilla – Bug 455299
v4lsrc ! videoscale doesn't correctly resize
Last modified: 2008-06-11 16:53:32 UTC
gst-launch v4lsrc ! ffmpegcolorspace ! videoscale ! ximagesink If you resize ximagesink, you get black borders, as you do without videoscale. Replace v4lsrc with videotestsrc and it does scale correctly.
Created attachment 101942 [details] [review] allow reverse cap negotiation in basetransform It looks like the problem is in the gstbasetransform, there reverse caps negotiation is not allowed for PUSH mode. Is there a special reason for this? However you also need the patch from bug #506682 to allow renegotiation of the v4lsrc. With those two patches the black borders are gone...
The logic in basetransform is correct. Reverse negotiation in push mode only works through pad_alloc requests -> v4lsrc needs to use pad_alloc to request the buffer it wants to produce, but to allow downstream to do get_caps and see that a different size is allowed. Downstream then returns a buffer with different caps than was originally requested by v4lsrc, and v4lsrc needs to adjust itself to produce that caps.
Note that both v4lsrc and v4l2src are similar in this area. Although this suggestion (to use pad_alloc) sounds simple, unfortunately it is not. These elements do not allocate buffers for each frame, but rather maintain their own pool (this is primarily due to the need for the data part of the buffers to have been "mmap'ed", because they are also directly used by the associated driver). Since "downstream-allocated" buffers would seem to not be a viable option in this instance, is there any other suggestion as to how the required change in caps should be recognized by the v4l(2)src elements?
When basetransform creates a new buffer for pushing downstream, it should use pad-alloc, which would detect a new size. Unfortunately, it does not do pad-alloc when it's operating in passthrough mode.
*** This bug has been marked as a duplicate of 339795 ***