Poisoning returned buffers is based around the implicit assumption
that the contents of said buffers are transient. Yet this is not true
for the buffer pools used by the various hardware contexts which store
important state in there that needs to be preserved.
Furthermore, the current code is also based around the assumption
that the complete buffer pointed to by AVBuffer->data coincides with
AVBufferRef->data; yet an implementation might store some data of its
own before the actual user-visible data (accessible via AVBufferRef)
which would be broken by the current code.
(This is of course yet more proof that the AVBuffer API is not the right
tool for the hardware contexts.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com>
---
Another thing that our current API is missing is a reset function
that is called when a buffer is returned to the pool. If there were
such a thing, one could use it for FrameDecodeData.
But before this can be addressed the original sin of using AVBuffer
for everything needs to be fixed.
libavutil/buffer.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 54590be566..e4562a79b1 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -341,9 +341,6 @@ static void pool_release_buffer(void *opaque, uint8_t *data)
BufferPoolEntry *buf = opaque;
AVBufferPool *pool = buf->pool;
- if(CONFIG_MEMORY_POISONING)
- memset(buf->data, FF_MEMORY_POISON, pool->size);
-
ff_mutex_lock(&pool->mutex);
buf->next = pool->pool;
pool->pool = buf;
--
2.30.2
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
