[fixed] Video and sound syncronisation (2 Viewers)

[morpheus_xx]

AW: Video and sound syncronisation

I already did, but unfortunately he couldn't find time for MP2 yet

In fact no one of the MP1 dshow developers (I know we don't have many ) could help until now...

 

[Owlsroost]

Yes, and at the moment the time problem is getting worse, not better - I seem to be getting more involved in MP1 TsReader C++ code as well as dshowhelper.....

There are a lot of calculations for render stats etc in MP1 presenter, but I strongly suspect they are not essential i.e. windows doesn't make use of the information itself. Also there is quite a bit of code related to the vsync correction logic, but that is 'icing on the cake' rather than real core functionality.

Basically in the MP1 presenter there are two main threads:

The 'Worker' thread which pulls video samples from the EVR mixer and puts them in a 4-5 deep sample queue,

The 'Scheduler' thread which compares the timestamp of the sample at the head of the queue against the presentation clock time, and either discards it (if late), 'presents' it (if on time) or puts the thread to sleep for a short time (if early).

The critical things for good performance seem to be getting the correct thread priorities (very high for Scheduler, high or normal for Worker seem to work best), and minimising interaction between the two threads i.e. only absolutely essential thread locking, otherwise latency problems from the Worker thread will impact the Scheduler thread.

Hope that helps a little

Tony

 

[Owlsroost]

If you are having A/V sync problems, I'd take a hard look at the sample timestamp <-> presentation clock comparison code - maybe it's not sleeping if samples are early ? (which would make the video lead the audio).

Tony

 

[morpheus_xx]

AW: Video and sound syncronisation

Can you please try this evr presenter?

I mainly did 3 changes:

• raise the schedulers thread priority
• drop samples that are too late by 1/4 of the frame time (they were force to present)
• adding 2 statistic counters to scheduler (drawn/dropped frames) so that in graphedit these numbers are available in prop page of evr

edit:
I also derived from CBaseVideoRenderer Class http://msdn.microsoft.com/en-us/library/dd368854(v=VS.85).aspx , but this seems to have absolutely no influence, so I will remove this change later.


For me the video is quite well now. Tell me your results

 

[Owlsroost]

If I understand you correctly, in this case video is displayed before the audio is played.

Here, I have the audio first... Any idea 'bout that ?

Cheers.

I think Morpeus has probably just fixed that problem i.e. dropping late samples correctly

Tony

 

[Smeulf]

Re: AW: Video and sound syncronisation

For me the video is quite well now. Tell me your results

Test result :

@60Hz, still ok for flickering, no problem
@75Hz, there is still some flickering, but not as many as before (maybe 1 or 2 in 3 minutes against 1 every 20 seconds maybe...). You improved it great

For the sound sync, the problem remains the same : video leads the sound.

Cheers.

 

[Smeulf]

If I understand you correctly, in this case video is displayed before the audio is played.

Here, I have the audio first... Any idea 'bout that ?

Cheers.

I think Morpeus has probably just fixed that problem i.e. dropping late samples correctly

Tony

Just to make it clear for all :

Video leads the sound. I've been confused, and i'm sorry about it

Anyway, I now better understand how it works... Thanks.

Cheers.

Smeulf.

 

[Owlsroost]

Smeulf - what does the flickering/flashing look like ?

Tony

 

[tourettes]

Just to make it clear for all :

Video leads the sound. I've been confused, and i'm sorry about it

Is it constant difference in the A/V sync or is there some drifting happening? Also how much the video is ahead if the diff is constant.

 

[tourettes]

Re: AW: Video and sound syncronisation

Can you please try this evr presenter?

I mainly did 3 changes:

• drop samples that are too late by 1/4 of the frame time (they were force to present)

Tony, shouldn't all samples that are late (even if 1 ns) be dropped to make sure there wont be drifting happening. A late frame will be scheduled always on the next v-sync on DirectX / GPU side so it will effectively move the A/V sync apart for one frame duration (20ms / 40ms on PAL material).