MP1 EVR Presenter/dshowhelper community development (7 Viewers)

[seco]

While testing the MPAudioRenderer I noticed that when using the DSShowHelper.dll from here, a lot of new issues with the videoplayback started.
Especially HD shows (*.mkv) with DTS audio had major stutter.

Sadly pretty much my entire hardware at home got toasted recently by a lightning-strike, so I can not provide any logs or info until i replaced the hardware.
But I thought I should let you guys know.

Umm, I was under impression that you should not mix these two?

Either use dshowhelper from here or if you want to use MP Audio Renderer, use dshowhelper shipped with it. I think this is mentioned in the Owlroosts 1st post too.

 

[infinite.loop]

While testing the MPAudioRenderer I noticed that when using the DSShowHelper.dll from here, a lot of new issues with the videoplayback started.
Especially HD shows (*.mkv) with DTS audio had major stutter.

Sadly pretty much my entire hardware at home got toasted recently by a lightning-strike, so I can not provide any logs or info until i replaced the hardware.
But I thought I should let you guys know.

Umm, I was under impression that you should not mix these two?

Either use dshowhelper from here or if you want to use MP Audio Renderer, use dshowhelper shipped with it. I think this is mentioned in the Owlroosts 1st post too.

I did not actually use the one from the thread, but a build from svn chemelli supplied for MpAudioRenderer testing (that version was not published).
Sorry for the confusion.

But the issue is not related to the MpAudioRenderer, because as I said, I noticed the playback issues when NOT using the MPAudioRenderer.

 

[Owlsroost]

While testing the MPAudioRenderer I noticed that when using the DSShowHelper.dll from here, a lot of new issues with the videoplayback started.
Especially HD shows (*.mkv) with DTS audio had major stutter.

Sadly pretty much my entire hardware at home got toasted recently by a lightning-strike, so I can not provide any logs or info until i replaced the hardware.
But I thought I should let you guys know.

Hi Chris,

Not seen any other reports of this, but I'll take a look at a screen cap of the render stats and logs when you're back up and running.

Tony

 

[davidf]

Hello Owlsroost,

I've been having a few issues with the MP Audio Renderer and the showhelper together. I've been playing around with the code a bit and may have fixed it - I say may as it seems to be very easy to break it. I haven't made any significant changes to the code i.e. I don't think I should have fixed it, so i wanted to know is the code as easily broken as it seems or have I just fluked a fix. I'll leave it running for the evening and see what happens. There are a few bits of code which I am curious about as well if you don't mind I'll ask some questions on it.

//De-sensitise frame dropping to avoid occasional delay glitches triggering frame drops
if ((m_frameRateRatio > 0) && !m_bDVDMenu && !m_bScrubbing)

Why >0 and not >1? surely this will always apply unless paused or the framerate is way off.

The only thing I have changed is the sleep time from 1.5ms to 1ms when it is close to scheduling time - and I doubt that has actaully fixed it as the issue seems to be due to latency and the extra execution cycles would increase the latency.

I have noticed that appears to be a bug is that if a sample from the past is scheduled it is also dropped almost every time.
Line 2526 and 2544 both should have i++ in the loop as well as the first sample is not currently checked (almost certain to make no difference).

David

 

[Owlsroost]

Hi David,

I've been having a few issues with the MP Audio Renderer and the showhelper together. I've been playing around with the code a bit and may have fixed it - I say may as it seems to be very easy to break it. I haven't made any significant changes to the code i.e. I don't think I should have fixed it, so i wanted to know is the code as easily broken as it seems or have I just fluked a fix. I'll leave it running for the evening and see what happens. There are a few bits of code which I am curious about as well if you don't mind I'll ask some questions on it.

Tell me about it...it's quite sensitive to the balance of thread priorities and which threads are under MMCSS control (and other time related things) - I've spent hours and hours playing around adjusting priorities and delay timers etc to arrive at the current setup.

//De-sensitise frame dropping to avoid occasional delay glitches triggering frame drops
if ((m_frameRateRatio > 0) && !m_bDVDMenu && !m_bScrubbing)

Why >0 and not >1? surely this will always apply unless paused or the framerate is way off.

m_frameRateRatio is the (integer) ratio of the display-to-video frame rates - see GetFrameRateRatio(). It's zero whenever there isn't a close integer relationship between the two rates (within 1.5%). When it's zero some processing is disabled because it's pointless or makes the situation worse.

I have noticed that appears to be a bug is that if a sample from the past is scheduled it is also dropped almost every time.

That's what should happen - it's not a bug.

Line 2526 and 2544 both should have i++ in the loop as well as the first sample is not currently checked (almost certain to make no difference).

It doesn't matter if you use pre- or post-increment for the loop variable (or i=i+1) - it's updated at the end of each loop iteration, not at the begining. I normally use post-increment - those lines were copied from elsewhere and I didn't notice they used pre-increment....

The only thing I have changed is the sleep time from 1.5ms to 1ms when it is close to scheduling time - and I doubt that has actaully fixed it as the issue seems to be due to latency and the extra execution cycles would increase the latency.

Do you mean:
*pTargetTime = systemTime + 15000; //delay in smaller chunks
is now:
*pTargetTime = systemTime + 10000; //delay in smaller chunks


Tony

 

[davidf]

Hi David,

I've been having a few issues with the MP Audio Renderer and the showhelper together. I've been playing around with the code a bit and may have fixed it - I say may as it seems to be very easy to break it. I haven't made any significant changes to the code i.e. I don't think I should have fixed it, so i wanted to know is the code as easily broken as it seems or have I just fluked a fix. I'll leave it running for the evening and see what happens. There are a few bits of code which I am curious about as well if you don't mind I'll ask some questions on it.

Tell me about it...it's quite sensitive to the balance of thread priorities and which threads are under MMCSS control (and other time related things) - I've spent hours and hours playing around adjusting priorities and delay timers etc to arrive at the current setup.

//De-sensitise frame dropping to avoid occasional delay glitches triggering frame drops
if ((m_frameRateRatio > 0) && !m_bDVDMenu && !m_bScrubbing)

Why >0 and not >1? surely this will always apply unless paused or the framerate is way off.

m_frameRateRatio is the (integer) ratio of the display-to-video frame rates - see GetFrameRateRatio(). It's zero whenever there isn't a close integer relationship between the two rates (within 1.5%). When it's zero some processing is disabled because it's pointless or makes the situation worse.



That's what should happen - it's not a bug.

Line 2526 and 2544 both should have i++ in the loop as well as the first sample is not currently checked (almost certain to make no difference).

It doesn't matter if you use pre- or post-increment for the loop variable (or i=i+1) - it's updated at the end of each loop iteration, not at the begining. I normally use post-increment - those lines were copied from elsewhere and I didn't notice they used pre-increment....

The only thing I have changed is the sleep time from 1.5ms to 1ms when it is close to scheduling time - and I doubt that has actaully fixed it as the issue seems to be due to latency and the extra execution cycles would increase the latency.

Do you mean:
*pTargetTime = systemTime + 15000; //delay in smaller chunks
is now:
*pTargetTime = systemTime + 10000; //delay in smaller chunks


Tony

Cheers for that.

That's what I had changed - unfortunatley it doesn't always work as I've discovered today. At least i've got my head around it now, I'll keep playing with it (although it does seem to be an awful lot of work for the want of an accurate timer).

 

[Owlsroost]

That's what I had changed - unfortunatley it doesn't always work as I've discovered today. At least i've got my head around it now, I'll keep playing with it (although it does seem to be an awful lot of work for the want of an accurate timer).

You're right - the problem with the Windows timers seems to be that they all run at a low-ish priority level, so they are fairly accurate most of the time, but it only takes a high-priority task etc to be scheduled by windows => the scheduler thread has just been asleep for 10-20ms longer than it should have been....at which point it probably has to drop a frame....

I added the 'timer' thread to try and get two delay timers using completely different mechanisms running in parallel, on the basis that if one timer got messed up the other one might still be OK - it does seem to help but it costs some CPU time of course. For info, on the render stats screen, 'Derr:' is the difference between actual time delay versus the target.

It's good to have someone running an Atom/ION system digging into the code - welcome aboard

Tony

 

[tourettes]

You're right - the problem with the Windows timers seems to be that they all run at a low-ish priority level, so they are fairly accurate most of the time, but it only takes a high-priority task etc to be scheduled by windows => the scheduler thread has just been asleep for 10-20ms longer than it should have been....at which point it probably has to drop a frame....

The problem is not the inaccurate timers itself, those could be firing of on good accuracy - but the issue comes from the thread scheduling. It wont help if the timer fires when OS kernel doesn't allow the thread to be working. This is why MMCSS was added in Vista. It will allow thread priority to be boosted when there is timing critical work to be done - Multimedia Class Scheduler Service (Windows)

At least on the audio renderer side there was / is huge difference how accurate the thread wakeup times are when MMCSS was enabled.

I added the 'timer' thread to try and get two delay timers using completely different mechanisms running in parallel, on the basis that if one timer got messed up the other one might still be OK - it does seem to help but it costs some CPU time of course. For info, on the render stats screen, 'Derr:' is the difference between actual time delay versus the target.

Probably that same (or much better) accuracy would be gained if MMCSS would be used for the scheduling thread (and maybe for other threads as well). I would say that adding the 2nd timer is not going to help that much since all is just being limited by the OS thread scheduling - as written earlier the timers itself aren't inaccurate.

I'll do some small experimenting with the MMCSS off/on with the audio renderer and post the timer / thread wakeup accuracy data.

It's good to have someone running an Atom/ION system digging into the code - welcome aboard

Indeed

 

[tourettes]

I added the 'timer' thread to try and get two delay timers using completely different mechanisms running in parallel, on the basis that if one timer got messed up the other one might still be OK - it does seem to help but it costs some CPU time of course. For info, on the render stats screen, 'Derr:' is the difference between actual time delay versus the target.

Probably that same (or much better) accuracy would be gained if MMCSS would be used for the scheduling thread (and maybe for other threads as well). I would say that adding the 2nd timer is not going to help that much since all is just being limited by the OS thread scheduling - as written earlier the timers itself aren't inaccurate.

I'll do some small experimenting with the MMCSS off/on with the audio renderer and post the timer / thread wakeup accuracy data.

Here's a result form really quick testing. Following way of accuracy measurement was used:

timer is scheduled:

SetWaitableTimer(m_hDataEvent, &liDueTime, 0, NULL, NULL, 0);
timeOnSchedule = GetCurrentTimestamp();

Timer fires and audio renderer receives an event:

LONGLONG sleepDuration = GetCurrentTimestamp() - timeOnSchedule;
LONGLONG dev = sleepDuration + liDueTime.QuadPart;
Log("dur: %I64d delay: %I64d - dev %I64d == %.5f ms", sleepDuration, liDueTime.QuadPart, dev, (double)dev/10000.0);

On a quick look into the results it seems that MMCSS is able to provide much more strict scheduling and no late events are happening.

 

[Owlsroost]

I have tried using MMCSS for the 'scheduler' thread in the past - the code is still there, commented out (and the other two threads do use MMCSS).

I stopped using MMCSS for the 'scheduler' thread because it seemed to have side effects which made the overall performance worse. MMCSS seems to be a very 'aggressive' scheduler, so it's all too easy to degrade the performance of other threads if you're not careful e.g creating high latencies in the worker thread which results in the sample queue running low on data. Running at 'THREAD_PRIORITY_TIME_CRITICAL' under the normal scheduler just seems to work better for that thread - and the timers are normally pretty good ('Derr:' is usually much less than 1ms on my system).

I don't want to put anyone off trying things, but don't expect miracles by using MMCSS

Tony