Mapping appsink buffer as READWRITE always copies data

[Michael Gruner]

Hello all

It seems like I can never map a buffer as READWRITE that I just pulled from an appsink without the map copying the underlying data. I have a bare minimal example here:

https://pastebin.ubuntu.com/p/27b6K4VX6c/

You may run it as:

cc -o gst gst.c `pkg-config --cflags --libs gstreamer-1.0 gstreamer-app-1.0`
GST_DEBUG=2,GST_PERFORMANCE:9,GST_BUFFER:9,GST_MEMORY:9,GST_LOCKING:9 ./gst

The pipeline is simply:

"videotestsrc ! appsink name=sink enable-last-sample=false max-buffers=1 drop=false”

The process is also simple:

1. Pull the sample

2. Get the buffer from the sample

3. Make it writable

4. Map it as READWRITE  <————— Copy occurs

5. Unmap

6. Unref

Here’s my log from the minimal example:

Sample refcount: 2

Buffer 1 refcount: 1

Buffer 1 is writable: 0

Buffer 2 refcount: 1. <———— Made the buffer writable

Buffer 2 is writable: 1

Memcpy below

…

0:00:00.059691000 33882 0x7f9c55e0e000 TRACE            GST_LOCKING gstminiobject.c:221:gboolean gst_mini_object_lock(GstMiniObject *, GstLockFlags): lock 0x7f9c58000000: state 00020000, access_mode 3

0:00:00.059706000 33882 0x7f9c55e0e000 DEBUG            GST_LOCKING gstminiobject.c:256:gboolean gst_mini_object_lock(GstMiniObject *, GstLockFlags): lock failed 0x7f9c58000000: state 00020000, access_mode 3

...

0:00:00.059753000 33882 0x7f9c55e0e000 DEBUG        GST_PERFORMANCE gstallocator.c:461:GstMemorySystem *_sysmem_copy(GstMemorySystem *, gssize, gsize): memcpy 115200 memory 0x7f9c58000000 -> 0x7f9c5804b000

...

Memcpy above

I’ve tried changing the source to verify it’s not a videotestsrc thing, forcing processing in the middle, unreffing the sample earlier. Nothing seems to make a difference.

I appreciate some light on this, or if it’s an actual bug, I’d be happy to help with the fix.

Thanks!

Michael

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

[Sebastian Dröge-3]

On Fri, 2020-09-18 at 19:22 -0600, Michael Gruner wrote:
> Here’s my log from the minimal example:
> Sample refcount: 2
> Buffer 1 refcount: 1
> Buffer 1 is writable: 0
> Buffer 2 refcount: 1. <———— Made the buffer writable
> Buffer 2 is writable: 1
> Memcpy below

The buffer is not writable because its parent (the sample) is not
writable (has a reference count > 1). This happens because appsink
caches the sample to not have to re-create it for every buffer.

This changed relatively recently, both the caching of the sample inside
appsink and the considering of the parent reference count for
determining writability. The latter is needed to fix memory corruption
that can otherwise happen.


Best to create an issue in GitLab about this so it can be discussed. It
seems rather unfortunate and probably means that something should be
fixed there.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com


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

[Michael Gruner]

Thanks for the quick response Sebastian. Here’s the issue:

https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/824

> On Sep 19, 2020, at 01:06, Sebastian Dröge <[hidden email]> wrote:
>
> On Fri, 2020-09-18 at 19:22 -0600, Michael Gruner wrote:
>> Here’s my log from the minimal example:
>> Sample refcount: 2
>> Buffer 1 refcount: 1
>> Buffer 1 is writable: 0
>> Buffer 2 refcount: 1. <———— Made the buffer writable
>> Buffer 2 is writable: 1
>> Memcpy below
>
> The buffer is not writable because its parent (the sample) is not
> writable (has a reference count > 1). This happens because appsink
> caches the sample to not have to re-create it for every buffer.
>
> This changed relatively recently, both the caching of the sample inside
> appsink and the considering of the parent reference count for
> determining writability. The latter is needed to fix memory corruption
> that can otherwise happen.
>
>
> Best to create an issue in GitLab about this so it can be discussed. It
> seems rather unfortunate and probably means that something should be
> fixed there.
>
> --
> Sebastian Dröge, Centricular Ltd · https://www.centricular.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