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. 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. 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. > 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. > 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 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. -- _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
