Disappointing MPEG2 decoding

[guppyman]

There's a switch in the config file to automatically launch gbpvr in "above normal" priority. (search around, i can't remember) That's probably better than the app you're using to monitor it if you want to give it a shot. Above normal should have the equivalent effect unless you're running OTHER above normal processes.

Can't find this setting in config - or in the config.xml file

[j3flight]

Can't find this setting in config - or in the config.xml file

Look for:
<ForceHighPriorityRecordingService>

[elricfate]

So then we're still working on this problem.

I had it too. Still do on a very rare occasion (my uncle has it, but he's using wintv2k) ...

We thought it may be something in the drivers for the PVR 150s we're using.

But I switched to VMR7, took less of a hit in CPU usage, and noticed the skip/hiccup was gone ... for the moment. I'll keep my eyes peeled to see if it happens again, and let you guys know the outcome.

Another thing I did was set all of the different codecs to system default, rather than optional settings. The picture quality even improved.

[sgilani]

I have another thread running about channel changing in timeshift mode taking a looong time; I'm posting here because it's related to quartz.dll.

Turns out, at least in my situation, that rolling back to the 9.0b quartz.dll causes channel changing to take forever, it must be a problem with DirectShow.

Anyway, the "fix" for me was to apply the Microsoft hotfix about quartz.dll that's listed in this thread, and then using VMR7.. I'll keep looking for a more "flexible" solution, since VMR9 looks better for me and probably others.

[kathakur]

In case you have not tried it, I have found Nero Video decoder and Nero Digitial Audio decoder with Overlay Manager to provide excellent software MPEG-2 playback performance even on the lower speed CPUs. The one I have is part of Nero suite version 6.6.

[Troy]

Hi everyone,

I just wanted to add a reminder to people when they do Windows updates to recheck the Quartz.dll file if their stuttering problem returns. I was racking my brain as to why the quartz.dll fix only worked for a few days and then went and checked what version I had and it had gone back to the 9.0c one! :eek: It is ridiculous that Microsoft hasn't put out a real patch for this! :mad:

[wtg]

Troy,

It's true however that for at least some people the 9.0c quartz.dll released in Dec, 2005 fixed the stuttering problem. I installed the Dec patch accidently and have had no trouble.

[iluvatar]

I actually had some reasonably serious stuttering going on my new machine, and changing quartz.dll or video decoders didnt help at all.

My new CPU is an AMD X2 4400+ with dual cores. It turns out many of the directshow components dont behave well will multiple CPUs or cores. I had to add an option in config.xml to force the processor affinity to one CPU. This fixed it, and things are running very smoothly now. This setting will be included in the next release for others that may need it.

The quartz solution did not work for me. Alse, the key you introduced in the config.xml does not do the trick for me (ForceSingleProcessorAffinity). My configured settings (video codec etc) in GBPVR config are identical as the ones WMP uses for playback. Even so, WMP plays a perfect MP2, and GBPVR does not.

[mobiusnz]

Well - I've previously stated in this forum that changing the quartz.dll fixed all my problems, but interestingly enough I decided to try the Nvidia decoders - I downloaded the latest version and switched to it from the Intervideo ones I've been using till now (WinDVD 5) and the problem came back. Exactly as before - often after skipping it goes jerky - like the overall speed is right but its skipping every 2nd frame or something. Switching back to Intervideo and its fine - perhaps when I previously changed my quartz.dll I broke the golden rule of problem solving and changed something else - perhaps I was using the Nvidia codec then. Or perhaps the quartz.dll solves it for Intervideo but Nvidia have something built in to resolve the issue that is broken but manually replacing the quartz.dll with the incorrect version. I don't know but I just thought I'd throw in my discovery to the mix.

[mobiusnz]

Ok - furthur to my previous post I finally got round to looking at the issue of jerkiness after installing Nvidia pureview and found that something (windows update? or Nvidia pureview install) had replaced quartz.dll with a version newer than the DX9c version I'd previously had problems with. So I put it back to the 9b version and again its perfect. So to recap the versions I've experienced.

The one that works flawlessly -
Version: 6.05.01.0902 - (1,962,496 bytes)

The 9c installed version I used to have that caused the jerky playback
Version: 6.5.2600.2180 - (1,287,680 bytes)

The new one that had been installed more recently
Version: 6.5.2600.2749 - (1,287,680 bytes)

As you can see its exactly the same size but definately different. The version reports different and a binary compare gets a lot of difference. I have no idea what installed it - I first noticed the problem after installing the Nvidia codec but theres been quite a few windows updates lately - don't know if any of them are DirectX related but I suspect not so I'm guessing the Nvidia codec did it.

So to recap - I'm 100% certain that the 6.05.01.0902 quartz.dll placed manually back in safe mode fixed my issues of jerky playback twice now. I don't play many games on the lounge pc (occasionally I play Mame32 and thats about it) so I don't know if there are other issues installing this old version but it fixes the jerky playback issue. Those who have tried and it didn't work need to make certain the version stuck as by default windows will auto repair and put the newer version back so double check what version is present after a reboot.