From: <br...@it...> - 2005-10-26 08:30:56
|
Hi Dischi, From dm...@sa... Wed Oct 26 02:54:44 2005 ... Bruce Janson wrote: > I too had similar problems playing DVB-T streams: the rate > that xine assumed for the stream appeared to be (very) wrong and > so rendered both xine_get_pos_length() and xine_play() inaccurate. > Eventually, I arrived at the following two-step workaround: > > - In the main loop of the UI thread, periodically execute > > xine_get_pos_length(stream, (int *)0, &xine_time, (int *)0); > gettimeofday(&actual_time, (void *)0); What happens if you play at double speed? ... It turns out that xine_get_pos_length()'s inaccuracy varies with playing speed (Perhaps you suspected that this would be so? :-)), but calculation of the correction factor adjusts accordingly. > - Now, when we want to jump to a new location -- "p" -- in > our file/stream we can execute a binary search based on > the pair: > > xine_play(stream, 0, p); > xine_get_pos_length_corrected(stream, (int *)0, &xine_time, (int *)0); > > By comparing the achieved location (returned in xine_time) > with the desired location (specified in p) we can derive a > second correction factor for xine_play() and finally, a new > function: > > xine_play_corrected(stream, 0, p); > > Fortunately, both of these correction factors appear to be simple > linear multipliers of the arguments (or results) of the primitive > functions so, once calculated they remain useful for the rest of > the stream/file. A patch would be nice. Right now, seeking in dvb-t streams is very wrong and seeking in mpeg streams without pck header isn't working at all. ... The above workaround (kludge) is implemented entirely in a test UI frontend. I'm not yet familiar enough with the libxine internals to know where such a patch should go within that library, let alone whether it would be an appropriate solution to the problem. Regards, bruce. |