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; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
