Hi, On Tue, Feb 16, 2016 at 8:25 AM, Ivan Kalvachev <ikalvac...@gmail.com> wrote:
> On 2/15/16, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > 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. > > That's not correct - *_HWACCEL isn't new thing either. > > You do understand that blocking this change means > removing existing thing, don't you? > > > >> 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. > > Yes, it is not mandatory for decoding. > > But that's true for all capabilities flag, including the threading ones. > If your application supports threading you can always use the thread > safe functions. > Hold on a minute, these aren't remotely the same. The slice-thread or frame-thread flags indicate that the decoder supports a form of MT, and has significant effect on how the decoder is invoked. These flags are not informational-only. There's other flags that are not information-only also. Please distinguish between them. > The capability flags are there to make things simpler. > No. This is really important: no. The capability flags are to indicate capabilities of the codec such that common code (inside ffmpeg!) can invoke the decoder functions correctly and most optimally. Calling a single-threaded-only decoder with MT will cause corrupt decoding and crashes. That's bad. Likewise, invoking single-threaded decoding on a MT decoder will cause a significant slowdown. Also bad. The hwaccel flag is informational. The actual capability is checked by existence of the ACHWAccel with that particular codec id. These info-only flags can easily be forgotten or be misinterpreted. The AVHWAccel check I indicated to you is more complete, more informational and guaranteed to be correct for the particular target platform you're on. Currently the only way an application could find that given codec > supports hwaccel > is to decode a frame, wait for get_format() callback and check the pixfmt > list. > > Ronald proposed to implement public function that would > query if given codec support given hwaccel pixfmt. > It's good, but it is not simple. > (Listing decoders is 400+ codecs * 10 hwaccel types, > traversing 40+ element table for each combination.) > So your CPU is from the mid-60s? I mean, you can do that in 1/100th of the time it takes to decode one block in a modern video codec. And that's an issue for initialization code why exactly? Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
