Dropped Frames in LiveTV

[marcdbl]

Ok, it's my first post, be nice please!

Here is the problem I am seeing:

1. I select a channel and start watching. Everthing looks OK.
2. I pause the channel, and then play again. Everything OK still.
3. I decide I want to go skip ahead to what is currently 'live', so I skip to the end of the timeshift buffer. At this point video frames start getting dropped, so the playback gets very stuttery, audio remains OK.
4. {I can workaround the problem by skipping back any amount (just one second is enough)}.

Notably this only really happens when I'm watching an HD channel (I'm in the UK, so HDTV is h264 encoded). It doesn't seem to happen with SDTV (mpeg2).
Has anyone else seen this?

I've tried several settings with no improvement:

• CoreAVC filter/PowerDVD/SageTV filter.
• DXVA on/off.
• Overlay/VMR9.
• 3D Acceleration on/off.
• MPEG4 timeshifting on/off.
• DScaler on/off.
• Full Screen on/off.

My setup:

• Windows Vista x86
• ATI HD3400 (Catalyst 8.8).
• Hauppage Nova-HD-S2.

[ryanagler]

UNLESS YOU HAVE A QUAD-CORE CPU, SAGE WILL ALWAYS GIVE YOU CHOPPY h264 HD PLAYBACK IN VISTA.

Plain and simply, Sage will not use hardware acceleration for h264 under Vista, because Sage doesn't support something called EVR.

I had the exact same problem. I had a Core 2 Duo 2.4GHz with an ATI HD 2600XP and cpu would spike to 100% in Sage playing h264, with 0% GPU usage. But in other players like Arcsoft Theater it would be smooth and at 5% CPU and 30% GPU because Arcsoft Theater supports EVR.

You basically have two options: wipe Vista off the machine and replace it with XP (worked for me). Or, throw massive hardware at it for Vista (Q6600, worked for me)

Don't waste your time toiling with settings -- i tried seemingly everything and never was able to get smooth Vista h264 playback without a quad-core.

[marcdbl]

I appreciate what you mean, and I'm aware that DXVA is not going to work in SageTV, however, like I said, h264 plays fine most of the time as long as I don't jump to the end of the timeshift-buffer. So I don't think what I'm seeing here is anything to do with processing power.

However, it has prompted me to watch CPU usage whilst I tried it again, and I saw the following.

1. I select a channel and start watching. Everthing looks OK. [CPU=~60%]
2. I pause the channel, and then play again. Everything OK still. [CPU=~60%]
3. I decide I want to go skip ahead to what is currently 'live', so I skip to the end of the timeshift buffer. At this point video frames start getting dropped, so the playback gets very stuttery, audio remains OK. [CPU=~25%]
4. {I can workaround the problem by skipping back any amount (just one second is enough)}.[CPU=~60%]

This gives me the impression that perhaps the Directshow filter simply isn't receiving enough frames, and the drop in CPU accounts for the fact that the filter isn't working as hard as a result.

[elaw]

Here's one thing you could try, it's from another thread here that I can never find...

Go into registry editor, and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Frey Technologies\Common\DSFilters\MpegDeMux.

Reset the values for the following two entries:
"NumBuffers" set to hex 00000200
"BufferSize" set to hex 00020000

This increases the memory used for buffering video, it did wonders for HD stuttering problems that I had.

[Opus4]

Try increasing these properties for the UI used for playback:

videoframe/local_encoding_to_playback_delay=2000
videoframe/time_behind_live_to_disable_fast_forward=6000
videoframe/time_behind_live_to_disable_skip_forward=4000

- Andy

[marcdbl]

Originally Posted by Opus4

Try increasing these properties for the UI used for playback:

videoframe/local_encoding_to_playback_delay=2000
videoframe/time_behind_live_to_disable_fast_forward=6000
videoframe/time_behind_live_to_disable_skip_forward=4000

Ah, you beat me to it! I did this over the weekend and it worked, but I now have slow channel-changes.

Could you describe what exactly those three settings mean. I think it's the following:

videoframe/local_encoding_to_playback_delay
- this is the lag (in milliseconds) between a channel-change completing, and video actually appearing on screen
videoframe/time_behind_live_to_disable_fast_forward
- this is as close to real 'live TV' as it is possible to get with fast forward
videoframe/time_behind_live_to_disable_skip_forward
- this is as close to real 'live TV' as it is possible to get with skip forward

I think the best thing to do to stop frame-drops is probably to make these all pretty much the same value (especially the last two), and to make that value as small as possible until frame-drops start. Does this sound right?

[paulbeers]

Originally Posted by marcdbl

I think the best thing to do to stop frame-drops is probably to make these all pretty much the same value (especially the last two), and to make that value as small as possible until frame-drops start. Does this sound right?

That would be correct. Just keep playing with the figures until the buffer is big enough to not cause problems. I have actually seen this behavior in HD MPEG2 streams in the past so while annoying, it isn't unheard of.