Re: [Gnash-dev] post-release task item: removing threads use

[strk]

On Mon, Jun 04, 2007 at 11:59:09AM +0200, Udo Giacomozzi wrote:
> Hello Martin,
> 
> Thursday, May 31, 2007, 4:03:23 PM, you wrote:
> MG> If a 24fps video be running in a 10fps flash movie, won't you need a
> MG> 120ticks-per-second (or rather lowest common multiple t-p-s?
> MG> I would have thought a free-running thread doing the video was
> MG> favourite for this.
> 
> MM doesn't take the lowest common multiple, but instead seems to
> quadruple the nominal FPS. In your case that would be virtually 40 fps
> / not really constant frame refresh.

I provided a patch doing something similar (x20 instead of x4, but was just
a proof of concept). The patch is known as the "tick" patch, basically adding
a "tick" interface ...
This basically fixed the video playback rate on 1FPS movies...

> Don't know much about video
> decoding in Gnash, but do we really need an extra thread to do
> asynchroneous video decoding? I'd expect to simply advance video
> frames until the correct frame has been reached (ie. decode multiple
> video frames while rendering only one new Flash frame when late, or
> not decoding anything when early).

With the "tick" call, and non-blocking reads in tu_file, this would be
possible yes. Using threads would allow system with multiple CPU to use them,
just that.

> MG> How is the high-FPS video running in lower-FPS SWF case handled by the
> MG> current renderers?
> 
> All renderers use nominal FPS rate (from the SWF). But this must be
> handled by the core as that's what tells the renderers the real FPS
> rate.

Handling is very confusing and is different between FFMPEG and GST.

For FFMPEG there's already a separate thread provided by SDL which keeps
playing sound. Last sound frame played drives the video frame to render
on next ::advance. The latter (video frame) is usually one over X frames
which are just discarded.

For GST there's a separate thread too, started by Gnash in this case.
Anyway, the idea is still the same: on ::advance the closest-to-time frame
is rendered, and previous frames are discarded. 

So, as I said: it is NOT handled (video runs at SWF rate)

--strk;