Thomas Worth wrote:
I have a loop that decodes frames using avcodec_decode_video2(), and
am spawning threads to convert the data put into the AVFrame struct
and write it to disk. However, even though I allocated multiple
structs to hold the picture data, frames are overwriting each other:
int maxthreads = 8;
AVFrame *frameData[maxthreads];
for(i=0;i<maxthreads;i++){
frameData[i] = avcodec_alloc_frame();
}
My loop sends a unique instance of frameData to a worker thread, which
pulls the data out, does its conversion, and writes it to disk.
This works OK if I only use one thread. If I use multiple threads, the
frames end up writing all over each other and I get 2 or 3 frames
worth of data on a single frame, always in rows.
How can I keep these AVFrame structs from interfering with one
another? I thought that allocating a unique struct for each would
isolate them from one another.
Thomas,
This explanation may be too late to help you, but let me offer it at
least for future google searchers.
The critical fact you were unaware of is that the decoder returns a
shared object to you. The decoder is allowed to modify that shared
object the next time you call avcodec_decode_video(). So the simplest
solution is for you to copy the pixel data into your own memory buffer
before calling avcodec_decode_video() again.
This behavior is not intuitive, but this is an optimization intended to
avoid copying several Megabytes of pixel data per frame.
A more complicated solution (that I personally have not used) is that
you write your own buffer allocation routine, and replace the pointers
in AVCodecContext.get_buffer() and AVCodecContext.release_buffer(). The
decoder will call get_buffer() to obtain a buffer, and call
release_buffer() when it no longer needs it. If your buffer allocation
routine does reference counting, then you can probably avoid the pixel
copy in your code too.
Note: be sure not to confuse this mechanism with the get_buffer()
function call in libavformat library. It is unrelated.
Anyway, I hope this is helpful.
--
Mike Scheutzow
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
