On 11/02/18 23:30, wm4 wrote: > On Sun, 11 Feb 2018 23:09:51 +0000 > Mark Thompson <[email protected]> wrote: > >> On 11/02/18 07:21, Song, Ruiling wrote: >>> I have run some test against the patches. It works as described. >> >> Great - there is general agreement on that part now so I've applied that >> series. >> >>> Are you still against setting a default value within qsv_init_pool()? >>> Users can easily override the default value through the interface you added. >>> And if they did not set a value, the default value will be used. >> >> I don't mind the idea but I'm against the specificity of it, I guess. The >> single value will help in the isolated hwupload case, but it would be >> inconsistent with other APIs and doesn't suggest a sensible value to anyone >> who does need to set a fixed pool size. >> >>> If you are OK, I will re-submit the patch and add more comment on the magic >>> value. >>> If you are against, we can discuss it further for a better solution. >> >> Returning to suggestions made before, how would you feel about adding some >> way to determine from a device how big a frames context should be for it? >> >> The simplest method to do that would be to add a new element to >> HWContextType containing a sensible value. If it's zero, dynamic allocation >> is supported and noone needs to care any further. If it's nonzero, then it >> becomes the default value for pool size used in the absence of any other >> choice. It would be used in av_hwframe_ctx_init() if it's set on the type >> and initial_pool_size is zero, which would fix our hwupload case. Probably >> it would want some way for the user to access it as well - new API for >> retrieving property values somehow, maybe? (Not sure about that bit.) >> >> Would that work for you? Anyone want to offer any criticism / other ideas >> which don't depend on semi-mythical rewrites of lavfi link negotiation? > > Still feels kind of arbitrary.
Yeah, but we need something arbitrary to get around this problem. > What exactly determines the size the > hwcontext will propose? It would be something like the largest number of frames that the worst consumer of that frame type might need in some nebulous "typical" case, plus the number that a non-decoder producer might need (probably two). But, more importantly, the arbitrary value can be set for each API independently... - Mark _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
