[Goose]

BC, I think both feeds were showing one version or the other of the game clock.  The officials might have recorded the stadium clock - it certainly has the same segments as the clock shown by NBC.  Or maybe they showed a recording of the official's clock (in a booth somewhere) which controls the stadium clocks. The command to change the lights from 0:01 to 0:00 might hit the official's clock in a nanosecond (literally) while the same command to the stadium clocks would arrive a few microseconds later (accounting for setting up the command packet, sending it out, it being routed to the stadium clocks, speed of light to the stadium clocks, arrival of the packet, and interpretation of the packet).  Since the cameras observe at likely no better than millisecond resolution (a frame is about 30 ms), the difference in arrival time should be a couple of orders of magnitude less than the temporal resolution of observing them.    If Wifi is involved, then the delays could be considerably more but should still normally be less than 10 milliseconds.

But, yes, there could be a technical glitch that makes the two noticeably different, so a rule deferring to the stadium clock is reasonable.

Now that I think about it, the use of off-site replay officials seems to me to significantly increase the chances of lost frames (more networking infrastructure between camera and recording device).  That won't matter much if individual views are separately used to make a call (did the tag touch the player) but it can matter if two cameras are coordinated (one camera on the bag at first base while the other is watching the ball go into the glove).

Again, tagging frames with the source's GPS time seems so simple and avoids most problems (that is, if you have GPS).

First, the frame rate of modern "TV" is 60 frames per second, not 30 frames per second. Each frame is 16.666... ms long. Second, in stadiums the cameras are all "GenLocked" together. Each frame on all cameras starts at almost exactly the same time. There is less than a millisecond delta between them.
 
There are exceptions in the case of some highly mobile cameras but they are few. Ask Google the following question: "are the skycams genlocked to the same reference as other cameras in the stadium". The answer is that indeed they are. The answer also contains an explanation of exactly how. It must be said that the critical concept is that all frames of essentially all cameras in the stadium start at almost exactly the same time. The reason for this is historical. Before digital technology was available if a switch was made from one analog video stream (camera) to another and said frames were not in sync the analog TVs watching the game would lose vertical sync. If each line of the frame wasn't started at the correct time the TVs would loose horizontal sync. You would get a "video tear" and lose several frames before the customer's TVs would re-lock. Obviously customers wouldn't like that. Therefore the system was designed to ensure that wouldn't happen.

In a modern digital system it is possible to buffer up frames and delay transmitting them. That allows fixing framing errors from the few cameras that are not genlocked to the master. If frames are "lost" in the digital transmission system the receiving system knows it because the UDP IP packet sequence numbers contain a "hole". If TCP is used retransmission will ensure nothing is lost. The problem with TCP is that retransmission may take too long and a frame may be unavailable when it is needed to be displayed. This isn't a problem in a replay situation because the replay can be buffered as much as necessary to ensure no packets are missed. In "real time" displays what is displayed when a necessary packet is not available is usually the previous packet. OK visually if only a few packets are lost, not so good otherwise. I think we have all seen this when serious technical difficulties exist. The actual transmission to the customer of the video data is always buffered considerably. This allows TCP data to be re-transmitted without being visually noticeable.

Given that the cameras are genlocked and the frames are of a fixed temporal length the time of each frame can be determined to at least ms accuracy simply by counting frames (including missed frames if any by noting packet sequence number gaps). You can use a Stratum 0 reference if you wish, but it isn't necessary. A good TCXO will work just fine. All the timing is relative to the same reference. The drift of the reference is much much less than other errors in the system.
 
The TV technology is not the issue. If there is a camera genlocked to the same master recording the displayed game time the game timestamp of each individual frame can be very precisely determined. What NBC and/or the NCAA/B1G deploys to execute this determination is another question. A system that automates displaying the game time for each frame can relatively easily be constructed using the existing hardware design. Whether that has been done or not I don't know.

[Goose]

BC, I think both feeds were showing one version or the other of the game clock.  The officials might have recorded the stadium clock - it certainly has the same segments as the clock shown by NBC.  Or maybe they showed a recording of the official's clock (in a booth somewhere) which controls the stadium clocks. The command to change the lights from 0:01 to 0:00 might hit the official's clock in a nanosecond (literally) while the same command to the stadium clocks would arrive a few microseconds later (accounting for setting up the command packet, sending it out, it being routed to the stadium clocks, speed of light to the stadium clocks, arrival of the packet, and interpretation of the packet).  Since the cameras observe at likely no better than millisecond resolution (a frame is about 30 ms), the difference in arrival time should be a couple of orders of magnitude less than the temporal resolution of observing them.    If Wifi is involved, then the delays could be considerably more but should still normally be less than 10 milliseconds.

But, yes, there could be a technical glitch that makes the two noticeably different, so a rule deferring to the stadium clock is reasonable.

Now that I think about it, the use of off-site replay officials seems to me to significantly increase the chances of lost frames (more networking infrastructure between camera and recording device).  That won't matter much if individual views are separately used to make a call (did the tag touch the player) but it can matter if two cameras are coordinated (one camera on the bag at first base while the other is watching the ball go into the glove).

Again, tagging frames with the source's GPS time seems so simple and avoids most problems (that is, if you have GPS).

First, the frame rate of modern "TV" is 60 frames per second, not 30 frames per second. Each frame is 16.666... ms long. Second, in stadiums the cameras are all "GenLocked" together. Each frame on all cameras starts at almost exactly the same time. There is less than a millisecond delta between them.
 
There are exceptions in the case of some highly mobile cameras but they are few. Ask Google the following question: "are the skycams genlocked to the same reference as other cameras in the stadium". The answer is that indeed they are. The answer also contains an explanation of exactly how. It must be said that the critical concept is that all frames of essentially all cameras in the stadium start at almost exactly the same time. The reason for this is historical. Before digital technology was available if a switch was made from one analog video stream (camera) to another and said frames were not in sync the analog TVs watching the game would lose vertical sync. If each line of the frame wasn't started at the correct time the TVs would loose horizontal sync. You would get a "video tear" and lose several frames before the customer's TVs would re-lock. Obviously customers wouldn't like that. Therefore the system was designed to ensure that wouldn't happen.

In a modern digital system it is possible to buffer up frames and delay transmitting them. That allows fixing framing errors from the few cameras that are not genlocked to the master. If frames are "lost" in the digital transmission system the receiving system knows it because the UDP IP packet sequence numbers contain a "hole". If TCP is used retransmission will ensure nothing is lost. The problem with TCP is that retransmission may take too long and a frame may be unavailable when it is needed to be displayed. This isn't a problem in a replay situation because the replay can be buffered as much as necessary to ensure no packets are missed. In "real time" displays what is displayed when a necessary packet is not available is usually the previous packet. OK visually if only a few packets are lost, not so good otherwise. I think we have all seen this when serious technical difficulties exist. The actual transmission to the customer of the video data is always buffered considerably. This allows TCP data to be re-transmitted without being visually noticeable.

Given that the cameras are genlocked and the frames are of a fixed temporal length the time of each frame can be determined to at least ms accuracy simply by counting frames (including missed frames if any by noting packet sequence number gaps). You can use a Stratum 0 reference if you wish, but it isn't necessary. A good TCXO will work just fine. All the timing is relative to the same reference. The drift of the reference is much much less than other errors in the system.
 
The TV technology is not the issue. If there is a camera genlocked to the same master recording the displayed game time the game timestamp of each individual frame can be very precisely determined. What NBC and/or the NCAA/B1G deploys to execute this determination is another question. A system that automates displaying the game time for each frame can relatively easily be constructed using the existing hardware design. Whether that has been done or not I don't know.