[FFmpeg-devel] [RFC] av_decode_video and CODEC_CAP_DR1

Cyril Russo stage.nexvision
Tue Jun 8 08:46:56 CEST 2010

Le 07/06/2010 22:50, Reimar D?ffinger a ?crit :
>> it would lead to slower code and unneeded copying, this is not how lavc
>> is designed.
> That was my first thought as well, but I think there may be a misunderstanding.
> I think the idea is to only change the currently invalid case (no DR1 and
> overridden get_buffer), so it would not cause any slowdown per se.
> However I still have my doubts, since users might inadverdently trigger
> this slow copy case, particularly since when built against share libraries,
> doing
> codecContext.get_buffer = default_get_buffer;
> can lead to
> codecContext.get_buffer != default_get_buffer
> when evaluated inside the library.
> (not to mention applications that just set get_buffer to a wrapper around
> default_get_buffer that does some logging, or "garbage collection" in case
> the allocation fails or...)
You're right, there is no change in the current behavior (same speed) 
for DR1 capable decoders (all of them except schrod/dirac).
The idea is to simplify user code, and make documentation easier to 

Currently it appears in the documentation like CAP_DR1 is an exception, 
while, in reality, it's the rule, and I think it'll be a good idea to 
update the code to reflect this.

There is like a flaw in the logic here, since if you're using the 
decoded buffer in direct rendering mode (no copy) in another thread, 
then you don't know what to do in get_buffer when a codec doesn't 
support DR1.
So this leads to something like ugly static/global boolean 
"copyPictureAfterDecoding" set in get_buffer/codec initialization, and a 
second code path in that case in the decoding part.

I propose to fix this somehow inside the 2 codec that don't use DR1, so 
that this specific case is inside the codec black box, and thus, remove 
the user code double code path ugliness.

More information about the ffmpeg-devel mailing list