[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] post-release task item: removing threads use
From: |
strk |
Subject: |
Re: [Gnash-dev] post-release task item: removing threads use |
Date: |
Mon, 4 Jun 2007 12:38:54 +0200 |
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;