NVidia Decoder performance issue in GB-PVR

[wtg]

I've been having issues with using the NVidia Pure Video decoders - sometimes the playback or sound stutters, and CPU percentage seems too high. CPU usage is noticably lower with Nero's decoder, even though DxHA is disabled with it.

I finally decided to do a bit more digging, and I've found that if I open an MPG with GraphEdit and play it, CPU usage is much lower than if I open the last_graph.grf file that GB-PVR creates and play it. The graphs are decidedly different, and I'm wondering if there's anything that can be done about it. Is it an issue with my config or is this just how it has to be?

Here's the GB-PVR graph and perfmon results, along with the default graph and perfmon results. In both instances I was watching the movie Bewitched, starting it at the beginning:

[wtg]

Notice the difference when I choose the Nero decoders and use GB-PVR's last_graph.grf file.

The one thing that is different with the GB-PVR graphs using NVidia Decoders is the use of the GB-PVR parser instead of the MPEG-2 Demultiplexer filter. Is this the problem? And if so, how do I fix it?

[sub]

The GB-PVR Parser is only used when watching timeshift mode in GB-PVR, or playback of an in-progress recording. Is this the only time you're having the problem? During playback of an existing recording, or watching live preview mode TV, it uses the Microsoft MPEG2 demultiplexer filter.

You can check what is being used by looking in gbpvr.exe-native.log for the following section:

16:10:03.250 VERBOSE Graph contains the following filters:
16:10:03.250 VERBOSE - Default DirectSound Device
16:10:03.250 VERBOSE - Video Renderer
16:10:03.250 VERBOSE - MPV Decoder Filter
16:10:03.250 VERBOSE - ffdshow Audio Decoder
16:10:03.250 VERBOSE - GB-PVR Flow Status
16:10:03.250 VERBOSE - MPEG-2 Demultiplexer
16:10:03.250 VERBOSE - C:\MyVideos\large\SwissToni_20040808_03301900.mpg

[wtg]

That's interesting... I wasn't watching an in-progress recording, but I did have one that was in-progress. This Bewitched video was recorded a long time ago. It seems that perhaps GB-PVR got confused, but only in the first graph... the other one was also with the same in-progress recording but it didn't do it.

In any event I tried it again with nothing in-progress and it is better, but still it gets nowhere near the performance of the default graph performance. You can tell where I started playback easy enough, at the beginning.

Ideas?

[sub]

I wasn't watching an in-progress recording, but I did have one that was in-progress.

No, that wont effect it. It'll only use the GB-PVR Parser when that specific recording is in progress. If you think its using it for any other playback, zip and attach the gbpvr.exe-native.log and I'll take a look.

Ideas?

No, but I dont personally use the nvidia decoder, so I'm not really that familiar with it.

[wtg]

No, that wont effect it. It'll only use the GB-PVR Parser when that specific recording is in progress. If you think its using it for any other playback, zip and attach the gbpvr.exe-native.log and I'll take a look.

Ok, tomorrow I'll try and reproduce it again for you - I've got to get some sleep now. But that particular Bewitched recording was recorded back on June 10th, and you can see the name in the graph so it was definitely replaying an existing recording... not an in-progress one. In fact, I was running it out of Video Library. I'd post the log from tonight, but of course I restarted.

[Braklet]

The GB-PVR Parser is only used when watching timeshift mode in GB-PVR, or playback of an in-progress recording.

I've run into problems similar to the original poster. As a matter of fact I can't open any .grf file generated by GB-PVR (lastgraph, lastdvdgraph) since graphedit complains that it can't handle an unregistered filter. (!) I've no problem playing video from within GB-PVR, however.

Are the different GB-PVR graph rules documented anywhere, or deductible from an .ini file? The reason I ask is because I've struggled with tuning and would like to understand more about how the filters and graphs work.

I've gone about as far as I can setting different merit values to get what I want.

I'll also add that I've found nVidia PureVideo decoder provides the best video quality of all I've tried, but it is extremely quirky and tough to tune.

[sub]

I've run into problems similar to the original poster. As a matter of fact I can't open any .grf file generated by GB-PVR (lastgraph, lastdvdgraph) since graphedit complains that it can't handle an unregistered filter. (!) I've no problem playing video from within GB-PVR, however.

This is fairly normal. There are a few reason it can happen.

You can still see which filters are being used by looking the gbpvr.exe-native.log, or in a couple of posts I've commented on registry settings that can be added to allow you to remotely connect to a graph in graphedit to view its connection.

Are the different GB-PVR graph rules documented anywhere, or deductible from an .ini file?

No, they're not. There is a fairly straight foward set of connections though, so you have any specific questions about how its connected, then feel free to ask.

[sub]

I decided to spend some time this morning looking into why you'd be getting these significantly large regular peaks shown in your graphs using the GB-PVR parser, but not using the MPEG-2 Demultiplexer.

Unfortunately I'm not see the same behaviour here. Here is my graph and perfmon output:

[wtg]

I sure appreciate your time looking into it sub.

As far as the peaks go, you can see I got them with the Nero decoder and with the MPEG-2 Demultiplexer - they were just much more extreme when using the NVidia Decoder and the GB-PVR Parser. Together they make a very bad combination.

Notice too that I get no sizable peak at all in the graph graphedit comes up with on it's own with the NVidia decoder, and the difference there is the GB-PVR Flow Status filter. In all tests I was using the exact same file and the graphs come from the exact same segment - the very beginning of movie. My working theory is that it's the GB-PVR Flow Status filter that is causing the peaks since you don't see them at all in the filter GraphEdit comes up with, and that perhaps something about it's output throws the NVidia decoder out of hardware-acceleration mode - hence the two combined makes for the worse case. Very little evidense of course , but it gives me something to focus testing on.

I'm at work right now so haven't done anymore testing yet, but I'll certainly do a bit more this evening. If you have any specific suggestions about what you'd like me to try, let me know. I'm thinking there must be something about myself and some others having issues with this particular decoder. Maybe it's a problem in the decoder itself, but as you can see in the graph, it uses so little CPU when it's working well and it produces such a nice picture, it's one many of us would like to use.

Thanks again for your time,
Tim