In resizing example, the approach to dealing with the video buffer size is wrong
Closed this issue · 3 comments
From LibVLC's point of view, it only ever needs a buffer of the precise size to render the video frames according to the intrinsic size of the video.
So, if the video is 1280x720, that's the buffer size that LibVLC wants us to allocate.
It does not matter at all what size we are going to render the video frame at, the native buffer size should match the video dimension.
The current example allocates a buffer large enough for the entire screen - this is completely redundant.
In terms of rendering the video, the application itself (not LibVLC) is responsible for scaling the video frames.
For example, in Java2D, if we use a BufferedImage, we paint the BufferedImage with an appropriate AffineTransform (and ideally bilinear rendering hints) to scale the video into our target component.
The approach with JavaFX will be similar.
In short, allocate the buffer size according the width and height LibVLC tells us, and scale the image in the client application when we render it.
On reflection, it may not be "wrong" - the current approach does save one full copy per frame.
The alternate approach requires an intermediate image.
Honestly I don't know which approach is better. I like the new approach as per the original comment in this issue, because it matches more how it's done with vlcj using the other UI frameworks and the code seems simpler and cleaner.
On the other hand, the number of full frame copies is clearly better to be less rather than more.
Currently, the examples have all been changed to use this new approach.
They are just examples, application developers can implement it however they want of course if they prefer the old approach.