On Sat, 06 Sep 2014 18:59:30 +0300 Rémi Denis-Courmont <[email protected]> wrote:
> Le samedi 6 septembre 2014, 17:28:59 wm4 a écrit : > > > Specifically as regards preemption, I think it remains doable. In > > > principles, this makes no real difference; you can still wrap the > > > callback in a similarly inconvenient manner as before and with the same > > > limitations. > > > > Have you actually implemented it? > > I don't need to implement to make an informed guess on the feasibility. Your API design pretends preemption doesn't exist. You're ignoring a major aspect of the vdpau API. I don't see how this is reasonable. > With this patch, there are only two changes that may be relevant to > preemption: > > 1) The DecoderRender callback is resolved via another callback instead of set > directly by the application. You can still provide a custom render callback > (through a GetProcAddress wrapper) as before and it will be called as before. Rejected. Too messy. You'd have to emulate and proxy half of the vdpau API here. You can't be serious. > 2) A few new callbacks are used during initialization. If they fail, > libavcodec will invoke get_format() again, so there should be no need to wrap > them for the same of preemption, but you can do it as in the previous bullet > if you want. > > 3) One new callback is used during de-initialization. There is nothing useful > to do, so you don't need to wrap it. But you can wrap it too. > > Furthermore, libavcodec does not override the preemption callback; you can > use > it or skip it as before. The presumed race conditions still exist unchanged. > > > > Of course, backward compatibility will break if/when new chroma types are > > > implemented, e.g. Hi10p. Sorry but I *told* *you* *so*. IIRC, you were > > > among the developers to object to different pixel formats for different > > > chroma types. I can still make that change if people changed their mind. > > > > Against pixel formats - not necessarily against a mechanism to set the > > chroma type. > > That distinction makes no sense. If you keep the old pixel format while > introducing a new chroma type, you break contemporary avconv and contemporary > VLC, and presumably all contemporary applications. > > You can argue that this is a bug in the applications. But it makes no > difference to the fact that compatibility with them will will break. The right way to do this backwards compatible is to have the application set a field that other chroma types are supported too. Well, I'm not really sure what you're arguing, because with the current API, the application has to create the decoder itself, and AFAIK there's no issue with other chroma types. For the new API, if there's really a reason new chroma types could somehow break applications, then just let the application set a list of supported chroma formats. > > Anyway, this is somewhat orthogonal to this patch, isn't it? > > Indeed this is not directly related to this specific patch 1/8. This refers > to > patches 5 and 6 in the same series. > > > > > A solution to this might be not deprecating the "old" API. Then > > > > downstreams can wait it out until the API finally becomes sane after a > > > > bunch of more incremental improvements. This is true for the other > > > > hwaccels as well (since I always hear of hwaccel 1.x...). > > > > > > The whole point of the series is to insulate applications from: > > > - new codecs, profiles and levels (for real), > > > - new chroma types, > > > - new function calls (as far as possible). > > > > > > If we postpone the change, all VDPAU-enabled applications will need > > > updates > > > for HEVC then Hi10 and who-knows-what later. That seems like a worse > > > alternative on all counts. > > > > These applications need a change anyway. > > You are inconsistent here. First you complain that the VDPAU interface > changes > too often, and then you argue that the interface should be changed for HEVC > and then for Hi10p. I'm against changing it now, and then changing it again once HEVC etc. are finalized. > > Why can't this change wait > > until HEVC and Hi10 (if the latter ever happens) are set in stone > > API-wise? > > No thank you. One change now versus three changes latter, I pick one any time. My point is that a larger number of API changes is worse. I'm not sure how hard that is to understand. 3 changes (on reach downstream) vs. 1. > > > My NVIDIA colleagues and I would also prefer to have more exemplary code > > > in > > > libavcodec. I cannot say that I am satisfied with the current state of > > > affairs. In fact, I wanted something like this patch from the beginning. > > > Only at the time, that was not yet possible for lack of init, uninit and > > > priv_data_size. > > NVIDIA should probably work on making preemption reasonably > > implementable (preferably by deprecating and removing it), so we don't > > have such problems in the first place. > > Again, if you have objections to the VDPAU interface definition, you can take > it to the public VDPAU mailing list on FreeDesktop.org. You won't solve it on > libav-devel. > My main problem is actually not with preemption (I assume NVIDIA won't do anything anyway by now), but with the fact that each step in Libav API design makes it less possible to handle preemption. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
