View Full Version : What encoder made this beautiful mess?
funskel
29th May 2018, 20:54
This is from the in-car video from the 2018 Azerbaijan Grand Prix:
https://i.imgur.com/NHgnSer.jpg
some more captures and a larger version of this one are in this album (https://imgur.com/a/Am0itMe), though I'm afraid they're from a different camera on the same car. I didn't notice that until now. They show the kind of dropped reference frame artifacts we're used to.
I found a drawing of a camera and "Camera Control Unit" packaged inside a mirror that says it's supplied by "Formula One Management," but no more detail. Formula E uses Vislink's (https://www.vislink.com/products/hcam/) "Gigawave HD on-board camera and H.264 video transmission system" which is just regular HEVC. Their older stuff is just AVC.
I have noticed some series' in-car encoding used Periodic Intra Refresh which has a peculiar look to it, but I've never seen the explosions of color here.
This is from Sky Sports via ESPN through Comcast to an X1 DVR then to the Stream app on an iPhone in San Jose, California. You can see the graphics overlays are undistorted which is why I'm assuming it's the in-car encoder.
Shirtfull
29th May 2018, 21:33
Bad signal reception caused by interference, from car to base.
FranceBB
30th May 2018, 07:30
What encoder made this beautiful mess?
Simple, it's LSD. Just joking.
There are 24 fibred cameras around the track, pit-lane, heli-cam, RF cameras and on-car cameras, with a total of about 60 individual sources. We are running a Quad 3G UHD system and the majority of sources require five inputs on the router and it doesn’t take more than the addition of another two to three cameras, for virtual graphics insertion. On the top of that, we air in 4K HDR, but some of the cameras (like the one you pointed out) are not in HDR and we route their signal to a live converter using a matrix and routing the output to the video mixer. We receive the feed via Fiber but we also get a backup via Sat, but we switch between these two only if we really need to. Our production is on remote, which means that we are not on the field, we are many miles away. In other words, sometimes these kind of things happen, but these issues are already in the signal that we get, because, even though fiber is stable (we no longer work in sat, 'cause we use sat only as a backup), the mess you see occurred on the field due to poor reception of the camera placed on the car.
Their older stuff is just AVC.
Actually, XAVC 10bit.
You can see the graphics overlays are undistorted
That's because the clean feed is routed to a DFS, passes through an MCR which is routed to Viz Mosart that adds the graphics, but it's not our fault if the clean feed we get is already screwed up.
I'm assuming it's the in-car encoder.
The encoder works fine, but the receiver gets a spoiled signal due to bad reception and sends to us an already spoiled signal.
Ghitulescu
1st June 2018, 10:06
The Kaspersky antivirus interferring with the packet data transmission :) :) :)
funskel
2nd June 2018, 03:20
The encoder works fine, but the receiver gets a spoiled signal due to bad reception and sends to us an already spoiled signal.
Right, but the encoding method used will have an effect on what the decoder can put together from the data that was received. If you used all I frame, you might have garbage macro blocks, but you wouldn't have legit-looking blocks of pixels in the wrong places due to the wrong reference or right reference with wrong motion vectors being used.
HEVC should look different than AVC because of variable CTU partitioning vs. fixed 16x16 blocks. I think you can see that in the 2nd image in the album I linked where there are some teeny blocks and some that are taller than wide.
Looking at images 2, 3, and 4 in the album, there are colors that were captured by the camera at some point, maybe a few frames back and incorrectly motion compensated. I've seen that plenty. Here's (https://www.youtube.com/watch?v=mvqakws0CeU) an example of it being used on purpose for artistic effect (datamoshing).
The colorful image is really strange, though. I've seen macroblocks that are all magenta or green or b&w checkerboards, but the oranges, blues and reds in this frame didn't come from the camera and can't be explained with normal HEVC encode/corruption/decode artifacts.
FranceBB
2nd June 2018, 07:31
That's correct. Moto-compensation creates these issues on bad signals and the intra class profile should be preferred in XAVC. The longer a GOP is, the more prone a decoder is to display artifacts is something is missing (like a slice error).
Intra class, however, requires higher bitrate 'cause all frames are intra and there aren't p and b frames and a more stable signal can be achieved using a long delay (generally between 5 and 20 sec), but that's unacceptable on live sports events.
Anyway, i didn't decide how to set encoders, I have no rights in deciding that, other people did, I've just recently joined the company (2016), but I'm pretty sure there's a logistic reason behind everything.
foxyshadis
5th June 2018, 21:47
Simple, it's LSD. Just joking.
There are 24 fibred cameras around the track, pit-lane, heli-cam, RF cameras and on-car cameras, with a total of about 60 individual sources. We are running a Quad 3G UHD system and the majority of sources require five inputs on the router and it doesn’t take more than the addition of another two to three cameras, for virtual graphics insertion. On the top of that, we air in 4K HDR, but some of the cameras (like the one you pointed out) are not in HDR and we route their signal to a live converter using a matrix and routing the output to the video mixer. We receive the feed via Fiber but we also get a backup via Sat, but we switch between these two only if we really need to. Our production is on remote, which means that we are not on the field, we are many miles away. In other words, sometimes these kind of things happen, but these issues are already in the signal that we get, because, even though fiber is stable (we no longer work in sat, 'cause we use sat only as a backup), the mess you see occurred on the field due to poor reception of the camera placed on the car.
Their older stuff is just AVC.
Actually, XAVC 10bit.
You can see the graphics overlays are undistorted
That's because the clean feed is routed to a DFS, passes through an MCR which is routed to Viz Mosart that adds the graphics, but it's not our fault if the clean feed we get is already screwed up.
I'm assuming it's the in-car encoder.
The encoder works fine, but the receiver gets a spoiled signal due to bad reception and sends to us an already spoiled signal.
I just have to say that for the incredibly demanding conditions you have to perform in, your work is amazing, and that we get a first-hand answer is why I love Doom9.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.