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
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
