Slashdot Mirror
Did a Timer Error Change the Outcome of a Division I College Basketball Game?
New submitter javakah writes: Controversy has erupted from the February 10th basketball game between Boise State and Colorado State, and speculation is that a timer may have made an incorrect assumption about the number of frames per second the game was recorded in, and ultimately lead to an erroneous result. With the game tied in overtime, Boise State had the ball out-of-bounds with 0.8 seconds left on the game clock. The ball was thrown in-bounds, the shot went in, and the game clock showed that the Boise State player got the shot off with 0.4 seconds left. However there was a problem: the game clock did not start until a fraction of a second after the in-bounds player touched the ball. Referees decided to use video replay to examine whether the player had gotten the shot off within 0.8 seconds or not. To do this, they used a timer embedded in the video replay system. This embedded timer indicated that 1.3 seconds had passed between the time that the in-bounds player touched the ball and when he got the shot off. (Read more, below.)
With the result of the timer, referees ruled that Boise State's shot was invalid, and the game went on to double overtime where Boise State lost. Afterwards, the Mountain West Conference organization, in which both teams play, defended the outcome based upon the embedded timer showing that 1.3 seconds passed and released video of the replay footage. That footage however, clearly displays the game clock. It shows that the game clock, which was counting down from 0.8, counted down to 0.7 seconds 0.7 seconds after the in-bounds player touched the ball. The game clock also shows that there were 0.4 seconds left when the shot was taken. The problem arises however, that the video also reveals that embedded timer counted 1.3 seconds between when the ball was touched and when the shot was taken, meaning that in the time in which .3 seconds passed on the game clock, the embedded timer had counted .6 seconds. Speculation has now arisen that the video footage may have been taken at 60 fps, but that the embedded timer may have calculated the time with an assumption that the video was taken at 30 fps. This closely matches ESPN's own timing, showing that only 0.63 passed.
Coming from a lifetime of bad calls in every sporting league ever, I'd encourage everyone to realize that the call made on the field of play is the only call that matters. It's a game, but not only that, it's a game you agreed to play under the appointed judges. Don't like the calls? Change the agreement you play under. Until then quit your whining and play ball.
I'm not sure the officials did anything wrong, but these things are horribly inaccurate. Here's what Boise State's coach had to say about it:
Boise State coach Leon Rice's frustration wasn't so much with the officials' decision as with the use of video to supersede the game clock.
"It opens a can of worms," Rice said Thursday in a phone interview with The Associated Press. "Why are those milliseconds [at the end] more important than any other time throughout the game?
"Because all my life, I've gone off the clock on the scoreboard -- and [Webb] got it off before that."
It's quite common to go to replay to see if a last second shot got off on time. This is also done with shot clock violations. There's a light on the backboard, an orange LED strip around the edge, that goes on when the shot clock or game clock is at zero. Officials simply look to see whether the player is still touching the ball when the light goes on. Of course, neither the game clock nor the shot clock is especially accurate because it requires people to start them running. And yet I don't normally see this come up because officials simply look at the ball, the player's hand, and the light on the backboard.
We, the people who work on the technical back-end to create the HD broadcasts you watch, are fighting a never-ending battle with crappy, hastily-written software that can't tell the difference between 30fps and 60fps.
Professional video gear that costs tens of thousands of dollars per unit still have software settings that assume the video coming into them is 29.97fps in both the settings and math calculations, which hasn't been used in broadcasting since the days of standard def. Even frame syncronizers - the workhorse devices that cross-convert and conform video feeds into whatever standards we need - still push out software that claims an output of 29.97fps when it's really pumping out 59.94fps. Not to mention, when the marketing staff puts together an on-air read to tell you how super-duper-awesome their new super-slow-mo cam-du-jour is, I can't tell you how many times I hear on-air talent still use the "regular cameras shoot in 30 frames a second but ours shoots 1,000!!@!" technical explanation, which just flat out isn't true anymore and hasn't been for nearly a decade.
If it's HD, you're more than likely staring at 59.94fps. In fact, any time you see an HD picture that is in 29.97fps, people immediately ask "Hey, why is that picture strobing?" This was a huge problem back when GoPros could only do 1080p at 30fps. Anyone who wasn't smart enough to set the cameras to 720p and upconvert them was met with very substandard results.
The only reason this hasn't come to a head sooner than this, is most of the time this poorly-written software and it's completely inaccurate timing isn't used as an official timing device to determine the outcome of a game. It was only a matter of time, pun not intended.
Baloney. The vast majority of sport programs are a net loss for the University. ESPN did a story on this. Even the powerhouses like Alabama (Football) lose massive amounts of money. People think the Universities are making massive money off of these teams, but reality it is just the coaches and Athletic Directors getting rich.
Professional broadcasts use something called "time code". Time Code Generators work along with a sync generator to make sure that every frame that a television truck creates gets created at precisely the same moment, and gets tagged with a unique and sequential timecode. The better ones sync with GPS or a modem to give precision time, the cheaper ones you have to manually set - usually with a cell call to the atomic clock. We embed that timecode signal into the ancillary data of each video frame, and produce a side-channel audio signal with the data embedded for devices that can't accurately read the timecode from within the video frames. We have to be incredibly accurate - as a video frame that is a fraction of a microsecond out of time can cause all sorts of issues. This used to be a huge deal in analog standard-def video - any frame that was out of time could cause the picture to shift horizontally or vertically (think of bad tracking on VHS tapes as a small example). Even sync was less accurate - sync was delivered through "black burst" which was literally just that - a burst of a black video signal, where you took the sync pulse and lined it up to ensure the timing of the frame was accurate or "close enough". Now with HD, we use tri-level sync which is way more accurate.
For the TL;DR crowd, in a production truck we can make precision measurements of time based on our sync and time code. The company that has created a good percentage of the official replay systems in the US - DVSport - has no access to our sync or time code. They also take our uncompressed frames and compress them into a video stream. They generate something loosely akin to our time code, but really it's just a reference point to where in the compressed stream you'd like to view.
Because of the inherent inaccuracies of how they time tag their compressed video and the inaccuracies of their internal clock itself, their time code - even when properly set - can "float". The longer you record, the more float you get - and it's not unusual to see minutes of float in a day. But if your internal source clock is inaccurate - and your math is trying to divide a second into the wrong number of frames - you get issues like this. You get severe time code float with 60fps vs 59.94fps alone, and that's BEFORE considering how accurate your reference clock is, and without any regard to how accurate your MPEG video encoder is. People are speculating that the software didn't know the video source was 59,94fps and was doing math based on 29.97fps or 30fps.
Even in the professional world we get tiny bits of "float", but ours is typically only a frame or two per day. We also issue what's called a "time code jam" - where we issue a uniform break in the time code stream to make sure every device is still synchronized to each other without falling too far behind actual time of day. These cheaper replay devices don't come anywhere near that level of accuracy.
Now imagine loosely time-tagging video into a compressed stream, and taking that wholly inaccurate time and reattaching it to video frames that are being uncompressed by an MPEG decoder on-the-fly. And now you can see how accurate relying on a replay system time overlay is. Prosumer video products like DVSport don't hold a candle to the timing standards we use in professional television production. Not that they can't - they just don't. More than likely because it's never become an issue up until now - or worked "well enough" for no one to notice. That is, until something as big as the outcome of a game relies on your kludge of a modestly-accurate timing reference.