[vlc-devel] More clocking observations ...
j.zorko at att.net
j.zorko at att.net
Wed Jun 4 23:13:37 CEST 2003
Gildas et al ...
Firstly, I do appreciate all of the work you and the rest of the VideoLAN team have put into this
project ... even with it's flaws, it's quite impressive and, once its' issues are worked out, it promises
to be one of the best media players, for any platform.
That being said, i've made some progress on the clock skewing problem relating to seeking a lot.
If I modify input_ClockManageRef() thusly:
*****************************************************************************
* input_ClockManageRef: manages a clock reference
*****************************************************************************/
void input_ClockManageRef( input_thread_t * p_input, pgrm_descriptor_t *
p_pgrm, mtime_t i_clock )
{
/* take selected program if none specified */
if( !p_pgrm )
{
p_pgrm = p_input->stream.p_selected_program;
}
if( ( p_pgrm->i_synchro_state != SYNCHRO_OK ) || ( i_clock == 0 ) )
{
/* Feed synchro with a new reference point. */
ClockNewRef( p_pgrm, i_clock, mdate() );
p_pgrm->i_synchro_state = SYNCHRO_OK;
if( p_input->stream.b_pace_control
&& p_input->stream.p_selected_program == p_pgrm )
{
p_pgrm->last_cr = i_clock;
printf( "* synchro not ok* PCR clock -- waiting %qd before reading more data\n", i_clock );
mwait( ClockToSysdate( p_input, p_pgrm, i_clock + 35000 ) );
}
else
{
p_pgrm->last_cr = 0;
p_pgrm->last_syscr = 0;
p_pgrm->delta_cr = 0;
p_pgrm->c_average_count = 0;
}
}
else
{
.
.
.
}
This was just an experiment. Since I noticed that the mwait() call in the synchro case (right after
the printf() I added) was always returning immediately (time had already passed), and since this
was getting called after every seek, and since my ff / rew stuff seeks a lot, I figured that this may
be the gate that was left open to the FIFO, if you dig. So, I noticed that the average time for the
MP3 frames of the 320K MP3s that iTunes made for me was about 32000 or so, so I added 35000
to the time to mwait() for.
Result: much much better ... I can ff / rew to my hearts content, and the audio never speeds up at
all. It occasionally played slower, probably 'cuz that number is just a rough estimate and could be
lower (and most likely is sometimes, being dynamic).
This isn't a fix, just an observation i've made that leads me to believe I may be able to fix this nasty
bug today, once I grok the clocking code a little better. Am I on the right track? Any comments
from anyone? Am I way off?
Regards,
John
--
Falling You - exploring the beauty
of voice and sound
http://www.mp3.com/fallingyou
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel
mailing list