Le lundi 24 mars 2014, 22:44:51 wm4 a écrit : > > You configure the decoder, you feed it the surfaces. All hwaccel was > > doing was just feed the decoder the slices and get back the opaque > > frames to you.
> Yes, but you still need to create the surface. Now assume you created a > decoder that expects 422 surfaces, and you give it 420 surfaces. It > will probably break. And the hwaccel API user basically can't know > which format it should use to create surfaces. > > So yes, I'm starting to see a problem here too. It's not a current > problem because everything assumes 420, but as hardware decoders gain > more features, it could become one. Though 422 would presumably be a lot less invasive to the hardware design than 9/10-bits, still extra transistors mean larger die which means higher costs... This would only make sense if there were a big market push for 422. I am actually more concerned about get_format() passing more than one software pixel format at once, than about hardware acceleration supporting 422, in the future. If the choice were between NV12 and YV12, there would be no ambiguity regarding the bits depth and colour subsampling. But if it were between 8-bits and 10-bits (say because a codec supported high-depth as an enhancement layer) or between 420 and 422, then using "the" software pixel format as reference would no longer work. In fact, it would no longer mean anything. My view is that so long as get_format() is used to select hardware acceleration, it needs provision to convey the surface type(s) and select it if there are more than one possibilities. There may be other ways to achieve it than multiplying pixel formats, but overloading the meaning of "the" software pixel format within the list does not seem very robust or future- proof. -- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
