[Webkit-unassigned] [Bug 213364] [GStreamer] gst_buffer_unmap: assertion 'GST_IS_BUFFER (buffer)' failed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=213364

--- Comment #5 from Xabier Rodríguez Calvar <calvaris at igalia.com> ---
(In reply to Philippe Normand from comment #4)
> (In reply to Xabier Rodríguez Calvar from comment #3)
> > (In reply to Philippe Normand from comment #2)
> > > Comment on attachment 404443 [details]
> > > Patch
> > > 
> > > This looks like a workaround for a bug in the InitData class. As the init
> > > data is quite small (IIRC), doesn't it pay off to have mapped buffer there?
> > > Can't we just copy it?
> > 
> > We could buy I don't think it is necessary because of I am going to comment
> > below.
> > 
> > > Also I see the append() method assuming the m_payload
> > > is mutable, while the createSharedBuffer() has a comment mentioning it
> > > should be considered immutable.
> > 
> > The data inside the SharedBuffer should be immutable, not the SharedBuffer
> > itself. That's why we assert on the mapping to be not WRITE. Actually,
> > appending SharedBuffers as we do is quite efficient as no data is copied,
> > only segments are appended or until it is read if needed.
> > 
> > About keeping the mapped buffer? It is already done, it leaves inside the
> > DataSegment of the SharedBuffer.
> 
> I meant the GstMappedBuffer which goes out of scope in the InitData
> constructor.

Yes, that one. It apparently goes out of scope, but if you follow the SharedBuffer onion, you'll see a & goes down to the DataSegment, it is implicitly becomes a Ref&& and moved into the segment.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200721/0e283907/attachment.htm>