You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: