On Dienstag 23 Januar 2007 01:25, Torgeir Veimo wrote:
> On 22 Jan 2007, at 20:26, Stefan Lucke wrote:
> > So my system skips around 9 to 10 frames per minute.
> > 60 * 25 = 1500 frames.
> > So the TV frame rate is 25 * 1490 / 1500 = 24.833 Hz .
> >
> > I guess I've to ask Ville if there is a way to increase the dot clock
> > of my card in some way.
>
> This assumes your soundcard is perfectly clocked to the incoming DVB
> stream? I'd assume that eventually if the soundcard is a bit faster
> than the DVB stream, you'd get an xrun. Maybe it's an idea to add
> xrun counts as well.
Yes, there are e few assumptions which may slightly influence calculation.
These numbers are from recording playback. During live view, they are
a bit different, but the direction is the same.
The other way, we have to issue additional delays, because of some
errors we lost about 9 frames is bad too. Let's look at the code:
1. calculate current audio / video offset:
if ( aPTS )
offset = aPTS - pts ;
else offset = 0;
if ( abs(offset) > 100000)
offset=0;
To my opinion thats ok.
// this few lines does the whole syncing
int pts_corr;
Bad thing starts here. Only 1/10 of offset is taken into account
for further calcs.
// calculate pts correction. Correct 1/10 of offset at a time
pts_corr = offset/10;
Even worse, correction value is clamped to +/- 2/10 frametime for
next frame delay calculation.
To understand that this is bad, you haave to remember that directfb ouput
ingores all delays which are lower than one frame duration of out device.
//Max. correction is 2/10 frametime.
if (pts_corr > 2*frametime() / 10 )
pts_corr = 2*frametime() / 10;
else if (pts_corr < -2*frametime() / 10 )
pts_corr = -2*frametime() / 10;
// calculate delay
delay += ( frametime() - pts_corr ) * 100;
// update video pts
pts += frametime();
Again clamping. Negative delays are out of interest. Positive delays are
limited to 2 frames which is ok to my opinion.
if (delay > 2*frametime()*100)
delay = 2*frametime()*100;
else if (delay < -frametime()*100)
delay = -frametime()*100;
Finally I guess this handling should be delegated to the output device,
as there might be the chance that it could adjust the frame rate on demand.
I like to have a calculation of a floating average of offset values, and let
the device make it's own decitions of further actions:
videoOut->EvaluateDelay (offset, frametime(), &delay, &hurry_up);
>
> Another thing which would be good to get statistics about: the
> average number of "hurryup"s after a channel change.
>
After a channel change, I think we issue delays instead of hurryups.
--
Stefan Lucke
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
