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

[wm4]

On Thu, 8 Aug 2013 03:53:33 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> 
> 
> 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?

The new API doesn't allow you to free old resources (AVFrame references
inside the decoder embed vdpau surface handles), but maybe it doesn't
matter too much: vdpau preemption implicitly marks all allocated vdpau
objects as deallocated/invalid.

You have a point about calling the decode function, but that helps only
if the preemption is for a short moment. Preemption recovery can take a
longer period of time, for example when switching away from X. At least
in my tests vdpau will refuse to reinitialize until you switch back to
X, so what you want to do would block the player completely. Moreover,
calling the real decode function again will not make much sense, since
the surface contents are lost anyway.

The dummy_render function from can be useful when trying to
reinitialize the driver, since libavcodec wants a valid function
pointer even if reloading fails.

In any case, you should talk to Rémi Denis-Courmont.

> 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?