On Mon, Feb 15, 2016 at 3:13 PM, Ivan Kalvachev <ikalvac...@gmail.com> wrote: > On 2/15/16, Ronald S. Bultje <rsbul...@gmail.com> wrote: >> Hi, >> >> On Mon, Feb 15, 2016 at 8:26 AM, Ivan Kalvachev <ikalvac...@gmail.com> >> wrote: >> >>> On 2/15/16, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >>> > On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev <ikalvac...@gmail.com> >>> > wrote: >>> >> Do not remove HWACCEL flag with FF_API_XVMC since the >>> >> flag is supposed to be used as generic one. >>> >> >>> > >>> > The flag is unused except by the XVMC decoder, so removing it with it >>> > seems appropriate. >>> >>> Should I add it to the other hwaccel decoders? >> >> >> Would it have a real-world purpose? > > Does any of the other Capability flags serve any real-world purpose? > e.g. CAP_DRAW_HORIZ_BAND or CAP_DR1. > > The *_BAND indicates usage of draw_horiz_band callback(). > The * _DR1 indicates usage of get_buffer(),
DR1 could probably be removed as well, since practically every codec we have does it this way now. But removing existing things and adding new things are entirely different topics. > The *_HWACCEL is supposed to indicate usage of get_format() and > availability of certain data, when it is called. > > Since the trend is removing codecs that do only hwaccel, > I think it is useful for the application to know that the codec > can do more than software decoding. > This is hardly useful, because hwaccels do not "just work", for proper hwaccel support you need to hardcode the available codecs in your application and appropriate conditions for them, so things like profile checks, hardware compatibility checks, etc can be implemented. A generic "this codec does hwaccel" flag is not very useful here. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
