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 748179 - videoconvert: Setting height to 1 freezes output in some cases
videoconvert: Setting height to 1 freezes output in some cases
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-20 12:56 UTC by Dimitrios Katsaros
Modified: 2018-11-03 11:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dimitrios Katsaros 2015-04-20 12:56:40 UTC
If a pipleline is created like the following:

gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw, height=1 ! videoconvert ! ximagesink

The output of the ximagesink is frozen after the first frame. Changing the ximagesink with another sink, e.g. glimagesink works normally
Comment 1 Vincent Penquerc'h 2015-04-20 14:27:13 UTC
Replacing v4l2src with videotestsrc -> no freeze.

The original pipeline doesn't preroll for me, it will depend on a particular camera's capabilities I suppose.
Comment 2 Dimitrios Katsaros 2015-04-20 14:47:36 UTC
Thanks for the update, testing the pipline with videotestsrc works for me too, however, adding format=GRAY8 breaks it on my device
Comment 3 Vincent Penquerc'h 2015-04-20 14:55:09 UTC
Good find, I can see the issue too with GRAY8. I'll have a look at it then.
Comment 4 Vincent Penquerc'h 2015-04-20 15:13:42 UTC
This does not freeze:

gst-launch-1.0 videotestsrc ! video/x-raw, height=1, format=GRAY8 ! videoconvert ! breakmydata probability=1 set-to=-1 ! ximagesink

I speculatively blame videoconvert (which is not needed in the case of glimagesink, so it presumably ends up in passthrough).
Comment 5 Dimitrios Katsaros 2015-04-20 15:27:32 UTC
Interresting, should I change anything on the ticket then? or leave it as is?
Comment 6 Vincent Penquerc'h 2015-04-20 16:04:01 UTC
If I dump some random values in the "input line" in video converter in the following bit of code, there's no freeze.

@@ -2815,10 +2817,12 @@ video_converter_generic (GstVideoConverter * convert, const GstVideoFrame * src,
     if (!convert->identity_pack) {
       /* take away the border */
       guint8 *l = ((guint8 *) lines[0]) - lb_width;
+//memset(l,rand(),out_maxwidth);
       /* and pack into destination */
       GST_DEBUG ("pack line %d %p (%p)", i + out_y, lines[0], l);
       PACK_FRAME (dest, l, i + out_y, out_maxwidth);
     }

That hints that l is stale. It's fetched from a cache which I don't understand at the moment. Disabling the cache doesn't seem obviously possible (when the cache search function returns NULL when not found, the caller crashes, which tells me cache misses aren't expected).
Comment 7 Vincent Penquerc'h 2015-04-20 16:05:13 UTC
I've changed the bug title as per your suggestion.
Comment 8 GStreamer system administrator 2018-11-03 11:37:10 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/183.