Re: [Gnash-dev] drawVideoFrame

[Benjamin Wolsey]

Am Montag, den 01.09.2008, 09:21 +0300 schrieb Shachar Kaufman:
> The current design in which:
> 1. A frame is decoded by, say, NetStream and pushed to a RAM queue
> 2. video_stream_instance pops the image from the queue and passes it
> along with transform control information
> 3. render_handler draws the pixels
> makes it difficult to accelerate in hardware.
> 
> It is much better to let the video decoder (which by the way deserves
> its own object really which would handle a stream from whichever
> source) perform transformations and draw the pixels - with a callback,
> defaulting to the current scheme. This kind of approach also helps
> letting the decoder control a/v sync. 
> 
> Is there any special reason behind the current design that will make
> my approach fail? 

It sounds like you're still using an old version of Gnash. If that's the
case, please update to current sources (in bzr) before spending too much
time working on improvements, as the codebase changes very quickly.

As far as I know, only encoded frames are queued now and decoded on
demand. There is certainly a VideoDecoder object. Whatever approach we
take, it will be necessary at some point to implement ActionScript
colour transform of the video.

bwy

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil