Does anybody know of a way to find the bitrate of transport streams captured with pcHDTV during or after capture?

I could probably calculate it by capturing some data for a few seconds after tuning to a channel and then dividing the number of bytes received by number of seconds I spent recording. I am hoping that there is more elegant way to do this.

I currently use dtvstream to capture from my pCHDTV card. dtvstream BTW is a very very nice tool for those who have not yet tried it.

Collect the data

Posted: Tue Jul 27, 2004 12:58 pm

inkling

Joined: 05 Feb 2004

Posts: 342

There is no substitute for collecting real data.

A few seconds of data does not give you the statistical sample size required to determine the overall bitrate. Clock inaccuracies further skew the limited data sample.

I've been collecting real data for months now.

pchdtvr: output 16G (17400687612) 119m 38s 12894p/s

pchdtvr: output 4804M (5037861192) 34m 39s 12889p/s

pchdtvr: output 8275M (8677222344) 59m 39s 12896p/s

Notice how the shortest sample size gives the greatest 'drift'. This may be clock inaccuracy, or it might be ABC not sending enough PADs.

The average is around 12894 packets per second.
Multiply by 1504 (188 * 8) for bitrate.

There are plenty of PAD packets, stream packets with 0xFF's, that are added to the stream by the encoder to keep the overall bitrate constant.

This is because MPEGv2 video and AC3 audio streams are variable bitrate, so the PAD fills in to keep overall bitrate near constant.

This could cause some fluctuation in the bitrate as well, since some encoders may add more or less PADs than perfection. Also, PAD packets might receive/transmit slightly faster due to easier de/compression of the broadcast stream.

pchdtvr displays spot and overall variance from 12894 during capture. I see it vary from -200's to +200's. I attribute this to RTC inaccuracies and stream fluctuations. It usually follows a pattern of varying upwards, then back to 0, then downwards then back to 0, over the course of about 5 or 6 seconds. Sinusoidal, as they say.

You don't have to be exact, you only have to be close. For example, if the capture says it's only 6448p/s, there's obviously a problem.