[FFmpeg-devel] [RFC] av_decode_video and CODEC_CAP_DR1

[Cyril Russo]

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 
understand.

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.
Regards,
Cyril