After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 455299 - v4lsrc ! videoscale doesn't correctly resize
v4lsrc ! videoscale doesn't correctly resize
Status: RESOLVED DUPLICATE of bug 339795
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.13
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-07-09 21:28 UTC by Thomas Vander Stichele
Modified: 2008-06-11 16:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
allow reverse cap negotiation in basetransform (754 bytes, patch)
2008-01-01 17:02 UTC, Thijs Vermeir
none Details | Review

Description Thomas Vander Stichele 2007-07-09 21:28:02 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.
Comment 1 Thijs Vermeir 2008-01-01 17:02:42 UTC
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...
Comment 2 Jan Schmidt 2008-01-04 10:00:28 UTC
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.
Comment 3 William M. Brack 2008-03-17 14:20:13 UTC
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?
Comment 4 Wim Taymans 2008-06-10 11:46:19 UTC
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.
Comment 5 Wim Taymans 2008-06-11 16:53:32 UTC

*** This bug has been marked as a duplicate of 339795 ***