On Tue, 02 Feb 2016 20:15:56 +0200 Rémi Denis-Courmont <[email protected]> wrote:
> Le 2016-02-02 17:26, wm4 a écrit : > > On Tue, 02 Feb 2016 14:53:46 +0200 > > Rémi Denis-Courmont <[email protected]> wrote: > > > >> Le 2016-02-02 14:29, wm4 a écrit : > >> > I'll ask my favorite question for vdpau related things: how does > >> this > >> > handle display preemption? > >> > >> I think that there are no reasonable ways to handle display > >> preemption. > >> As soon as libavcodec handles anything more than individual > >> VdpDecoderRender calls, then display preemption handling becomes > >> impractical, if at all possible. This is because there are no ways > >> to > >> ensure that the application rather than libavcodec gets The One > >> preemption error. > >> > >> Now, I don't mean to say that we should necessarily ignore display > >> preemption. However, if we want to handle display preemption, I > >> think we > >> have to create a common VDPAU wrapper shared by libavcodec and > >> VDPAU-capable libavcodec applications. With that, we can (among > >> other > >> things) catch the preemption error safely and, say, make all later > >> VDPAU > >> calls fail safe until objects are destroyed. > >> > > > > > >> Conversely, if we stick to plain libvdpau as it currently exists, I > >> think we have to forget about display preemption and pretend it does > >> not > >> exist. > > > > I can't forget that it exists, because it will be triggered by e.g. > > display mode switching. > > All I'm saying is that either a VDPAU wrapper is involved, or > preemption is not handled. If you think that preemption must be handled, > then that means you need a VDPAU wrapper. > If you write such a wrapper, I'll be all for using it. Otherwise, I'll prefer a solution that is somewhat more light-weight and less intrusive. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
