On Apr 10, 2010, at 2:28 PM, Thomas Worth wrote:
Well, I only have one thread that runs avcodec_decode_video2. And the
only reason it runs in its own thread is to allow UI input, otherwise
it would just run in the main thread. That "decode" thread, as we'll
call it, contains the av_read_frame() loop, which contains the
avcodec_decode_video2() function. I pass avcodec_decode_video2's
resulting AVFrame struct that has been decoded to the worker threads.
So, the actual decoding phase only runs once per loop iteration, just
like it would normally.
It seems like the AVFrame struct that avcodec_decode_video2 delivers
(which contains the decoded video frame) is referencing something that
is changed during the next decode cycle. This is the case whether I
create an array of AVFrame*s or just use one. It seems to me that
creating a unique AVFrame struct for each thread would only point to
that exact part of the file, unless the next time
avcodec_decode_video2 is called overwrites all previous AVFrame
structures.
OK, I think the mists are clearing. Yes, with some codecs, the
previous frame will be used. There's some sort of marker that defines
that, I think. What you can do (except, I think in the ffmpeg-mt fork)
is to take more control of the AVFrames yourself by marking them as
under your control, not under ffmpeg's. I bet if you looked at your
sturctures, the data members are being filled in the same - the
AVFrame is just a holder, after all.
You're looking to set the frame's 'type' after it's delivered to you
(maybe even before). That will tell ffmpeg to leave that frame alone,
and it passes responsibility for deleting it to you.
Something like: frame.type = FF_BUFFER_TYPE_USER; as I recall.
Bruce
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
