Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> HDTV programming and listings -> STT variations
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
STT variations
PostPosted: Fri Feb 18, 2005 5:24 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




I'm seeing pretty large variations on System Time Table packets from station to station.

Variations can be from 2 to 16 to 54 seconds, so far.

Has anyone else seen this or bothered to look yet?

Have the television stations ever heard of ntpd?

I have STT integrated into pchdtvr now. It's optional because of the above variations.

-ink
View user's profile Send private message
PostPosted: Sat Feb 19, 2005 1:35 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Interesting question. My machines at work and at home and even my Palm Pilot all use ntpd and they all always have the exact same time. Lemme check:

My PBS station is 13 seconds ahead.

My CBS station is 24 seconds behind.

My NBC station is 70 seconds ahead.

My ABC, WB, FOX, and UPN stations are all correct within a second. They also were the last to go HD in town and have the newest equipment.
View user's profile Send private message
old equipment
PostPosted: Sat Feb 19, 2005 7:47 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Scott Larson wrote:
Interesting question. My machines at work and at home and even my Palm Pilot all use ntpd and they all always have the exact same time. Lemme check:

My PBS station is 13 seconds ahead.

My CBS station is 24 seconds behind.

My NBC station is 70 seconds ahead.

My ABC, WB, FOX, and UPN stations are all correct within a second. They also were the last to go HD in town and have the newest equipment.


Cool, thanks for the comparitive reference Scott. So, for once, it's not bad programming on my part then.

ntpd does a fine job of timekeeping here, too. It baffles me as to why ntp hasn't been an industry standard for broadcast time synchronization for at least the past 10 years.

I'm reading ATSC spec A/65b. It mentions how the repeaters have to adjust for time delay due to transmission and buffering.

70 seconds is long enough for a photon to go to the moon and back two dozen times, so that mostly rules out transmission delays.

I suspect it may be the buffering delays that aren't being compensated for by the older hardware. 70 seconds would be about 170M of total buffer delay, assuming it's not someone forgetting to set the time.

I thought it might be a nice feature to have in pchdtvr, but I can see now the TV industry is behind the curve when it comes to accurate timekeeping. It makes a nice -A option to play around with, though.

One newly broadcasting station is 54 seconds out. I'm wondering if that's a sign of hand-me-down equipment for the local independents?

Does your set-top box set the time from the stream? I would probably have thought it was broken, had I had seen all those time variations without reading A/65b.

-ink
View user's profile Send private message
PostPosted: Sat Feb 19, 2005 10:40 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Well, some stations care a lot more about PSIP than others. For example my WB and NBC stations usually only have the next eight hours of programming (what's on tonight) yet my FOX and UPN stations (which have the same owner in my town) always have at least two weeks of programming!

I was going to grab PSIP data from my local stations every night to run a little TiVO-like script that looks for stuff to record. It proved to be a waste of time since stations can't even get a day's worth of programming into their PSIP. I've switched to using XMLTV which usually has a couple of days of info for all my local stations.
View user's profile Send private message
PSIP for the future?
PostPosted: Sun Feb 20, 2005 3:09 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Scott Larson wrote:
Well, some stations care a lot more about PSIP than others. For example my WB and NBC stations usually only have the next eight hours of programming (what's on tonight) yet my FOX and UPN stations (which have the same owner in my town) always have at least two weeks of programming!

I was going to grab PSIP data from my local stations every night to run a little TiVO-like script that looks for stuff to record. It proved to be a waste of time since stations can't even get a day's worth of programming into their PSIP. I've switched to using XMLTV which usually has a couple of days of info for all my local stations.


FOX and UPN same owner here too. Had to call FOX news desk to notify about UPN missing audio because no number for UPN anymore.

I bet they liked that. They sure did get it fixed in a hurry, though.

I'm looking at putting PSIP into pchdtvr, but as you know it probably won't be useful until 2007. Nice to get a jump on things instead of playing catch-up.

Maybe it won't take me a whole year to figure out.

The implementation is the tricky part. To make it act like a set-top box, have to start reading stream as soon as switch to channel, instead of doing signal scan like pchdtvr does.

That's all well and good for cable when you know there's a good signal, but for small single antenna, really need some way to know if the signal is good enough before reading stream.

One way it could be done is to only fall back to signal check if stream read gives garbage. Or some variation of that theme. Switch to channel, if signal is good, start reading and loading arrays with PSIP data. Then if get garbage, fall back to signal check.

HD2000 signal check causes dropouts (buffer overruns) if used during stream read. The transfer engine on HD3000 is a lot nicer, but I haven't tested it yet to see if signal strength glitches stream read.

I would have to assume it would because new HD2000 and HD3000 drivers take longer than old HD2000 driver to get signal strength because it samples 3 times instead of once.

Reverting HD2000 driver to non-averaging method showed best case of about 1/38th second for signal strength. That's 340 packets or 63k of stream. Stock 1.6 driver is about 1/9th second, 1430 packets, 270k of stream. I haven't tried changing HD3000 driver yet, but could do something similar. Make it so V4L2 access gives newer slower averaging and V4L1 access gives older faster less accurate method.

If PSIP parse code has CRC32 check, it could handle the signal check dropouts. Could check signal strength once a minute or so and get PSIP the rest of the time, unless garbage forces fall back to signal check.

Not sure if DVB API does PSIP, but it might. Still reading docs on it. Could save me a whole lot of work!

-ink
View user's profile Send private message
PSIP for the NOW
PostPosted: Sat Mar 05, 2005 12:17 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




pchdtvr-1.0-rc5 now has PSIP support.

That's STT, TVCT, MGT, EIT and ETT tables.

How well it works remains to be seen.

-ink
View user's profile Send private message
STT variations
  pcHDTV Forum Index -> HDTV programming and listings
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 1 of 1  

  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin