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. What exactly determines the size the
hwcontext will propose?
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to