[FFmpeg-devel] [PATCH] Try to make new VDPAU usable by adding context to callback.

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Aug 9 22:46:46 CEST 2013


On 09.08.2013, at 09:27, wm4 <nfxjfg at googlemail.com> wrote:
> On Fri, 9 Aug 2013 08:57:53 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
>> 
>>>>>> How would I even be able to handle the return value of the render function in general, no matter the cause of error? (if you don't care about losing more frames than necessary I guess you coukd handle preemption outside the decode loop, but that seems at least suboptimal).
>>>>>> lavc ignores the return value, and any wrapper would have nowhere to store it.
>>>>> 
>>>>> Maybe lavc should check the return value, and return it from the
>>>>> libavcodec decoding function?
>>>> 
>>>> Remapping all possible VDPAU errors to FFmpeg ones? That's going to be
>>>> fun...
>>> 
>>> Well, OK, but maybe at least render2 should be able to return a ffmpeg
>>> error code?
>> 
>> That is why it has an int as return value actually :-).
>> Integrating it so that libavcodec actually returns that is missing though.
> 
> Isn't it just a matter of forwarding the error code?

Checking that was on my todo, and I am doing that now.

> By the way, I think your patch missed the render call in
> vdpau_h264_end_frame.

Only the first version had that issue I believe.
Also I realized there is no reason to pass the surface explicitly when the function now is passed an AVFrame.
Also for reference frames this is admitedly all a bit messy, since you have to go through the buffers and adjust the references if you want to update them after preemption to be completely correct.
Though in principle it's possible to just leave that to VDPAU to figure out, and just make sure to handle whatever surface is the current output surface.


More information about the ffmpeg-devel mailing list