On 2018年02月12日 07:09, Mark Thompson 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.)
Sounds good to me. I think your suggestion is an good enough solution.
And some idea from me I am not sure if it helps.
You can add some warning message in vf_hwupload when a HWContextType needs fixed pool and user does not set one to notify user could further tune that value through extra_hw_frames. like if the pipeline does not work, user could increase the value. If memory consumption is a problem, they can decrease the value.

Ruiling

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

_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to