2019年10月29日(火) 7:51 Bian, Jonathan <jonathan.bian(a)intel.com>:
I am not sure about the context of the comment you mentioned in
gstreamer-vaapi, but VABuffer can be used as long as they have not been
Thanks for clarifying.
The reason for vaUnmapBuffer() is that it will force host CPU cache
flushes, before the driver operates on the buffer. The "SyncBuffer" you
mentioned below basically achieves the same so I don't see a need to add a
Once vaUnmap is called, we need to vaMap again to modify the buffer next
That will change a mapped memory address every time.
I wonder if there is a way that each VABuffer is mapped the same cpu memory
address as previous mapping of the VABuffer.
If there is SyncBuffer, we don’t need to vaMap every time and the mapped
memory address is unchanged.
From: Hirokazu Honda <hiroh(a)chromium.org>
Sent: Sunday, October 27, 2019 8:41 PM
Cc: Balachandran, Sreerenj <sreerenj.balachandran(a)intel.com>
Subject: [intel-vaapi-media] VABuffer is recyclable?
I am thinking to recycle VABuffers in video processing.
A VABuffer created by vaCreateBuffer() intuitively only has to be
destroyed when a buffer is no longer needed, that is, in the end of the
I checked gstreamer-vaapi code today. VABuffer used on video encoding is
always created and destroyed in encoding each frame .
There is a comment.
> /* XXX: vaRenderPicture() is meant to destroy the VA buffer implicitly
If this is true, we cannot reuse VABuffers during video processing.
Besides, I am curious if we really need to vaUnmap before a driver reads a
content modified by an application.
VA-API documents vaUnamp needs to be called in order to notify a driver
can consume the buffer by the driver .
But, in this way, we need to map/unmap in every buffer modification. I
wonder if we can have SyncBuffer, similar to SyncSurface, to avoid
What do you think?
Thanks in advance,
intel-vaapi-media mailing list -- intel-vaapi-media(a)lists.01.org To
unsubscribe send an email to intel-vaapi-media-leave(a)lists.01.org