[Bug 704760] opencv: disparity-map calculation element

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Aug 19 07:46:05 PDT 2013


https://bugzilla.gnome.org/show_bug.cgi?id=704760
  GStreamer | gst-plugins-bad | 1.x

--- Comment #13 from Miguel (elmiguelao) Casas-Sanchez <miguelecasassanchez at gmail.com> 2013-08-19 14:46:01 UTC ---
(In reply to comment #12)
> Review of attachment 250442 [details]:
> 
> ::: ext/opencv/gstdisparity.cpp
> @@ +324,3 @@
> +  GstStateChangeReturn ret = GST_STATE_CHANGE_SUCCESS;
> +  GstDisparity *fs = GST_DISPARITY (element);
> +  g_mutex_lock (fs->lock);
> 
> Better take the lock just around the lines that need it, someone might add
> something else to the switch statement later

Done.

> 
> @@ +342,3 @@
> +      transition);
> +
> +  g_mutex_lock (fs->lock);
> 
> Same here

Done.

> 
> @@ +373,3 @@
> +      /* Critical section since both pads handle event sinking simultaneously
> */
> +      g_mutex_lock (fs->lock);
> +      GstVideoInfo info;
> 
> Put all variable declarations at the beginning of a block

Done.

> 
> @@ +387,3 @@
> +            "format", G_TYPE_STRING, "RGB",
> +            "width", G_TYPE_INT, fs->width,
> +            "height", G_TYPE_INT, fs->height, NULL);
> 
> Use gst_video_info_to_caps() to create raw video caps
> 

Done.

> @@ +396,3 @@
> +
> +      GST_INFO_OBJECT (pad, " Negotiated caps via event, %" GST_PTR_FORMAT,
> +          caps);
> 
> Put ret in the debug output too
> 

Done.

> @@ +402,3 @@
> +      break;
> +  }
> +  ret = gst_pad_event_default (pad, parent, event);
> 
> You probably don't want to forward the event if above the caps equality check
> has failed
> 

Done.

> @@ +418,3 @@
> +      else
> +        gst_query_set_caps_result (query,
> +            gst_pad_get_current_caps (fs->srcpad));
> 
> This is leaking the return values of gst_pad_get_pad_template_caps() and
> gst_pad_get_current_caps(), also needs locking
> 

Hopefully done :)

> @@ +448,3 @@
> +  filter = GST_DISPARITY (object);
> +  gst_disparity_release_all_pointers (filter);
> +  filter->width = filter->height = filter->actualChannels = 0;
> 
> Not necessary to reset these to 0 in finalize

Done.

> 
> @@ +469,3 @@
> +  GST_DEBUG_OBJECT (pad, "processing frame from left");
> +  if (fs->flushing)
> +    return GST_FLOW_FLUSHING;
> 
> Check flushing after taking the mutex
> 

Done.

> @@ +476,3 @@
> +    GST_DEBUG_OBJECT (pad, " right is free, continuing");
> +    if (fs->flushing)
> +      return GST_FLOW_FLUSHING;
> 
> Returning without unlocking the mutex

Done.

> 
> @@ +481,3 @@
> +
> +  if (!gst_buffer_map (buffer, &info, (GstMapFlags) GST_MAP_READWRITE)) {
> +    return GST_FLOW_ERROR;
> 
> Returning without unlocking the mutex

Done.

> 
> @@ +504,3 @@
> +  GST_DEBUG_OBJECT (pad, "processing frame from right");
> +  if (fs->flushing)
> +    return GST_FLOW_FLUSHING;
> 
> Check flushing after taking the mutex

Done.

> 
> @@ +511,3 @@
> +    GST_DEBUG_OBJECT (pad, " left has just provided a frame, continuing");
> +    if (fs->flushing)
> +      return GST_FLOW_FLUSHING;
> 
> Returning without unlocking the mutex

Done.

> 
> @@ +587,3 @@
> +
> +  GST_DEBUG_OBJECT (pad, " right has finished");
> +  fs->buffer_left = NULL;
> 
> Unmap and unref the left buffer

Done unmapping but not unrefing: fs->buffer_left is just a mapping of an
already unreferenced incoming buffer (in chain_left), after the unmap, both
will get automatically unreferenced and destroyed. 

> 
> @@ +591,3 @@
> +  g_mutex_unlock (fs->lock);
> +
> +  ret = gst_pad_push (fs->srcpad, buffer);
> 
> As the right buffer is always the one that is forwarded it would make sense to
> proxy the allocation query from the right sinkpad to the srcpad

I don't really understand that :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list