Problems with Gst.Buffer.map and Gst.Memory.map

[dayunbao]

Hi everyone,

After a fair amount of troubleshooting, I believe the problem I've been having is related to the map() function that both the buffer and memory class have.  I've tried using two different pipelines.  This one:

v4l2src -> videorate -> queue -> identity -> jpegenc -> queue -> jifmux -> multifilesink

and this one:

                                                              queue -> jpegenc -> queue -> jifmux -> multifilesink
                                                          /
v4l2src -> videorate -> queue -> tee
                                                         \
                                                             queue -> appsink


but the same problem is happening in both pipelines.  When either the identity plugin's handoff signal is fired, or when appsink's new_sample signal is emitted, I grab the data from the buffer, and send it over a socket to another process to process the data.  At the moment, I'm simply displaying the data received by the second process as an image (using OpenCV), and I often times get images like the one attached below.  However, the JPEGs that are written to file by the multifilesink are fine.  So, the problem must be with the map functions.  I've tried calling map() on the data using a buffer object and a memory object inside of both the identity handoff and appsink callback functions, but I get the same results.  So, does anyone know if there is a known problem with those functions in Python?  Is there an alternative to map()?  This is a project at work, and I've been stuck on it for a few days now, and need to make some progress, or decide if I'm going to have to use a tool other than GStreamer.  I'm using GStreamer version 1.6.3 on Linux, by the way.

[kendell clark]

hi

I'm not sure if this one is related, but when trying to launch asunder
cd ripper, the xfce application for ripping cd's, it prints the
following message and fails to launch.

Warning: could not load config file: Bad address

(asunder:6291): Gtk-WARNING **: Default font does not have a
positive size

(asunder:6291): Gtk-WARNING **: Default font does not have a
positive size

(asunder:6291): Gtk-WARNING **: Default font does not have a
positive size
Fatal error: g_strdup_printf() failed. Out of memory.

In case it helps, I then immediately launched mate's system monitor and
I'm only using 1.6 gb out of 5.6 gb, so nowhere near out of memory.

Thanks

Kendell Clark



On 06/08/2017 10:00 AM, dayunbao wrote:

> Hi everyone,
>
> After a fair amount of troubleshooting, I believe the problem I've been
> having is related to the map() function that both the buffer and memory
> class have.  I've tried using two different pipelines.  This one:
>
> v4l2src -> videorate -> queue -> identity -> jpegenc -> queue -> jifmux ->
> multifilesink
>
> and this one:
>
>                                                                queue ->
> jpegenc -> queue -> jifmux -> multifilesink
>                                                            /
> v4l2src -> videorate -> queue -> tee
>                                                           \
>                                                               queue ->
> appsink
>
>
> but the same problem is happening in both pipelines.  When either the
> identity plugin's handoff signal is fired, or when appsink's new_sample
> signal is emitted, I grab the data from the buffer, and send it over a
> socket to another process to process the data.  At the moment, I'm simply
> displaying the data received by the second process as an image (using
> OpenCV), and I often times get images like the one attached below.
> *However, the JPEGs that are written to file by the multifilesink are fine.*
> So, the problem must be with the map functions.  I've tried calling map() on
> the data using a buffer object and a memory object inside of both the
> identity handoff and appsink callback functions, but I get the same results.
> So, does anyone know if there is a known problem with those functions in
> Python?  Is there an alternative to map()?  This is a project at work, and
> I've been stuck on it for a few days now, and need to make some progress, or
> decide if I'm going to have to use a tool other than GStreamer.  I'm using
> GStreamer version 1.6.3 on Linux, by the way.
>
>
> <http://gstreamer-devel.966125.n4.nabble.com/file/n4683257/problemImage.png>
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Problems-with-Gst-Buffer-map-and-Gst-Memory-map-tp4683257.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel