GNOME Bugzilla – Bug 739693
assrender doesn't render frames into given memory area
Last modified: 2018-11-03 11:32:15 UTC
i've done some debugging and by the looks of it, the videosrc buffer data pointer changes during this line (in gst_ass_render_chain_video): gst_video_frame_map (&frame, &render->info, buffer, GST_MAP_WRITE); if the rendering is supposed to be written into a specially allocated dma area, this will cause the need for an extra memcpy. this may be a general gst_video_frame_map problem or just me not correctly understanding yet, how this works.
Can you show us the code for your special dma allocator / GstMemory ? What is the buffer refcount when (before) calling _map() ? Have you tried with a normally allocated video buffer?
Created attachment 290078 [details] [review] this is where i added the extra pointer debug lines in bad-1.4.1 gstassrender.c
Created attachment 290079 [details] GST_DEBUG_FILE=/testProgs/dreamsubbin_changedpointers.log GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:0,dreamsubbin:4,*ass*:4 /testProgs/gst/dreamsubbintest "file:///media/net/Videos/Anime/Fairy Tail/Watched/[Ho
I basically get a pre-allocated dma pointer from my application which i then wish to render the subtitles to. therefore, in my gstreamer element i create a new buffer with this memory area, memset an empty bitmap there and push it into assrender (via subtitleoverlay). it arrives there, correctly (i was tracking that by multiple debug outputs) and changes after the gst_video_frame_map call. this is how i create the buffer. gdi_data is my fixed pointer: nv12frame = gst_buffer_new_wrapped_full (GST_MEMORY_FLAG_PHYSICALLY_CONTIGUOUS, gdi_data, size, 0, size, NULL, NULL); i display the pointer of the buffer's data using the three lines GstMapInfo map; gst_buffer_map(buffer, &map, GST_MAP_READ); GST_INFO_OBJECT (buffer, "....... data@%p refcount=%i", map.data, GST_OBJECT_REFCOUNT_VALUE(buffer)); gst_buffer_unmap(buffer, &map); there's probably a cleverer way how to do it though. it shows that during gst_video_frame_map, the refcount is increased from 1 to 2 and the flags and the pointer changes.
i forgot to answer your other question. the change of the pointers happens in the same spot if i create the buffer letting gst do the allocation with a plain nv12frame = gst_buffer_new_allocate (NULL, size, NULL);
so it does the copy because this gst_buffer_map operation has the flag GST_MAP_WRITE, even though refcount=1 and writable=1 i dived through gstbuffer.c and gstmemory.c into gstminiobject.c it turns out that the gst_memory_lock() call in gst_memory_map() fails at this condition in gst_mini_object_lock() /* access_mode must match */ if ((state & access_mode) != access_mode) debug output is lock failed 0x72006800: state 00010101, access_mode 2 as a result it then allocates new memory for this buffer a few lines down below in the log i see that the lock also fails the other way around for a different memory lock failed 0x709aa008: state 00010102, access_mode 1
Is this still an issue with the latest GStreamer release?
Retesting this under realistic environment will probably take me the greater part of a whole day of my free time, a little too much effort for an unsubstanciated check... or have there been changes that realistically could have fixed this?
Fair enough. Setting it back to NEW for now, but it does need someone to be able to reproduce it, otherwise it's not actionable as it is.
Correcting myself: If the problem is indeed in gstminiobject.c , it's actually quite likely that it's been fixed, or at least the behaviour has changed, since 2014. Let us know when you have any news!
-- 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/140.