Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a version of FFMS_GetFrame that lets the user allocate the output buffer #59

Closed
tgoyne opened this issue Aug 19, 2013 · 1 comment
Closed

Comments

@tgoyne
Copy link
Member

tgoyne commented Aug 19, 2013

From kalle.blomster on September 02, 2011 06:37:38

As per the summary. The x264 people have been requesting this since forever; I think it has something to do with memory stride.

Original issue: http://code.google.com/p/ffmpegsource/issues/detail?id=59

@slajar
Copy link
Contributor

slajar commented Jul 17, 2015

Just for your information. I came to the same feature request and I tough about submitting a patch to this issue :) After reading the code and testing some stuff finally I came to the conclusion that this feature request is just a wish for the first place and not a performance boost.
The problem is, that ffms does internally decoding to a frames list. This is great to save decoding time and CPU load and stop frame finding and so on. This behaviour is ideal for mpeg and mp4 and probably all newer container formats as well.
Having a GetFrameToPointer-Function would not prevent any memcpy operation at all since the images are already in the queue. The only thing I could imagine is to work with plain AVFrame there. This would lead to an resampling overload, since avframes would be held in the queue and every time they are retrieved the resampler would run. This is also not a pretty good solution and would lead to more CPU load.

Hence, from my point of view it is not needed to have this function, since it would not solve any issue and it does not save memcpy operations at all.

@myrsloik myrsloik closed this as completed Oct 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants