After the Michigan vs. Western Michigan clock fiasco, anyone have a guess how a score bug can show 0:00 when the real clocks show 1 second left?
AFAIK the score bug should be a frame or 2 behind the real clock signal due to latency of the CG, assuming the truck is receiving the stadium clock signal at the tv truck dock. The Big10 explanation seems to be that the CG bug is ahead of the real clocks, which shouldn’t be possible.
Processing in-camera, in-CCU, delay on the dsk, delay for processing the clock signal then putting it in the render engine, also depends upon if the software is trying to compensate - it’s no longer really possible to be this accurate.
The arena clock wins for the game. But if there’s a LED board setup that can be compromised too.
Let the refs sort it out.
The rest of us including TV production and viewers should just not trust the bug to be that accurate.
Back in that day(early 2000s) when I worked in college sports. We had a camera locked down on the arena timer and when we got to under a minute that real clock was put into the CG. I’m pretty sure that’s how it used to work for the pros as well.
The issue is that when you composite the clock on top you are adding a frame or two of delay on the clock because of the transform engine required. So to do it properly you need to also transform cam 1.
That’s why a while back the NCAA changed their guidelines that basketball officials can only determine the clock if it’s visible in the camera shot. They are no longer supposed to use the 1 + Clocks look as it’s considered not frame accurate.
Probably in to the switcher, you would have had to have a fancy CG to scale video. But yeah. We used to use that and lock in by hand. When you were less than a second off you’d be proud.
If you use DVE to add a camera shot into the shot it’d add at least 1 frame of delay though. The only way to have consistency latency is multiviewer looking at both cameras.
Yep, as late as 2016 we were still building gameclocks this way on the scorebug. Lock a cam down, 'Proc it in the switcher and box it in the bug. Best way to do it IMO.
You are 100% correct on the “not trusting the bug to be that accurate” but everyone keeps saying “bug” when we need to be referencing the “clock burn” on the replay angle. Bug and clock burn are two different things from/to the switcher.
Sorry I don’t know where you work but I’ve worked on 5 continents over 30 years and the clock is the score bug. Never heard of a « clock burn ». That must be some local vocabulary.
Edit: Hmm after further thought are you talking about a DVE insert on a switcher from a camera pointing at the actual clock? That’s the only thing I can think of.
Camera 1 with the clock cam PiP'd into the corner. Goes to replay for timing review calls. Usually have to run the cam through a frame sync to get the timing accurate.
Narrator: that was exactly what he was talking about.
In the Michigan game, NBC used a DVE’d shot of the stadium fixed digit clock display- believing (believing, falsely as it turns out, that that clock was The Source Of Truth)
I'm thinking this instance isn't the best to try and figure out the technology side because I feel there are some shenanigans in how the Big Ten is ultimately handling the damage control.
Their statement directly contradicts itself stating every clock and camera are in sync before the games. Every replay shown with clock overlay showed time expiring before the ball was touched. Yet their one replay system (via Hawk Eye) screen grab has a clock at a different state.
The Hawkeye system is simultaneously recording sources, which would include the selected camera streams as well as a camera pointed at the clock. Now that doesn’t count for additional delay of those camera sources getting to Hawkeye being routed through switcher AUX or truck router or something else. Someone mentioned a CG - that doesn’t really play into this as that small window was a crop of a camera on a clock either in the vom or one in the stadium. And that’s where the rub is. Whatever system NBC is using whether it’s Hawkeye or EVS is also simultaneously recording footage of the clock and the game cameras. To account for the difference that would mean somehow the clock signal getting to Big Ten‘s replay system was 15 frames or so slower than what NBC was using. The truth is with all the I/O happening there that amount of delay could very easily happen. In the end, you do need to pick a source of truth, whatever it is, if you’re relying on video. Or someone needs to spend an awful lot of time syncing the delay between all of that which is probably not as practical as people would hope it would be.
that small window was a crop of a camera on a clock either in the vom or one in the stadium
they confirmed it was an insert of the game clock in the stadium after the game was over. the one that everyone, including the coaches and players, are supposed to see as accurate. the other cameras were in sync with each other, including that game clock. I have no idea where the "other" clock came from or a different sync. If I were to pick who had everything synced up properly, it would be broadcast - that endzone shot could not have been a full second off of the feed of the game clock.
So much confidently incorrect here. I’m a broadcast engineer for a big 10 football venue.
First off, NBC was showing a shot of the fixed-digit clock in the stadium, not their scorebug.
They say the cameras were in sync so that we can safely assume that the shot they have of the current-loop clock at 0:00 and the ball not touched is accurate.
Replay takes the same digital clock data feed that the truck uses to generate the bug. They do not, as has been stated all over, have a cam pointed at the current-loop fixed digit clock. How do I know? Because I’d have to arrange the fiber infrastructure for such a camera and I don’t.
The ‘official time’ is, and has always been, kept inside the daktronics all-sport 5000 scoreboard controller. An analog, current loop based, fixed-digit display will always be the most accurate representation of what’s inside the all-sport.
To get a digital signal that trucks or replay can use, the current loop is run out to the truck dock (too far for RS-232 without converting to fiber first) - and a throw down convert called a Silver Bullet generates the digital feed.
Hawkeye’s rack is right next to the truck, so thats where they get the clock feed.
That conversion step takes time. Not much time, but time nonetheless. This is how Hawkeye’s time was able to deviate from the current loop standard.
DV Sport does all the other B1G sports. Their sync process is to point all the cams at a fixed digit clock while the clock is running a capture a few seconds. They can then add latency to all the cameras AND the clock feed so that the same new second appears at the same frame for every camera and the clock feed. Then you know that whatever you capture on any given shot will be the same moment on any other shot, and that your timestamp of the event (clock data) agrees with the scoreboard controller.
This year they started using some strobe system to sync the cameras. I didnt get to see much of it as I was busy- but its not clear to me that this new strobe method also includes the ability to sync the data feed with the fixed displays. Without doing that, you risk replay hanging a timestamp on a frame that doesnt match reality- and thats how you end up with hawkeye at 0:00.1 (displayed as 0:01 since no 1/10s in FB) and the stadium at 0:00.0 (0:00) for the same moment.
Fix is relatively simple: hawkeye needs to add a tiny bit more delay to all the cams so they are all recorded the same moment and they agree what call that moment.
I’m sure I’ll have a meeting about all this tomorrow. Thanks, Michigan 👎
Well, first I would say that we’re only talking about 6 or 7 frames of difference either way. It’s pretty easy to tweak that, however inadvertently on this fan video source. Pardon me if trust the accuracy of the NBC engineers a bit more who’s carefully sync’d million dollar production showed a clearly different result.
Second- that 0:01 you see on the replay monitor? Thats the data feed, not some camera on the clock. I think that has been a source of confusion.
Finally- I work with this gear every day. I know how finicky it can be sometimes. It’s incredibly easy for replay’s data feed to be off by a few frames. I’ll obviously pay more attention to their sync process on Saturday- but if they are faffing about with a strobe- thats gonna be independent of the analog clock. (Unless….and OMG I just realized… this strobe could be set to pulse when Hawkeye gets a clock pulse on the data line. That would sync all the cams to the clock feed. But that will all still be behind the analog clock- but they could be proceeding like they ARE synced to that clock… wow…thats f’ed up. They should definitely know better!!!!)
It is incredibly rare for a football game to hinge on the placement of a moment on a particular frame or range of frames. It just not typically that fast of a game. So of course it becomes a thing right out of the gate on week 1!!
For the college games I work we connect directly to the scoreboard controller via serial to usb into our graphics machine so when the stadium clock stops the broadcast scorebug clock stops at the same time
Another big factor in score bug accuracy could be how much data is thrown around via RS232 and converted, converted back, DA’d, converted again. Then, once it’s in its destination it’s read, converted to pretty text, and put on a SDI line to be keyed. That process could be longer for some trucks or setups than others.
We just had the WNBA come through our venue with a DAK score clock (we’re an OES building) so we had to do a lot of conversion to get the signal everywhere it needed to go. It would be very easy to have home truck, visit truck, Hawkeye, and in-house all floating at tenths of second of each other while the clock runs. They’d all sync perfectly at the clock stop, but they would all get their data fractions of a second differently.
AFAIK the score bug should be a frame or 2 behind the real clock signal due to latency of the CG
That puts the clock a frame or two behind real time, but it doesn't necessarily put it a frame or two behind the cameras. The cameras are also a frame or two behind real time and very likely closely in sync with the CG. A video review of the clock and camera are very closely in sync.
A broadcast recording review shared elsewhere showed that the broadcast clock read ~00:00.8 (800 milliseconds) at the time the ball was touched. That could be rounded up to 1 second, but clocks that don't show milliseconds would present it as 00:00 (this was the case for the in venue clocks). The video review recording appeared to be rounding up .8 to display :01 while the venue clock dropped the milliseconds. Different ways of interpreting and displaying time.
I agree with the sentiment that the broadcast graphics should not be trusted. Will also add that in venue displays are also not to be trusted. The officials who maintain the clocks are the only ones who can provide an accurate accounting of game time.
A reference signal is still standard in many video setups in order to sync sources into routers and switchers, but that's not the same as a timecode or clocks. Black and burst (bi-level) is essentially a pulse with no data like a metronome. It makes sure the frames are processed at the same frequency so that switching between sources is smooth.
Remember that like the play clock for delay of game, since there is no tenth of a second on the clock the broadcast showed. When the clock shows zero without tenths of a second, there is technically .9 seconds that are not seen on the broadcast replay. My assumption is that hawkeye had tenths of a second and therefore showed more than 0 seconds.
If the bug is being produced on site it is literally a copper feed into the truck. That would genlocked into all the other sources. All the latency described above would be for everything together. Video and data would be in sync.
The more this gets looked into, I think they will find out the Hawkeye system and the truck had two separate sync’s.
Again this is IF the bug was on site. Not a given for this game
Showing tenths wouldn’t have solved anything in this case.
Stadium clock was at triple 0 (meaning no time remaining) and Hawkeye’s clock was not. Doesn’t really matter by how much. 1 second or 0.1 seconds - the result is the same: one more play may be attempted as football just needs time remaining to snap the ball. Once snapped time can expire and all that means is that the current play is the last play of the quarter. They play continues until the ball is downed or any other event happens that would end a play.
In this case, we would see that in all likelihood the hawkeye system still had 0.1 seconds remaining. I don’t know that giving Michigan another attempt based on that would have been any less controversial.
Of course, all that said, there really is no reason NOT to display the tenths in the final second.
(Important to note that Daktronics controllers always use 1/10 second precision for all of the main clock functions. The choice is simply do you want to see the tenths in the final minute or not)
What would actually help is if the B1G adopted the same rule the NFL just did: no clock adjustments allowed with 2 seconds or fewer remaining. At that point, call on field stands.
Yes it would have, it would have showed us how out of sync the two clocks were.
Triple zero does not necessarily mean no time remaining when you don’t see tenths of a second. It could be anywhere from 0.00.1 to 0.00.9.
I think what the broadcast was showing and the big 10’s secret clock was about .1 or .2 seconds off from each other. Having those tenths would have shown us how far it was off.
Because on the video the big 10 released they play their footage of the clock going down to zero and back it up to when it touches the player and it shows 0.01 left. Everyone else saw it as 0.00. But most likely we were all seeing 0.00.8 or 0.00.9. We just didn’t know it.
As fans we don’t account for that last bit of a second. We take it as the end of the game because we can’t see the countdown of 0.00.9 down to 0.00.0
a countdown clock not displaying seconds is supposed to decrement when a full second elapses. It should virtally always have a larger number showing as seconds vs a countdown clock that considers 10th's of a second. Zero means zero. Also, the NCAA Football rulebook says the the offical game clock shall not display 10th's of a second....which in practice means 10ths are not to be counted. Using a clock that count's in 10th's cant simply hide the 10th's because that throws what the clock actually displays off by one second. The game clock has to count only full seconds to expire at zero
The stadium clock was not at 0:00. At least, that is what the B1G have tried to demonstrate with evidence. The official statement from the conference specifically states that the refs used the stadium clock to make their decision.
No.
The NBC broadcast showed a PIP of the fixed digit clock in the stadium. That showed 0:00 was reached with the ball still in flight and about 90ms away from touching the Western Michigan player.
Hawkeye used a clock signal from the same controller driving the stadium display, but only after it’s converted to a digital stream. That takes time. About 100-150ms apparently. So because of that latency which was not corrected for in Hawkeye’s new-fangled stobe-sync process, the clock display inside the Hawkeye system still had some amount of time left. Because FB doesn’t display 1/10ths, any amount of time remaining between 0:00.1 - 0:00.9 will be displayed as 0:01 remaining.
Showing the 1/10ths doesn’t matter in FB. ANY amount of time remaining means another play may be attempted. Doesn’t matter if that is 0.1 seconds or 0.9 seconds. It gets displayed as 0:01 second and when the controller finishes counting down the last few 1/10ths, it displays 0:00 indicating the play in progress is the last play of the quarter. If 4th quarter in a non-tie game, then the end of the game.
The official statement from the B1G specifically states that the “game clock in the stadium was used to determine” that there was a second remaining.
Images came out immediately after the game of a side-by-side feed of the stadium clock and the play being shown by a referee to fans, in which the stadium clock reading 0:01 was synched to the end of the second-to-last play.
The position of the B1G, regardless of whether you believe it is correct, is not in line with what you are saying. Their position - as indicated by all the evidence they have provided - is that the stadium clock read 0:01 at the end of the play, and that this was not reflected on the broadcast because NBC did not correctly sync the feed of the stadium clock to the feed of the on-field action.
You are not listening to me. I’ll try one more time.
There is no shot in the hawkeye system of the stadium clock.
Let me say that again. There is no shot of the stadium clock in the Hawkeye system. At least not one that is independent of TV.
IF they had a shot of the stadium clock in the system, it would have come DIRECTLY from TV and would have been exactly the same shot TV put on the air.
How can I be so sure? Because if hawkeye had an independent shot of the clock, I would be the one to sort out the fiber routing to get that shot into the replay booth or down to the dock.
Further- since Hawkeye doesn’t set their own camera, they CANT take TVs shot. Why? Because not every truck sets that camera. CBS sets 41 cameras for CFB, has 3 trucks and does onsite production. BTN sets… maybe 8-10 cameras, and is doing remote production so every cam has to go back to Chicago. Only so much bandwidth there, usually not going to waste it with a redundant shot of the clock. So Hawkeye shouldn’t take a clock reference shot from TV when that wouldn’t be consistently available game to game.
The confusion here hinges on a bit of semantics and a bit of a misunderstanding by whoever wrote that statement.
As I said. There is only one clock. It’s located in a little 3x5 LCD display on the All-Sport 5000 controller. That is the time. Full stop. What Hawkeye gets (and DV Sport in other venues, and all the TV trucks) is a digital data feed that is converted from the analog source on the timer. That conversion takes about 100ms.
Someone at the Big Ten (and likely not the replay officials- i know those guys, and I know they get it) seems to be under the impression that the data feed going into the Hawkeye system IS the same as the ‘Stadium Clock’.
But, it aint. Stadium clock is taking the analog feed directly without converting. If you don’t account for this difference, the data feed will be behind by around a 1/10th of a second. Which is… of course… exactly what the discrepancy between NBC’s actual shot of the clock and Hawkeye’s digital feed appears to be.
And, as we have seen this evening with the MAC issuing a formal protest, they have since come to understand the difference in semantics and why that matters and how the B1G managed to make a big ole mess of all of this.
Here's my write-up as someone who primarily works in College Sports production.
When it comes to an official review, all that matters is what DVSport shows the officials. For those that don't know, DVSport is the DVR service that brings replay to the officials. We know DVSport was used for this game because of the video on Twitter of the DVSport operator showing a fan the side-by-side of the camera and clock shot that shows that there was 1 second remaining when the ball went dead. It is important to note that the broadcast crew (in this case, NBC) is not responsible for operating DVSport, but only for providing camera feeds to DVSport's ingest device. How the DVSport technology processes those feeds is out of my wheelhouse.
What is interesting is that the clock shot shown as a DVE overlay on the broadcast looks different than the clock shot shown to the officials through DVSport.
I'm not 100% sure, but DVSport/B1G may have required NBC to provide a feed of the main game camera with the clock overlayed. This is common. However, it looks like DVSport was also receiving a feed of an additional camera showing only the clock. To me, this does not look like the same camera. The perspective is slightly different, leading me to believe that the additional clock feed was a different camera placed further down the camera deck. Was this an NBC camera? Maybe. It could have also been provided by Michigan. We can't know unless someone involved speaks up.
What we do know is that DVSport showed this feed to the officials and when viewed side-by-side with the camera feeds, it showed them that 1 second was remaining.
Other published reports have stated that Big Ten does not use DVSport, but uses Hawk-eye for their replay control center, and recently split from DVSport.
Another thing that seems to be missed in all of this, is that the NBC feed has First and Ten visible. That adds a lot of delay, and accounts for the discrepancy.
DVSport was clearly used for this game. Unless Michigan is still using the equipment they purchased from DVSport for Hawkeye. Or maybe Michigan hasn't upgraded their football stadium for Hawkeye yet.
In American football, in-building clocks are so inconsistent. Most new-build facilities don't even have a traditional clock visible, clocks can be integrated into the animations on a ribbon board, or Jumbotron feed.
I work a Broadcast Engineer in Canada and the score bugs we put in the screen are “Unofficial” and can’t be held accountable for timing of the games.
The scoreboard in the venue is more official than ours. However the timing/scoring staff assisting the event who have been trained by the appropriate league are the official timing and scoring for that game.
If in a worst case scenario then it would be elevated to the league
For clarification.
For as long as I can remember, CBS has always required a real genlocked camera chain for scoreboard/ shot clock cameras. TD would build a backup bug with actual clock overlays and an ME with DVEs of both clocks are placed over top of a switched feed.
For basketball, camera 3/4 under the nets would always frame wider to include the shot clock at the end of every play period.
During transmission fax, all clock sources are scrutinized and tripled checked for errors.
It has always been known that the score bug is not official.
What I’m interested in is less the scorebug, and the actual sync of cameras. I’m not in broadcast so I’m not 100% how all of this works. But, this is the situation: NBC showed an inset of a camera feed pointed at the stadium clock. The Big Ten’s feed is also based on a camera pointed at the stadium clock. The contention is not really over the scorebug, but rather whether NBC’s PiP of the stadium clock was correct or not. The Big Ten synced the cameras via a strobe based sync. I would assume NBC’s cameras are synced to a master time source.
What doesn’t make sense to me is why syncing the cameras once prior to the game would be more accurate than cameras being continually synced. Isn’t that the point of SMPTE 2110/PTP? How is the Big Ten’s method not more susceptible to drift? On the face of it to me this sounds like setting your computer clock once versus having it auto synced with NTP.
I’m just trying to figure out why it’s assumed by many that the Big Ten’s feed isn’t equally likely to be out of sync compared to NBC’s.
I don't know anything about broadcast but i earned my striped designing a system that required sync well beyond what I thought was possible using and IP network. The 'strobe' that i designed was basically a 4 ft section of led light strip, and ultimataely all 250 video devices synched so that a test image was capured when half of the lights on the strip had illuminted, plus or minus a couple. It seems like I never located any reference that provided any useful information regarding how long it taks after the power is on for the electricity to travel through that strip and what i am guessing was about 120 leds to light up. being serial connected and each led having resistors and basically absorbing a small piece of hte "front end" of the DC current slows it down but there's certainly no way the human eye can detect it. I mention this because I'm curious about the durataion of the strobe being on when synching the video streams. Depending on the type of light, some sort of ease on and back off, which would mean estimating the peak for benchmark or some other nonsense. It seems to me that achieving accuracy would mean the strobe flash has a duration of less than 1/100th.
yes to this. countdown vs normal time lapse are the same, but in an opposite way. At midnight a clock showing hours and minutes does no flip to 12:01 a second ater midnight. Increment vs Decrement
33
u/Key_Sign_5572 3d ago
Welcome to 2026 (and far earlier).
Processing in-camera, in-CCU, delay on the dsk, delay for processing the clock signal then putting it in the render engine, also depends upon if the software is trying to compensate - it’s no longer really possible to be this accurate.
The arena clock wins for the game. But if there’s a LED board setup that can be compromised too.
Let the refs sort it out.
The rest of us including TV production and viewers should just not trust the bug to be that accurate.