From: Alien999999999 <ali...@us...> - 2004-07-21 14:10:46
|
Op woensdag 21 juli 2004 15:14, schreef Michael Roitzsch: > Hi, > > > i have nothing against using double, except the fact that xine > > parameters (including current way to set/get speed) are integers. so > > extending it would be a matter of just adding a new, integer, > > parameter. > > > > > anyway, is the dropped frames message fixed when going fast? > > > > are you talking about the xine-ui 0.99.1 bug? it is already fixed. > > > > > well, I'd like to have extremely fluid and responsive sound/video speed > > > changes, because I plan to make a frontend to xine in a plugin for my > > > 3D engine... and speed changes in everything would be a very good > > > feature... > > > > as i said, patches are welcomed. Reinhard Nissl is already lobbying > > for a better speed control for his VDR plugin, it would be nice to > > hear opinion from other developers about it... > > Here are my ideas about playback speed: I think we have two separate > concepts of playback speed in xine: > > The first is the current one, which is the speed of the clock the playback > is synced to. My idea is to solve this completely different in a post-1.0 > API. What we actually need is a way to create and attach clocks to output > ports. This should be quite easy since the output ports are already the > only xine components that need a clock. I think all output ports should by > default be attached to some xine_t-global default clock, but frontends can > attach different clocks. Of course, different clocks can have independent > speeds and, more importantly, outputs with different clocks can be paused > independently. > > The second speed is the mapping from logical timestamps to real-life time. > We need a way to alter this mapping so that a stream's timestamps will be > translated to physical time in an arbitrary way. My idea would be to > incorporate this mapping into metronom. For a given PTS-delta, the > VPTS-delta created by metronom should be larger or smaller by an arbitrary > speed factor. Of course audio out has to do some adaption by resampling the > output, but we already have code for that, which should be possible to > extend. > > Maybe, if the second solution works well, we can reduce the clocks in the > first concept to two speeds: paused and running. But I am not sure about > this yet. I can think of applications, where one might need to set both > speeds independently at the same time. Example: Video compositing. The user > wants to combine two streams with a post plugin to one output. One of the > streams has to run at a different speed than the other, so the metronom > speed factor has to be set. Now the user wants to play the resulting > composite in slow motion, therefore the output clock needs to be set to a > different speed as well. > > (Btw, I realised some time ago that VPTS is not the best term. What is > virtual about these timestamps? I think MPTS = monotonic PTS would describe > it more clearly...) > > Michael I'm not sure i understand you, so I'll give an example of what i think you are saying (correct me if i'm wrong) global==665 PTS/sec (for normal time (independant of playback speed)) - xine ==2.0 (double playback speed) - audio_out ==1.004 (correct sound drift) - audio_out ==0.995 (to sync with second output card) - video_out ==1.001 - video_out ==0.654 (mixing with a stream that's playing slower) (M) - video_out ==1.200 (mixing with a stream that's playing a little faster) - spu_out ==1.000 - spu_out ==1.012 (M) in a video editing program, this would be a possible occurance: -every item needs to be in sync and some streams are running faster or slower. -the whole thing is played at double playback speed -the second spu and the second video_out is muted (M) (meaning it's unapplied (invisible), but not paused) is this what you are telling me, or do i have understood it wrongly? -- Alien is my name and head-biting is my game |