6 ms·

What causes the green line in the frame before the puck hits the camera?

53 points by sillysaurus2 13y ago

DrRandell 13y ago
Could be any number of things. If the camera is analog then sync is carried on the "green" channel. That's why most video imperfections are green. I would need more information on the camera and camera system
djent 13y ago
The way I see it happening is that the video is delayed enough so that when the puck actually hits the camera, the video gets encoded[insert correct technical term] wrong - green - for that line. Then we actually get the video of the puck hitting the camera.
- pornel 13y ago
  > [insert correct technical term] In most MPEG-family video codecs video is split between brightness (luma) and color channels (chroma). This looks like error in one of chroma channels. Image is divided into blocks and average intensity of each block (called DC) is stored as difference from a previous block. It looks like the first block on that line had invalid, out-of-range DC value stored, and this value has been propagated through entire line.
- oakwhiz 13y ago
  So... the physical impact against the camera is causing a fault with the video encoder on the camera?
  - drakaal 13y ago
    More likely caused the sensor to send invalid values for pixels. Still More likely the jostle caused data loss for a while. The green squares don't look to be 16 pixels tall. Hard to tell with the footage, but DC's are typically 16x16 or 8x8 This looks to be a CCD issue not a compression issue especially since the artifacts don't propagate to the next frame, nor cause variations in the sharpness of things in the next frame which would be common if new image data had to be created in whole rather than as a differential from the perfectly noiseless, "broken" frame before.
    - oakwhiz 13y ago
      Ah that makes much more sense.
    - bobdvb 13y ago
      Can I suggest that the loss of signal during the impact caused an issue with the encoder but because of the encoding of video if the disrupted frame was an i-frame or a b-frame then it might cause effects on p-frames?
graeham 13y ago
Looking at image No. 28 (after green line), the image is considerably darker and more pixelated than No. 26 and previous. The green line could be artifact from an auto-contrast or auto-focus.
mertd 13y ago
My guess is that those particular scanlines were being read out at the instance of the impact, which momentarily flexed the circuitry and caused funny things.
- deleted 13y ago
  [deleted]
ubersoldat2k7 13y ago
The camera shit its pants!
Luc 13y ago
Could the green line correspond to the moment the camera was hit, and the next 'closer' image show the rebounding of the puck?
larrys 13y ago
To add to rampant speculation without enough details my theory would be that it's some kind of a light reflection artifact off the puck corresponding at the exact moment of the camera scan lines and frequency.
drakaal 13y ago
There are two impacts. In front of the glass is a light mesh that is used to keep water from kicked up is from showing as droplets on the screen. That mesh is coated in a hydrophobic material and works well keeping a camera from needing to have the lens wiped. The Green Line is when the camera took that part of the impact. Likely the Sensor shook enough to cause an error. It recovered in the frame before the puck hit the lens so there is a clear frame before that. The comments about IPB frames and compression might seem logical at first, but B frames are very rarely used in live broadcast because they add so much to the delay, and cause a lot of issues when broadcast over lossy formats. If this was a broadcast from tape, the impact could have damaged the tape when the tenisioner was jostled by the impact, but typically that would do more than the small ammount of frame loss shown here, and wouldn't have been part of a live broadcast.
- ricardobeat 13y ago
  In the frame where the glitch happens the puck still looks quite far from the lens. If the mesh was positioned that far it would probably be visible and mess up autofocus. B frames or buffering would only add <100ms latency, while live transmission already has at least 1s lag, before even considering 'tape delay'. I'm betting on processing delay as the explanation.
  - drakaal 13y ago
    The mesh is about 3 feet out. B Frames to be of any use require 6 frames at 33ms each, that is 200ms, a quarter of a second, but on play back you need all of the frames in the set from i frame to i frame to get make the reference frames work, this is typically 1-3 seconds. -Brandon Wirtz SMPTE Voting Committee Member for the ratification of H.264 and VC-1 standards.
  - drakaal 13y ago
    A screen in a window only messes up auto focus when the size of the screen is greater than the size of a single pixel.
kineticfocus 13y ago
It seems to be a problem with raw sensor information prior to encoding, otherwise I figure there would be more blocky image corruption. Frame 0-26: Puck Flying Frame 27: Impact g force shorts capacitor (usually rated for ~10g), scanline loses chroma until circuit at proper threshold again. Frame 28: Frame dims b/c of occlusion from puck, and collision likely turns glass into a negative meniscus lens. Frame 29->: Officially an inelastic collision. Time to get a new camera

53 points by sillysaurus2 13y ago

Could be any number of things. If the camera is analog then sync is carried on the "green" channel. That's why most video imperfections are green. I would need more information on the camera and camera system

djent 13y ago

The way I see it happening is that the video is delayed enough so that when the puck actually hits the camera, the video gets encoded[insert correct technical term] wrong - green - for that line. Then we actually get the video of the puck hitting the camera.

pornel 13y ago
> [insert correct technical term] In most MPEG-family video codecs video is split between brightness (luma) and color channels (chroma). This looks like error in one of chroma channels. Image is divided into blocks and average intensity of each block (called DC) is stored as difference from a previous block. It looks like the first block on that line had invalid, out-of-range DC value stored, and this value has been propagated through entire line.
oakwhiz 13y ago
So... the physical impact against the camera is causing a fault with the video encoder on the camera?
- drakaal 13y ago
  More likely caused the sensor to send invalid values for pixels. Still More likely the jostle caused data loss for a while. The green squares don't look to be 16 pixels tall. Hard to tell with the footage, but DC's are typically 16x16 or 8x8 This looks to be a CCD issue not a compression issue especially since the artifacts don't propagate to the next frame, nor cause variations in the sharpness of things in the next frame which would be common if new image data had to be created in whole rather than as a differential from the perfectly noiseless, "broken" frame before.
  - oakwhiz 13y ago
    Ah that makes much more sense.
  - bobdvb 13y ago
    Can I suggest that the loss of signal during the impact caused an issue with the encoder but because of the encoding of video if the disrupted frame was an i-frame or a b-frame then it might cause effects on p-frames?

graeham 13y ago

Looking at image No. 28 (after green line), the image is considerably darker and more pixelated than No. 26 and previous. The green line could be artifact from an auto-contrast or auto-focus.

mertd 13y ago

My guess is that those particular scanlines were being read out at the instance of the impact, which momentarily flexed the circuitry and caused funny things.

deleted 13y ago
[deleted]

ubersoldat2k7 13y ago

The camera shit its pants!

Luc 13y ago

Could the green line correspond to the moment the camera was hit, and the next 'closer' image show the rebounding of the puck?

larrys 13y ago

To add to rampant speculation without enough details my theory would be that it's some kind of a light reflection artifact off the puck corresponding at the exact moment of the camera scan lines and frequency.

drakaal 13y ago

There are two impacts. In front of the glass is a light mesh that is used to keep water from kicked up is from showing as droplets on the screen. That mesh is coated in a hydrophobic material and works well keeping a camera from needing to have the lens wiped. The Green Line is when the camera took that part of the impact. Likely the Sensor shook enough to cause an error. It recovered in the frame before the puck hit the lens so there is a clear frame before that. The comments about IPB frames and compression might seem logical at first, but B frames are very rarely used in live broadcast because they add so much to the delay, and cause a lot of issues when broadcast over lossy formats. If this was a broadcast from tape, the impact could have damaged the tape when the tenisioner was jostled by the impact, but typically that would do more than the small ammount of frame loss shown here, and wouldn't have been part of a live broadcast.

ricardobeat 13y ago
In the frame where the glitch happens the puck still looks quite far from the lens. If the mesh was positioned that far it would probably be visible and mess up autofocus. B frames or buffering would only add <100ms latency, while live transmission already has at least 1s lag, before even considering 'tape delay'. I'm betting on processing delay as the explanation.
- drakaal 13y ago
  The mesh is about 3 feet out. B Frames to be of any use require 6 frames at 33ms each, that is 200ms, a quarter of a second, but on play back you need all of the frames in the set from i frame to i frame to get make the reference frames work, this is typically 1-3 seconds. -Brandon Wirtz SMPTE Voting Committee Member for the ratification of H.264 and VC-1 standards.
- drakaal 13y ago
  A screen in a window only messes up auto focus when the size of the screen is greater than the size of a single pixel.

kineticfocus 13y ago

It seems to be a problem with raw sensor information prior to encoding, otherwise I figure there would be more blocky image corruption. Frame 0-26: Puck Flying Frame 27: Impact g force shorts capacitor (usually rated for ~10g), scanline loses chroma until circuit at proper threshold again. Frame 28: Frame dims b/c of occlusion from puck, and collision likely turns glass into a negative meniscus lens. Frame 29->: Officially an inelastic collision. Time to get a new camera