From: Michael R. <mr...@us...> - 2004-07-02 19:09:37
|
Hi Andr=E9, > > You have to call xine_play() before xine_get_next_video_frame(). The > > get_next_video_frame is just a replacement for the video output > > plugin, the > > rest of the engine believes it is in normal playback mode and has to be > > treated as such. > > Hmm, the whole point was to _not_ call xine_play() :). The problem is > that if I call xine_play() and then xine_get_next_video_frame(), how > can I be guaranteed that I'm actually getting the first video frame? The API guarantees that. That's the whole idea of the grabber ports: The=20 engine has no regular output and therefore the frames (and audio buffers)=20 will be enqueued (and the stream will block, when the fifo is full) until y= ou=20 fetch them manually with the xine_get_next_* functions. > xine_play() may have played 5 or 10 frames already (with possibly some > audio output too). That's impossible, because there is no other way for the frames to be playe= d=20 than through xine_get_next_video_frame(). > You could, but again, can't actually get the current frame. Is there a > possibility of having the xine engine in some sort of "ready" state, > where the movie isn't actually playing (i.e. pumping out video frames > and audio frames to the A/V ports), but can respond to requests such as > seeking, or getting the current frame? That's exactly what the grabber ports do. Michael =2D-=20 /* Identify the flock of penguins. */ 2.2.16 /usr/src/linux/arch/alpha/kernel/setup.c |