From: Michael R. <mr...@us...> - 2005-07-28 10:23:57
|
Hi Jason, >> _x_post_frame_copy_down(old, new); >> new->do_something(new); >> _x_post_frame_copy_up(old, new); > > That's indeed what I originally had, because it follows the example > code > in the documentation, but it works tragically bad. There's a burst > of 2 > frames, and then nothing for a full second, repeat. The code that > seems > to work in this case is: > > _x_post_frame_copy_down(passthrough_frame, frame); > passthrough_frame->draw(passthrough_frame, frame_gen->stream); > _x_post_frame_copy_up(passthrough_frame, frame); I just realized what goes wrong here: Since the original frame has reached the video output, it has already passed through metronom, xine's syncing engine. But since you call the full drawing function on the passthrough_frame, it will again be routed through metronom, which confuses it. You might have much more luck with the "correct" copying direction, when you pass NULL as the stream to draw() (which is legal). >> Eventually xine will have a way to execute post plugins (or >> something related) right before the displaying. Then you could >> change your code to something even nicer. > > That might also solve my vf_osd issue. Any sense as to where > something > like this is on the TODO list? I am afraid this has a long way to go... >>> At the very least, the memcpy calls seem somewhat extraneous, and >>> it would be nice to reuse the image buffers of the original frame. >> >> That's not possible, because the frame could still be needed by the >> decoder as a reference frame. > > You might be misunderstanding me. Currently the buffer driver must > allocate memory in a call to update_frame_format. During > display_frame, > it calls get_frame() of the passthrough driver, which itself > implicitly > calls update_frame_format and allocates another set of buffers. > Then I > do a straight memcpy. > [...] > // But reuse the target's buffers as our own ... > memcpy(&frame->vo_frame.pitches, frame->passthrough_frame- > >pitches, sizeof(int)*3); > memcpy(&frame->vo_frame.base, frame->passthrough_frame->base, > sizeof(char *)*3); I get the idea. I think this should work. > This however segfaults inside xv_display_frame(). (Xv being the > passthrough driver, obviously.) I haven't been able to see precisely > where in there it dies. I might have to insert some printfs in > xv_display_frame() to see. But maybe it's apparent to you what I'm > doing wrong? I don't see a problem with the basic idea. >> It would be possible to do that in a post plugin, but that would >> again introduce an offset between drawing the overlay and the >> display. > > But if I did it as a post plugin, wouldn't it stop working when the > video was paused? The application needs to be able to write to the > OSD's buffer and call some sort of sync() interface, and know it > will be > updated. When the app hands control to the post plugin, it could make a copy of the last frame that passed through it, write to the frame and schedule it for display. > Thanks for your replies, Michael. You've been most helpful. Although it is full of hidden limitations, I am always amazed to see how clever people integrate cool new features into the existing xine architecture. Michael |