> 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. > Not taking the full offset into account is necessary, because otherwise there is a risk of getting oscilations. So one has to damp the system, and to do this the best way is to correct only small amounts of the offset. > 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. > Well, it might be bad for directfb, but what about Xv, Vidix and Framebuffer? In my opinion the a/v sync for Xv is quite good, there might be still some constant offset, but at least the syncing is very smooth and you don't get any judder. So I want to ask you not to break this for the other video out methods.. Anyway, if you want to have a smooth adjustment of the A/V sync I think clamping there is necessary.
> //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 guess that this would best if DirectFB wants to implement syncing on the graphics card. But I want to remind you that if you sync on the graphics card, you will usually not get a better average a/v sync t han +- 10ms, because the bad resolution. Maybe it is anyway better to switch to sync the audio to the video by resampling the audio. Of course that not possible for AC3 pass through, but I guess there the A/V sync is anyway worse... > I like to have a calculation of a floating average of offset values, and > let A floating average hides oscilations of the a/v sync and the result would be similar only correct a small part of the offset at a time. > the device make it's own decitions of further actions: > > videoOut->EvaluateDelay (offset, frametime(), &delay, &hurry_up); > I would suggest that cVideo gets access to cClock and does the syncing all by itself (and all the syncing code is removed from mpeg2decoder.c). It already has the pts values of the frames, so it doesn't need frametime(), and it can maintain its own delay. I'm not sure if a hurry_up is necessary, but if so the Mpeg2Decoder could poll a variable from cVideo.. Bye, Martin -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail _______________________________________________ Softdevice-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/softdevice-devel
