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? Thanks, - Mark _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
