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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Thu Aug 8 03:53:33 CEST 2013



On 07.08.2013, at 23:43, wm4 <nfxjfg at googlemail.com> wrote:

> On Wed,  7 Aug 2013 21:28:15 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
>> Using VDPAU correctly means checking for preemption
>> and possibly regenerating the context all the time.
>> With the current API there is no context or other
>> user-defined pointer and thus this in not possible
>> unless using some hack like global variables.
> 
> What stops you from checking for preemption? You can still do that
> fine:
> 
> static VdpStatus dummy_render(
>    VdpDecoder                 decoder,
>    VdpVideoSurface            target,
>    VdpPictureInfo const *     picture_info,
>    uint32_t                   bitstream_buffer_count,
>    VdpBitstreamBuffer const * bitstream_buffers)
> {
>    return VDP_STATUS_DISPLAY_PREEMPTED;
> }
> 
> And if a preemption occurs:
> 
> context.render = dummy_render;
> 
> (Which will work because hwaccel doesn't support multithreading anyway.)
> 
> Note that you still can call vdpau functions even during preemption.
> But if you reload the vdpau driver (which might change driver entry
> points, i.e. the decoder_render function pointer changes) you still
> need this hack.

I have no idea what you propose.
How does any of this allow me to free the old resources, create the new decoder and call the decode function again within the decode function?
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.


More information about the ffmpeg-devel mailing list