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 757254 - Deprecate GST_MEMORY_FLAG_NO_SHARE
Deprecate GST_MEMORY_FLAG_NO_SHARE
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.6.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-10-28 15:21 UTC by pietro_bonfa
Modified: 2018-11-03 12:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case showing that meta are not propagated. (3.11 KB, application/gzip)
2015-10-28 15:21 UTC, pietro_bonfa
  Details
memory: Deprecate GST_MEMORY_FLAG_NO_SHARE (1.51 KB, patch)
2017-07-11 22:56 UTC, Olivier Crête
none Details | Review

Description pietro_bonfa 2015-10-28 15:21:31 UTC
Created attachment 314325 [details]
Test case showing that meta are not propagated.

Custom metadata API cannot be copied by 

myapi_meta_transform (GstBuffer * transbuf, GstMeta * meta,
    GstBuffer * buffer, GQuark type, gpointer data)

with some pipelines because transbuf is not writable.

Citing this message: http://lists.freedesktop.org/archives/gstreamer-devel/2015-October/055188.html

"It's a bug in videodecoder, the same bug probably also exists elsewhere."

Testcase attached.
Comment 1 Thiago Sousa Santos 2015-11-03 18:04:33 UTC
The frame is mapped from gstavviddec.c while decoding and mapping takes 1 extra ref, making it not writable. Happens at gst_ffmpegviddec_get_buffer2

Perhaps we want to use the MAP_FLAG_NO_REF flag to make sure it won't take an extra ref? Would be nice to verify that the buffer won't be unrefed while it happens is mapped.
Comment 2 Thiago Sousa Santos 2015-11-04 13:02:35 UTC
Unfortunately it is not that simple, using the no-ref flag can be dangerous as in some scenarios the buffer in a video frame is replaced and unref'd directly while libav seems to still possess a reference to the frame, causing it to try and unref it again.

Some further investigation is needed, it seems wrong to unref a mapped buffer.
Comment 3 Sebastian Dröge (slomo) 2015-11-04 17:54:53 UTC
Related to this is also bug #740222 and bug #754826
Comment 4 Olivier Crête 2015-11-04 21:01:16 UTC
I wonder if the GstBuffer shouldn't be a gst_buffer_copy'd before being pushed out out of avviddec? or something like that. libav only needs the memories, not the GstBuffer struct.
Comment 5 Sebastian Dröge (slomo) 2015-11-04 21:13:21 UTC
Some GstMemory is not shareable, so that might be problematic in these cases.
Comment 6 Olivier Crête 2015-11-04 21:20:49 UTC
I think NO_SHARED memory is always a mistake, the tracking should be done at the GstMemory level, not at the GstBuffer level. IE, one should always be able to subbuffer mappeable memory, there is no good reason to prevent that, only bad code on our side.
Comment 7 Sebastian Dröge (slomo) 2015-11-04 21:24:38 UTC
I agree, let's make NO_SHARED deprecated then? You do it? :)
Comment 8 Tim-Philipp Müller 2017-07-11 20:56:00 UTC
Before we do, we need to sort out our own use of it, at least in:

- ximagesink
- ximagesrc
- gst-omx
- gstreamer-vaapi
- kmssink
- (vdpau we can ignore I think)
Comment 9 Olivier Crête 2017-07-11 21:19:29 UTC
As a first step, we can document it as deprecated and tell people not to use it in new code.
Comment 10 Olivier Crête 2017-07-11 22:56:20 UTC
Created attachment 355361 [details] [review]
memory: Deprecate GST_MEMORY_FLAG_NO_SHARE

This flag always causes problems as it prevents subbuffering,
instead one should create a custom GstAllocator to pool the GstMemory objects
and not rely on the lifetime of the GstBuffer object they were originally
attached to.
Comment 11 GStreamer system administrator 2018-11-03 12:30:29 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/gstreamer/issues/135.