From: Michael R. <mr...@us...> - 2004-07-01 19:16:51
|
Hi Andr=E9, > > a) Create a framegrab port with xine_new_framegrab_video_port(), > > attach it to your xine_stream_t and retrieve the frame yourself with > > xine_get_next_video_frame(). Before you start the actual playback, > > rewire the output of the stream with xine_post_wire_video_port() fro= m=20 > > the framegrab port to the real video port. Advantage: Easy to code,= =20 > > uses only the public API. Disadvantage: You only get the raw image, = you=20 > > have to display it yourself. =20 > > I've tried doing this procedure, but xine_get_next_video_frame() > freezes. Attaching gdb to the process shows the following: > > (gdb) bt > #0 0x90012588 in clock_sleep_trap () > #1 0x9000d758 in nanosleep () > #2 0x00329f70 in xine_usec_sleep (usec=3D467997) at utils.c:408 > #3 0x00313538 in xine_get_next_video_frame (this_gen=3D0x1239930, > frame=3D0x123aa90) at video_out.c:1155 > ... > > I'm guessing this is because the input/demuxer isn't properly > initialised yet, since xine_play() hasn't been called. That's your fault then. ;) You have to call xine_play() before xine_get_next_video_frame(). The=20 get_next_video_frame is just a replacement for the video output plugin, the= =20 rest of the engine believes it is in normal playback mode and has to be=20 treated as such. > I think that a general way to seek around and get frames in the movie > would be very useful, e.g. for getting keyframe representations. You can also call xine_play() with a new position between=20 xine_get_next_video_frame() calls. Michael =2D-=20 If a packet hits a pocket on a socket on a port, And the bus is interrupted as a very last resort, And the address of the memory makes your floppy disk abort, Then the socket packet pocket has an error to report! |