Re: [AD] Plan for the video addon

[SiegeLord <siegelordex@xxxxxxxxxx>]

On 09/13/2015 06:22 AM, Elias Pschernig wrote:
> How do you control the number of frames the backend decodes? It
> shouldn't decode 1000 frames before the first one is shown, that just
> would waste memory. But it also should not just decode a single frame
> and risk not being done reading the next frame before it is supposed to
> be shown.

I'm leaving this logic entirely up to the backend, but with no 
particular implementation strategy in mind. I think that these sorts of 
decisions can only be made by the backend, because it can actually track 
how long it takes to decode a single frame and thus decide whether it 
needs to skip frames. Same thing with the buffering. A decoding backend 
might have a short buffer and only decode, let's say 2 frames into the 
future, so it will only send a few FRAME_PREPARE events.

My main concern here is to make sure that the API we provide allows 
enough control from the user for the backend to be able to serve the 
frames in a timely manner. Naturally it's a tricky decision without a 
concrete implementation in place...

> If you create the video yourself, you can use
> al_draw_bitmap(al_get_video_frame(), 0, 0, 0)); But an unknown video in
> general can be optimized to use a non-square aspect ratio, so you need
> to query it of course. We could pre-scale the bitmaps, but that would be
> done in software and add quite a bit of useless CPU. Still, I think the
> use of this video addon will mostly be cut scenes where you already do
> know the encoded size.

That's a good point. I guess I'm fine with it as is then. We'll just 
have to document this insight (and provide quick recipes using 'ffmpeg' 
tool).

-SL