I've been having a stuttering video problem that has been driving me crazy. I'm not sure when it started exactly because it only happens under certain scenarios, but once it starts the video is virtually unwatchable. Sound is fine but the video constantly stutters. Basically, when I first played back a video it was fine, but if I skipped forward, pressed FF or REW, or did a resume playback, the playback went all to hell. After many days and evenings of frustration, and learning quite a bit more about diagnosing playback trouble I've fixed the problem and I thought I'd share how just in case some others run into it.
When this started happening I first tried changing playback to virtually every manner of video and audio decoder I could, to no avail. Of the decoders I have that playback fine under normal circumstances, skipping forward in a video or anything else remotely would result in the same trouble.
I was not able to reproduce the behavior outside of gbpvr. If I opened a file in any of my players and then skipped, FF, REW or anything else, it worked fine. But it was consistently reproducable in gbpvr.
I searched for the forums for help and there are some that have run into the same trouble, but no great answer other than I think one guy who wiped out all the decoders on his system, save one. What I did learn from the forums was that many people use graphedit to resolve decoder issues, so I finally decided I'd download it and figure out what it was all about. I'm really quite a neophyte in this kind of thing, so I put it off until I had no other options. Here's what I found out.
First, graphedit is quite a cool tool. If you've been intimidated by the sound of it ("what's a graph got to do with playing back a video?"), just try it. It's quite cool the way it allows you to swap out and test various decoders, and just opening a video and seeing the "graph" that the system creates for playing it back can tell you a lot. Sub in one of his replies to another experiencing playback trouble had recommended using graphedit and selecting "Render media file" to see what the system defaults were for playback. While this won't necessarily show you want gbpvr is doing since you specify the decoders explicitely in the config app, I did learn something from it.
In desperation I set my decoders to System Default in config, reproduced my playback problem, and then used graphedit to show my what the system default decoders were, since according to sub this would be exactly what gbpvr was doing when it was configured to use system defaults. What it showed was what I thought... graphedit showed the Nero decoders were being used, and when I played the file, in graphedit it worked just fine. And when I played it back in gbpvr it was fine too, until I skipped forward. So now what?
Well quite by accident I asked graphedit to "Render Media File..." again, with out first getting rid of the original graph. What I saw surprised me. Instead of the second graph looking the same as the first, it was quite different. It used a different video and audio decoder and playback sucked! Same trouble I was having in gbpvr.
It turns out the audio decoder was the culprit. The second graph used the AC3Filter. Some others have posted about certain versions of this being really lousy and killing their system, and this was apparently the problem with me. However, I didn't think I cared since I wasn't configuring the system to use it as far as I knew. I disabled the decoder and did the same thing again, opening two graphs for the same file. Again, the second graph was different from the original system default, this time using ffdshow for the audio decoder. I didn't play this back (should have) but instead just went ahead and got rid of it since I know some people have mentioned it can be quite slow on slow machines (mine's only a 1.1 GHz) and I didn't have gbpvr configured to use fddshow anyway. Finally I repeated the steps again to get the second graph and it showed different decoders from the first graph's Nero decoders, but it still chose decoders that I knew played back well.
So guess what happens next? I start gbpvr again, playback a video, skip forward, and bingo!! it works fine. Just like I remember it working ever-so-long ago. Here's my theory as to why, and hopefully sub will interject where my theory doesn't quite meet reality.
First, I'm guessing graphedit shows a different graph for rendering a file a second time because the same decoders can't be used simultaneously, or at least, not all of them. Perhaps decoders aren't thread safe or at least the system knows which ones are and which ones aren't... I don't know. But for whatever reason, the second graph never matched the first and I'm thinking that gbpvr builts two graphs too.
Perhaps when you skip in a video gbpvr creates a new graph, positions the video, starts it and then destroys the old one. If so, and if it (or DirectShow, outside of gbpvr's control) does the same thing that graphedit demonstrated, this second graph won't use the same decoders as the first, and the second graph just might suck if you have some sucky decoders sitting around in your system. Whatever the case, when I got rid of my sucky decoders, which should never have been used in the first place if DirectShow was using the filters I had configured in gbpvr, the problems went away. Yea!
So, will this help you? No telling, but it sure can't hurt to try it. I know some people have complained about trouble after switching channels in live tv - I don't use live tv so I don't know if this was a problem for me or not - others about stuttering after pressing buttons on the remote - maybe this is why.
Now that I know about graphedit I wish gbpvr had a debugging option that would let graphedit inspect it's graph during runtime. Graphedit can do this, but only if the application creates its graph a certain way, and gbpvr doesn't do this apparently for stability reasons. It'd sure be nice as a debugging tool though.
Anyway, hopefully this will help someone else, and perhaps sub can shed some light on this and tell me whether my theories are crap or not. I'm just glad its working now.
Tim
When this started happening I first tried changing playback to virtually every manner of video and audio decoder I could, to no avail. Of the decoders I have that playback fine under normal circumstances, skipping forward in a video or anything else remotely would result in the same trouble.
I was not able to reproduce the behavior outside of gbpvr. If I opened a file in any of my players and then skipped, FF, REW or anything else, it worked fine. But it was consistently reproducable in gbpvr.
I searched for the forums for help and there are some that have run into the same trouble, but no great answer other than I think one guy who wiped out all the decoders on his system, save one. What I did learn from the forums was that many people use graphedit to resolve decoder issues, so I finally decided I'd download it and figure out what it was all about. I'm really quite a neophyte in this kind of thing, so I put it off until I had no other options. Here's what I found out.
First, graphedit is quite a cool tool. If you've been intimidated by the sound of it ("what's a graph got to do with playing back a video?"), just try it. It's quite cool the way it allows you to swap out and test various decoders, and just opening a video and seeing the "graph" that the system creates for playing it back can tell you a lot. Sub in one of his replies to another experiencing playback trouble had recommended using graphedit and selecting "Render media file" to see what the system defaults were for playback. While this won't necessarily show you want gbpvr is doing since you specify the decoders explicitely in the config app, I did learn something from it.
In desperation I set my decoders to System Default in config, reproduced my playback problem, and then used graphedit to show my what the system default decoders were, since according to sub this would be exactly what gbpvr was doing when it was configured to use system defaults. What it showed was what I thought... graphedit showed the Nero decoders were being used, and when I played the file, in graphedit it worked just fine. And when I played it back in gbpvr it was fine too, until I skipped forward. So now what?
Well quite by accident I asked graphedit to "Render Media File..." again, with out first getting rid of the original graph. What I saw surprised me. Instead of the second graph looking the same as the first, it was quite different. It used a different video and audio decoder and playback sucked! Same trouble I was having in gbpvr.
It turns out the audio decoder was the culprit. The second graph used the AC3Filter. Some others have posted about certain versions of this being really lousy and killing their system, and this was apparently the problem with me. However, I didn't think I cared since I wasn't configuring the system to use it as far as I knew. I disabled the decoder and did the same thing again, opening two graphs for the same file. Again, the second graph was different from the original system default, this time using ffdshow for the audio decoder. I didn't play this back (should have) but instead just went ahead and got rid of it since I know some people have mentioned it can be quite slow on slow machines (mine's only a 1.1 GHz) and I didn't have gbpvr configured to use fddshow anyway. Finally I repeated the steps again to get the second graph and it showed different decoders from the first graph's Nero decoders, but it still chose decoders that I knew played back well.
So guess what happens next? I start gbpvr again, playback a video, skip forward, and bingo!! it works fine. Just like I remember it working ever-so-long ago. Here's my theory as to why, and hopefully sub will interject where my theory doesn't quite meet reality.
First, I'm guessing graphedit shows a different graph for rendering a file a second time because the same decoders can't be used simultaneously, or at least, not all of them. Perhaps decoders aren't thread safe or at least the system knows which ones are and which ones aren't... I don't know. But for whatever reason, the second graph never matched the first and I'm thinking that gbpvr builts two graphs too.
Perhaps when you skip in a video gbpvr creates a new graph, positions the video, starts it and then destroys the old one. If so, and if it (or DirectShow, outside of gbpvr's control) does the same thing that graphedit demonstrated, this second graph won't use the same decoders as the first, and the second graph just might suck if you have some sucky decoders sitting around in your system. Whatever the case, when I got rid of my sucky decoders, which should never have been used in the first place if DirectShow was using the filters I had configured in gbpvr, the problems went away. Yea!
So, will this help you? No telling, but it sure can't hurt to try it. I know some people have complained about trouble after switching channels in live tv - I don't use live tv so I don't know if this was a problem for me or not - others about stuttering after pressing buttons on the remote - maybe this is why.
Now that I know about graphedit I wish gbpvr had a debugging option that would let graphedit inspect it's graph during runtime. Graphedit can do this, but only if the application creates its graph a certain way, and gbpvr doesn't do this apparently for stability reasons. It'd sure be nice as a debugging tool though.
Anyway, hopefully this will help someone else, and perhaps sub can shed some light on this and tell me whether my theories are crap or not. I'm just glad its working now.
Tim
