From: Michael R. <mr...@us...> - 2004-01-07 18:41:19
|
Hi Miguel, > that's exactly what i was expecting from you! to catch the flaws i > didn't thought about. :) I think I found even more problems. See below. > > In the future, I planned to replace the global clock with a local > > clock. > > sounds very reasonable, but i'm not sure if it is 1.0 stuff or > beyond... I think beyond. We must have something to work on after 1.0... > > The logical design would be to attach the clock to the output > > ports, since they are the only component that should require > > syncing. However, with such a design, it is hard for a single > > stream to tell, if it is in pause or running state, since it might > > be feeding more than one output. > > that's a difficult problem indeed. > > however, while i agree that current xine architecture points towards > the association of clocks to output ports, i think such change may > not bring significative improvements over what we have now. Not much, that's true. > i have two situations where i currently miss the ability of a > per-stream pausing or speed changing mechanism: [snip] > attaching clock to output port doesn't fix these problems, and i'm > not sure what it adds over the current solution of creating two > xine_t instances. > > so what is the ideal solution? i don't know, but it would be > desirable to have speed as a per stream property. I think it would be better that way. It's much more difficult, though. Definitely post-1.0. > > Besides that, does your idea fix the most delicate problem > > remaining? (The one I silently ignored, because my new system does > > not fix it either...) I am talking about someone playing a stream > > with a very low framerate, where the decoder hangs in get_frame() > > almost all the time. With my system, a rewire might need up to a > > full frame length to succeed, how does your system handle that? > > just like yours. Well, mine opens an extra thread anyway, so this problem would at least be hidden. > i don't think there is any easy solution to that. > > nevertheless what is a low frame rate? 10fps? i don't think user > would be annoyed because of waiting 1/10th of second to the change > take effect. 1 frame every 5 seconds? > ok, ok. Mike has some really weird streams where frames lasts for > seconds. in that case, latency is huge. but please forget that... > xine is supposed to be more like a movie player, not a fancy > slide-shower! ;-) But then, there are DVD stills. When someone rewires during a DVD menu, the frontend waits for the engine and vice versa. Next problem would come with arbitrary clock speeds. Someone might play a movie in super slow motion. > > Anyway, I will postpone the commit of the new post plugin > > architecture until we discussed that. > > you may commit everything except the async patches. it will be easier > to work on rewiring ideas/proposals with your post plugin cleanups on > cvs. All right. Coming in the next minutes. I am still looking for a rewire solution we all could be comfortable with. Currently, the best idea I have is to have keep get_frame() callers alive by timeouting and returning NULL, if no frame is available. That would mean all decoder's and post plugin's calls to get_frame() had to turn into something like: while (!(frame = port->get_frame(port, ...))) { process_pending_rewiring(); /* only post plugins would return */ return NULL; /* post plugins get_frame() must be aware of being recalled later */ } Michael -- Never trust a programmer who is carrying a screwdriver. |