From: Mike L. <mi...@we...> - 2001-09-13 11:39:55
|
Hi I've just been trying to investigate an apparent (and growing) lag in the dxr3 scr plugin. In versions xine-lib 0.5.2-0.5.3, even though the dxr3 scr_setspeed is called when necessary, unixscr_adjust is called in preference to dxr3_adjust. In the current cvs, dxr3_setspeed seems to be ignored completely, and the system uses unixscr entirely, regardless of the priority assigned to dxr3_scr. Can anyone else confirm this? If so, does anyone mind if I have a go at rectifying the scr selection logic? A few printfs' within the unixscr & dxr3_scr plugins have revealed the following (in xine 0.5.3) (I apologise for the length of this post): xine_init entered unixscr_setpivot unixscr_set_speed unixscr_get_current load_plugins: input plugin found : file load_plugins: input plugin found : DVD ... load_plugins: demux plugin found : QUICKTIME spu decoder plugin found : dxr3-spudec video decoder plugin found : dxr3-mpeg2 video decoder plugin found : mpeg2dec spu decoder plugin found : spudec audio decoder plugin found : a/52dec ... video decoder plugin found : videofill xine_init returning gui_main: LIRC thread created xine: using input plugin >DVD< for this MRL. ... xine: using demuxer plugin >MPEG_BLOCK< for this MRL. unixscr_setpivot unixscr_set_speed unixscr_setpivot unixscr_set_speed xine_play: demuxer started metronom: video stream start... metronom: waiting for audio to start... metronom: audio stream start... metronom: audio stream start...done unixscr_start metronom: video stream start...done unixscr_start dxr3: Entering video init, devname=/dev/em8300. video_out: thread created dxr3scr: init complete video_decoder: using decoder >dxr3-mpeg2< metronom: first video pts => offset = -20733 xine-panel: PLAY xine_set_speed 4 DXR3SETSPEED unixscr_setpivot unixscr_set_speed DXR3SETSPEED unixscr_adjust unixscr_adjust demux_mpeg_block: read_block failed demux_mpeg_block: checking if we can branch to dvd://VTS_01_1.VOB metronom: video stream end metronom: waiting for audio to end... metronom: audio stream end unixscr_get_current unixscr_get_current xine_stop unixscr_setpivot unixscr_set_speed unixscr_setpivot unixscr_set_speed ... xine: using demuxer plugin >MPEG_BLOCK< for this MRL. unixscr_setpivot unixscr_set_speed unixscr_setpivot unixscr_set_speed xine_play: demuxer started metronom: audio stream start... metronom: waiting for video to start... metronom: video stream start... metronom: audio stream start...done unixscr_start audio_decoder: using decoder >mad< audio_decoder: using decoder >a/52dec< metronom: video stream start...done unixscr_start dxr3: Entering video init, devname=/dev/em8300. video_out: thread created dxr3scr: init complete video_decoder: using decoder >dxr3-mpeg2< audio_oss_out: ao_open rate=48000, mode=8 audio_oss_out : 2 channels output audio_out: output sample rate 48000 metronom: first audio pts => offset = -63933 metronom: first video pts => offset = -63933 unixscr_adjust xine_stop DXR3SETSPEED unixscr_setpivot unixscr_set_speed DXR3SETSPEED xine_stop: stopping demuxer metronom: video stream end metronom: waiting for audio to end... xine_stop: done metronom: audio stream end unixscr_get_current unixscr_get_current <snip> Thanks in advance Mike |
From: Eduard H. <ed...@ao...> - 2001-09-14 22:32:59
|
Hello. On Thu, Sep 13, 2001 at 09:08:53PM +0930, Mike Lampard wrote: > I've just been trying to investigate an apparent (and growing) lag in the > dxr3 scr plugin. In versions xine-lib 0.5.2-0.5.3, even though the dxr3 > scr_setspeed is called when necessary, unixscr_adjust is called in preference > to dxr3_adjust. In the current cvs, dxr3_setspeed seems to be ignored > completely, and the system uses unixscr entirely, regardless of the priority > assigned to dxr3_scr. > > Can anyone else confirm this? If so, does anyone mind if I have a go at > rectifying the scr selection logic? As I don't have much time for investigating into this bug, I just explain how the SCR plugins are intended to work. There can be a maximum of 10 (MAX_SCR_PROVIDERS) be available at the same time. As with every plugin, the SCR providers have a common set of functions (methods). The main function of a SCR provider is to provide the current PTS value of the "real time". As the dxr3 itself provides the SCR value and keeps sync for the mpeg and spu stream, only audio has to be kept in sync by xine. Having dxr3scr the one and only plugin available would be sufficient. But the unixscr provider should also be available as a "last resort". So we have at least two SCR providers with the dxr3 active. Usually the two providers would drift away. To keep the SCR providers in sync, a separate thread is launched (metronom_sync_loop). This thread gathers the PTS of the master SCR every 5 seconds, and adjust the PTS of all other SCRs to this value. The master provider is determined via the known SCR priorities. Considering this, I think it is correct that only the unixscr_adjust is called. The _adjust function of all SCR providers is only called when the SCR value is changed by the metronom_adjust_clock function. This function was called by one audio driver in a former version of xine. But this seems no more to be the case. So, if after you have read this and still feel there is a bug, please report back any information you find. The best would be if you manage to track the bug yourself ;-) greetings, -- Eduard Hasenleithner student of Salzburg University of Applied Sciences and Technologies |
From: <bar...@t-...> - 2001-09-24 21:29:59
|
Hi Eduard, On Sat, 15 Sep 2001, Eduard Hasenleithner wrote: > Considering this, I think it is correct that only the > unixscr_adjust is called. The _adjust function of all SCR providers > is only called when the SCR value is changed by the > metronom_adjust_clock function. This function was called by > one audio driver in a former version of xine. But this seems > no more to be the case. humm, I re-introduced this behaviour recently; for small audio gaps adjust_clock is called by audio_out.c - I hope I didn't break anything in the dxr3 scr plugin this way? It should be ok to ignore these calls; audio_out will then insert 0-samples or drop audio packages to sync later. Cheers, Guenter -- time is a funny concept |
From: Eduard H. <ed...@ao...> - 2001-09-28 00:13:41
|
Hi Guenter! I hope that you are well relaxed from your vacation ;-) Ok, back to work. On Mon, Sep 24, 2001 at 11:29:39PM +0200, Guenter Bartsch wrote: > On Sat, 15 Sep 2001, Eduard Hasenleithner wrote: > > > Considering this, I think it is correct that only the > > unixscr_adjust is called. The _adjust function of all SCR providers > > is only called when the SCR value is changed by the > > metronom_adjust_clock function. This function was called by > > one audio driver in a former version of xine. But this seems > > no more to be the case. > > humm, I re-introduced this behaviour recently; for small audio gaps > adjust_clock is called by audio_out.c - I hope I didn't break anything in > the dxr3 scr plugin this way? It should be ok to ignore these calls; > audio_out will then insert 0-samples or drop audio packages to sync later. Oh, thank you for mentioning it. The new audio sync code gives me some headaches. Dxr3 users usually want to sync on the hardware SCR. As metronom_adjust_clock always has the highest priority, ths SCR of the dxr3 is adjusted too. My intention with the SCR plugins was, that every possible SCR sorce implements one. This means that the audio driver should also provide a SCR plugin. Using this, the user can decide which master SCR she wants to have by using the SCR priorities. The former audio code only synced on the SCR, which was very fine. But now, all other SCRs are synced to the audio. This means for example that a future syncfb implementation would also be useless. I intended to write some new audio sync code (as an SCR plugin) but I don't have much time for now. Furthermore some design issues may have to be discussed in advance. What do you think about it? greetings, -- Eduard Hasenleithner student of Salzburg University of Applied Sciences and Technologies |