Hello Michael,
do you think the patch could be merged in its current state?
It is functional, maybe I can do the cosmetic changes later.
I was a bit busy the last weeks.
Would be nice if it could get into the 3.5 / 4.0 release.
Felix
Am 02.01.2018 10:23, schrieb Felix Matouschek:
Am 28.12.2017 um 19:20 schrieb Michael Niedermayer
<mich...@niedermayer.cc>:
+ av_image_copy_to_buffer(pkt.data, pkt_buffer_size,
+ (const uint8_t * const *)
image_plane_data,
+ image_linestrides, ctx->image_format,
+ ctx->width, ctx->height, 32);
Is the copy needed ?
can the data not be put in a AVPacket without copy but by pointing to
the image?
the AVPackets deallocation can be overridden to free the image
I’m not sure but I guess it could lead to problems as the AImageReader
has its own queue, which is currently limited to two images. In
general the image_available callback is processed fast enough so this
is not a problem and all AVPackets are buffered in the thread message
queue (ctx->input_queue) while the original AImage is deleted. Every
AImage is also permanently associated with the AImageReader and needs
to be deleted for the AImageReader to accept new images. I think if
doing so the input_queue and the AImageReader queue probably need the
same size.
How could I put the different pointers I get from the Android system
for each plane into the AVPacket? I’m not even sure if all planes live
in the same contiguous space of memory? How does one overwrite the
AVPacket deallocation?
Currently I’m using AImageReader_acquireLatestImage(), this should be
changed to AImageReader_acquireNextImage(), other than that it could
work.
Felix
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
