Frame dropping in live tv

[nmilne]

Hi - I've just started having a bit of a play with btv for analog capture from my cable box. So far it seems quite good, however I am having trouble with occasional dropped frames and some stuttering, but only about 20-30% of the time.

I've found the best replay is using either the Snapstream SP decoder or Cyberlink SP decoders in overlay mode. They give very fluid and smooth playback (unlike the jerky nvidia, intervideo and other decoders which seem to have much lower framerates) however about 20-30% of the time they start to drop a few frames and the video becomes temporarily choppy, then goes back to being fine, but this process continues on ad nausium. It doesn't make the video unwatchable but does make it rather annoying

I'm running an ath64-3200 and during playback CPU sits around 12-15% utilisation, and memory is way under the 1g in this box. I'm capturing the video using a Leadtek PVR2000 capture card through s-video input. I'm in Australia so of course I'm capturing & playing PAL video.

Has anyone else come across similar sort of behaviour?


Neil.

[iamfried]

Yes, I have the same problem. I had a friend over the other day and he noticed it in a matter of minutes that it was dropping frames.
Depending on what you are watching the more frames it drops - or atleast the more you can notice.
I haven't determined what the problem is yet, but I am doing quite a bit of trouble shooting and investigating. If I find something I have to change to get this better, I will post.

[yuppicide]

I hardly ever get dropped frames. I think a lot depends on your hard drive.. you should defrag it regularly. If you have under 10% space free on your operating system drive it could be slowing down things a lot. Also, recording on a drive seperate from your operating system is reccommended for best performance. This way that drive is only doing one thing recording.

RAM also plays a performance.

[nmilne]

Thanks for the replies guys ... hdd should hopefully be good, as I've got two 300gb Segate 7200rpm/8mb SATA drives, recording on a separate physical drive from the o/s. RAM wise I have reasonably unspectacular corsair pc3200 RAM in the box, but 1Gb worth, and certainly it shouldn't be a bottleneck if the hard disk comes into play.

I've been having a play with some different decoders, and I can make the problem worse but not better I get the same effect using either the cyberlink or the snapstream SP decoders, and noticably lower framerate using the standard, intervideo, nvidia or other decoders. I don't get the same stuttering problem viewing live or recorded digital TV.

I can also confirm that I get the same problem with recorded TV when not being viewed live, so I think I can rule decoders out of it, unless its some sort of format/logic type of error....

[nanook105]

What recording settings are you using ?

[bits]

What is your cpu% during capture, you mentioned that it was 12-15% during playback but what is important is what it is during capture. I am not familiar with your video card, does it have on board hardware encoding? or does it use your cpu and software to encode?

Other random thoughts:

- Make sure your HDD is set to Ultra DMA
- Is there any chance the stuff your recording is encrypted
- Try different cap settings, like reducing the bitrate
- Try turning off video preview during capture
- Take a look at what is running in the background, Norton for example.
- Make sure your video connection is good

If your capture card does have hardware encoding and you are getting dropped frames then I would highly suspect the capture card. If it does not have hardware encoding and you are using software encode then something is sucking cpu and your system is not keeping up. Reducing bitrate will help this.

BTW DRAM does not play that much of a role in video capture, the cpu is the main thing.....

[nmilne]

Thanks guys - I'm recording with max settings (dvd quality). CPU use is low, around 12-25% when capturing (capturing/timeshifting and playing live tv at the same time has it sit about 20%). I'll double check my udma settings too. Nothing being recorded should be encrpyed, its just boring old analog s-video capture out of my cable box

Either previewing / viewing live tv and timeshifting, or recording without the viewscape running nets the same result. I'll play around with lowering the capture rate and see whether that makes any diff. Nothing much running in the background, and cpu isn't spiking at all.

The video cap card has a hardware mpeg2 encoder on board, and the relatively low cpu numbers seem to indicate that it's being used. The cpu itself is an athlon64 3200. I'm thinking now that hard disk may be the bottleneck but need to work out some numbers to calculate average bitrate throughput to disk and compare that with what I can benchmark out of it...

[bits]

Is your HD a slave or master? Is it on the primary IDE? Is it USB? or Firewire?

Also for clarity, does the video look ok when you view live TV but are not recording? Way back when I was capturing using AIW7500 the live video looked great but the recorded video was jerky, clearly dropping frames, is this exactly what you see?

I use a PVR250 to do my mpeg2 caps and I have recorded, without dropped frames, to a USB drive BUT I much prefer cap'ing to a dedicated internal HD.

A slave HD on the secondary IDE will run at about the same speed as a USB2 and a slave HD on a primary IDE will about 2x the speed of a USB2 HD.

Is there any other way to get the video into your capture card? Just for test purposes, maybe your 'S' video cable is defective?

Can you cap to another drive?

[nmilne]

Both HD's are SATA drives and are on separate SATA channels. The o/s is on one device and i'm cap'ing to the second (physical) device. The second device just does capturing, anything I want to store and play later gets plonked on to a second partition on the first device.

I tried the speed test under the SATA device controller properties in device manager, and it gave me a throughput of around 65mb/sec, and even on its highest quality setting I should only need around 1mb/sec throughput to the actual disk itself. I'll try and find a decent hdd benchmarking tool and get some real world data transfer numbers out though just to make sure that the drive can sustain this past its 8mb buffer.

When either recording without the viewscape or viewing live tv through the viewscape I get the same result, in terms of dropped frames. However when viewing it is still recording because of its automagic timeshifting. If I turn the timeshift buffer to 0 in the web admin will this stop it trying to record during live tv? Or is the setting burried somewhere else? I'll have a look when I get home tonight anyway

I can give composite a shot and see what that does, instead of s-video. Actually, that's quite a good idea, as I can take the foxtel digital box out of the picture alltogether and just try capturing some old VHS tapes instead...

[nmilne]

Ok, I'm pretty sure its the mpeg decoders now. I tried setting up zoomplayer to use the same cyberlink sp decoder and replayed a timeshift .dat file numerous times and found that it would introduce the light stuttering at different times. Sometimes the whole clip would play ok, other times it would stutter at different times in the clip. I tried the Nero video codec in BTV and that seems to be a lot less prone to it, although I haven't used it enough yet to know whether it has got rid of it or not.

Both the cyberlink and snapstream sp codecs seem to suffer from occasional almost random choppyness. I have a different cyberlink DTV decoder that seems pretty good, and as I said the Nero ones seems fairly good too. I'll have a bit more of a play around and see how I go, at the moment it seems like using zoomplayer with different codecs and replaying the same clip over and over is the best way of easily determining whether the codec itself is introducing problems.

The strange thing is that even the problematic decoders don't appear to be nasty from a system perspective, such as needing too many cpu or disk resources...

[bits]

Originally Posted by nmilne

Ok, I'm pretty sure its the mpeg decoders now. I tried setting up zoomplayer to use the same cyberlink sp decoder and replayed a timeshift .dat file numerous times and found that it would introduce the light stuttering at different times. Sometimes the whole clip would play ok, other times it would stutter at different times in the clip. I tried the Nero video codec in BTV and that seems to be a lot less prone to it, although I haven't used it enough yet to know whether it has got rid of it or not.

Both the cyberlink and snapstream sp codecs seem to suffer from occasional almost random choppyness. I have a different cyberlink DTV decoder that seems pretty good, and as I said the Nero ones seems fairly good too. I'll have a bit more of a play around and see how I go, at the moment it seems like using zoomplayer with different codecs and replaying the same clip over and over is the best way of easily determining whether the codec itself is introducing problems.

The strange thing is that even the problematic decoders don't appear to be nasty from a system perspective, such as needing too many cpu or disk resources...

Have you tried burning one of the cap'd files to DVD and viewing on a standalone DVD player?

[nmilne]

I haven't done the viewing yet, but I do have a 3 hour cap on dvd, so i'll plug the dvd player into another telly and see whether it has the same frame dropping problem...