FS7: Is the HDMI Output REALLY Uncompressed?

basspig

basspig

Veteran
I raised this issue on the forum for the Shogun product and someone raised an interesting question:

"Is the HDMI output truely uncompressed signal?"

I had believed it was and not post encoder, but the fact that the macroblock pattern is IDENTICAL for both the HDMI recording to Prores on the Shogun and the internal XAVC, it has me wondering if those artifacts are being transmitted out the HDMI port.

Prores422 frame grab:

https://www.dropbox.com/s/zsxg1y5wqw2l2un/Shogun%20macroblocks.PNG?dl=0


XAVC still frame grab:

https://www.dropbox.com/s/232uaaqntdfibbr/XAVC macroblocking.PNG?dl=0

I remember scrutinizing Shogun footage recorded at 1080P from my EX3 via SDI port, and seeing not a trace of macroblocks. Mosquito noise, a bit at 200% magnification, but no macroblocks. I can't imagine that in UHD record mode, Prores jumps from a JPEG encoding to a long-GOP encoding format. The identical nature of the two images, recorded side by side, makes me suspicious of the quality of the signal coming out the HDMI jack.

Can anyone in the know tell me if that HDMI out is truely uncompressed and free of compression artifacts?














 
Yes, it's uncompressed, because that's what HDMI is. HDMI is a standard for sending raw pixel values down a wire -- it's like the digital version of VGA. Arguing over whether it's "really uncompressed" (not just you, lots of people) is like arguing over whether it's really digital, or really a wire with copper in the middle.

And yes, I know that people talk about "uncompressed HDMI" as a feature. That's either because:


  • they're marketing people trying to sell you something that you get automatically
  • they're trying to say "clean HDMI", but for some reason don't know how to say it
  • they just don't know what they're talking about.

OK, being less snarky, "uncompressed HDMI" also refers to the fact that you can get uncompressed video out of the camera (via the HDMI out) as opposed to the compressed video off the memory card. Of course, the HDMI output may have a lower bit depth (like 8-bit), or more chroma subsampling (like 4:2:0).

Bottom line, there are no macroblocks in HDMI -- just pixels.

As for what you're seeing -- my guess is you're seeing macroblocks because the image has a ton of motion in it, and maybe exposure issues. So both codecs (H.264 in the camera, and ProRes on the Shogun) are getting stressed. I would guess that they both use 16x16 macroblocks, which is why you're seeing them in the same place in both images. Even if not 16x16, it's most likely that theyr're both powers of 2 (like 8x8), and so the edges will line up perfectly.
 
AtticusLake said:
Yes, it's uncompressed, because that's what HDMI is. HDMI is a standard for sending raw pixel values down a wire -- it's like the digital version of VGA. Arguing over whether it's "really uncompressed" (not just you, lots of people) is like arguing over whether it's really digital, or really a wire with copper in the middle.
Click to expand...

Sure, but what if you are sending already compressed signal via HDMI? In example, you connected a DVD player or any other device which outputs compressed content, HDMI transfers pixel values BUT these are pixel values of already compressed image, HDMI does not contribute to compression artifacts, it just sends them as "raw pixel values down a wire". I don't know if it would make sense in the camera but the question of the OP is valid.
 
That, too, is my understanding of HDMI, but it's WHERE it is picking off the signal in the chain that I am not so certain of, given that when overlaid, two images of the same frame, toggling visibility of the top layer yields little change other than a slight color cast.
My past research on Prores 422 indicates the compression is akin to JPEG, not MPEG, so the appearance of 8x8 macroblocks was unexpected and raised the suspicion that perhaps I'm seeing the XAVC-encoded signal out the HDMI in realtime, or maybe delayed by the encoding lag, but not necessarily the un processed (other than debayering) stream from the sensor?

I'm going to shoot some more controlled tests and see if I can nail down what's causing this. If Prores is no better than XAVC, I can ditch the Shogun.
 
Better or worse might be difficult to nail down. If you have a fast computer with good gpu, you might not be seeing any performance penalty for the xavc files. If you have a slower computer, then the prores should be giving you better performance while editing.

But if the first case is present, and both are 8 bit 4:2:0, then there may not be any reason for the extra box and cables.

You may need to split the video into Y, U, and V layers so you can see what's really happening on both luminance and chrominance portions.
 
The Prores has the advantage that my quad core can play it without dropping frames in CS6. XAVC playback in Resolve is more like watching flipbook animation, a frame here a frame there.. and then crash. I have a 4GB GTX 680 GPU, which is the highest one on the Adobe compatibility list for CS6.

A new build with 14-core CPU, 128GB RAM, 12GB Titan GPU is on the drawing board. I hope that's enough, even though it's barely 4X better on Cinebench scores I've seen it do on Youtube.

I did a test today, and shooting the face of a rough boulder brings out the artifacts. I do see macroblocks on the Prores 422 version, but not as apparent on this particular example. The XAVC, of course, shows very obvious macroblocks at 200% magnification, while the Prores 422 in this same shot shows a more subdued block pattern and more fine detail in the rock face. Without the rushing water of the other shot, the Prores 422 did considerably better in this instance.

The thing that makes macroblocks worse is the tendency for abutting edges to contain contrasting color/luma values. If they were closely matched, they would be hard to spot.
 
This macroblocking looks very bad. I have not seen anything like that anywhere in my footage. Since the pattern of it is the same and does not seem to depend on the codec - is it possible that this is your NLE system generating the artifacts?
 
basspig said:
Here's a sample from a test shot I did today. The upper right quadrant looked the worst.

https://www.dropbox.com/s/jui8m9ctx5zo2w7/Prores422 macroblocks.PNG?dl=0

On the XAVC version, it is even worse--looks like an image printed on basketweave. Evidently, both CODECs use a macroblock type compression method. They seem to have strengths and weaknesses, depending on the content and motion.
Click to expand...

What is the original resolution of the clip? How big is the area you included a screen grab off in the original clip (are we looking at 100%, 200% magnification, etc) ? Something really tells me those artifacts are generated by your computer.
 
Original video is 4K. This is a 200% crop. The area can be figured out from the dimensions of the still image. It's about 1000 pixels wide, so about a 500 pixel wide block of the original image is shown here.
Why would a computer generate artifacts? Isn't that the software's job? The computer can either run it slowly or quickly, but the results should be the same.
 
basspig said:
A new build with 14-core CPU, 128GB RAM, 12GB Titan GPU is on the drawing board. I hope that's enough, even though it's barely 4X better on Cinebench scores I've seen it do on Youtube.
Click to expand...

OTT
I wouldn't go crazy with a high core count CPU or a Titan, you'll get better performance from a 6 core with much higher clock speed because it will be able to feed the GPU better than the 14 core ( I didn't know they made them yet). I'd also suggest some PCIe attached flash and have as much of it as you can afford, it's much better than SSDs.

My Macbook Pro's flash storage is tipping 2 GB/s and it makes editing 4K a breeze, in fact I had to check that FCPX hadn't proxied the media when I first tried it. You can skim a timeline like it's DV footage. Go Flash and you'll never go back.
 
broughtonfilm said:
Sure, but what if you are sending already compressed signal via HDMI? In example, you connected a DVD player or any other device which outputs compressed content, HDMI transfers pixel values BUT these are pixel values of already compressed image, HDMI does not contribute to compression artifacts, it just sends them as "raw pixel values down a wire". I don't know if it would make sense in the camera but the question of the OP is valid.
Click to expand...

You're absolutely right to think that things can be way more complex than they should be, and that electronics manufacturers sometimes do apparently crazy things for wierd reasons -- I've been involved with some of that myself in products I've worked on.

But in this case, I'm afraid it does NOT make sense in a camera. For this to happen, the camera would have to compress the video to H.264, then de-compress it to get back to a raster image, then send that over the HDMI.

First, this would be really dumb; but second, it would require the camera to have an H.264 DE-coder. Which it doesn't have.

So, no. The image coming out from HDMI is the image BEFORE it gets compressed.
 
basspig said:
... raised the suspicion that perhaps I'm seeing the XAVC-encoded signal out the HDMI in realtime, or maybe delayed by the encoding lag, but not necessarily the un processed (other than debayering) stream from the sensor?
Click to expand...

(By the way, XAVC is just H.264.) So no, the camera doesn't output H.264 over HDMI, because that's not what HDMI is. It's just pixel rasters -- no compression. See my post above too.

basspig said:
I'm going to shoot some more controlled tests and see if I can nail down what's causing this. If Prores is no better than XAVC, I can ditch the Shogun.
Click to expand...

Sounds like a good plan -- I strongly believe that it's well worth testing your kit, so you know the limits of its capabilities.

But I guess I don't know why you would expect ProRes to be better than XAVC. The FS7 has VERY good XAVC, with a good high bit rate. The ProRes bit rate is higher, but that's only because ProRes is an EXTREMELY simplistic codec, with no inter-frame compression -- which can give you HUGE gains in video. Now, that simplicity can certainly be a benefit, but ProRes 422 is an old codec. I found it to be a slight improvement over the 24 Mb/sec AVCHD on the FS700; I would be amazed if it was significantly better than the XAVC from the FS7.

basspig said:
Evidently, both CODECs use a macroblock type compression method.
Click to expand...

Most do, I think. H.265 moves to a more versatile scheme -- still basically macroblocks, but with nested partitioning based on the content.
 
basspig said:
Why would a computer generate artifacts? Isn't that the software's job? The computer can either run it slowly or quickly, but the results should be the same.
Click to expand...

I meant the system, computer + software. Since the example posted here is a screen grab (is it?) then it's quality depends on how your system decodes the clip. I have a player which struggles with some types of video, if I took a screen grab of a video played by it, it would show artifacts generated by the player (on top of clip's own artifacts). Similarly if it is an exported frame in an NLE (then cropped), whether the clip is decoded properly or not would affect the frame grab's quality.
 
Last edited:
AtticusLake said:
But in this case, I'm afraid it does NOT make sense in a camera. For this to happen, the camera would have to compress the video to H.264, then de-compress it to get back to a raster image, then send that over the HDMI.

First, this would be really dumb; but second, it would require the camera to have an H.264 DE-coder. Which it doesn't have.
Click to expand...
Can the FS7 not play back its internal XAVC recordings? Because it would need an h.264 decoder to do that.

It is not unheard of for the output of a camera to be tapped off far further down the processing pipeline than one might expect. What "makes sense" intuitively, and what may actually happen can be two different things. There may be valid engineering reasons why it is simpler to do something a particular way which cannot be guessed at without detailed knowledge of the camera systems. I have no knowledge of the processing in the FS7, so can't comment on if this does happen there. I'm not suggesting it does.
 
Nick_Shaw said:
Can the FS7 not play back its internal XAVC recordings? Because it would need an h.264 decoder to do that.

It is not unheard of for the output of a camera to be tapped off far further down the processing pipeline than one might expect. What "makes sense" intuitively, and what may actually happen can be two different things. There may be valid engineering reasons why it is simpler to do something a particular way which cannot be guessed at without detailed knowledge of the camera systems. I have no knowledge of the processing in the FS7, so can't comment on if this does happen there. I'm not suggesting it does.
Click to expand...


Some valid points here, but it's also worth logging some things we do know about the FS7 pipeline:

1. It's possible to record XDCAM 422 in 1080p. This is a different codec, and very likely handled by it's own chip.
2. The HDMI can do operations like showing display menus or adding an output LUT not applied to recorded XAVC footage.

While this doesn't tell us whether the HDMI takes the XAVC encoded pipeline and adds to it, it's worth considering that can't *just* do that - it's got to add further processing afterwards, which would essentially mean it would need to decode the XAVC to do so - ie, to apply the display menu and LUT and such. That doesn't seem like a sensible engineering choice.
 
Nirv, can you point me to some benchmarks that show the 6-core outperforming a 14-core in XAVC decoding? Every benchmark I've been able to find show the 14-core at least 3X faster than the top of the i7 line.

All my drives are SSD, and the system can play back uncompressed 4K (rendered animation from Maya) more smoothly than it can play XAVC. I'm sure the drives are not a bottleneck with compressed 4K.



AtticusLake, if XAVC is just h.264, then why is it that CS6 can play h.264 UHD with no frames dropped, and gives a 'general error' when importing XAVC? And on an NLE that accepts XAVC, or even VLC Media Player, the h.264 plays smoothly, but the XAVC plays a few frames and freezes? I know it's a flavor of h.264, but there must be several levels of complexity and XAVC is probably the very top, requiring dedicated ASICs to properly decode it in realtime. Obviously, the FS7 has them, because it can play back it's own media smoothly, but not my NLE.

My testing yesterday did reveal that in the particular shot (a rough face of a boulder/rock in a wooded area), the Prores 422 did considerably better at capturing fine detail. In the background that was less in focus, some fiddlehead ferns showed macroblocks. It was much worse on the XAVC clip. Also, the detail of the rock's surface was smoothed out a bit. At normal viewing distance on a 4K monitor, this difference is not noticed. If I get within 8" of the display, and toggle the Prores track on and off, I can see a slight change in the detail of the rock. So this leads me to believe that some situations still favor Prores. I want to try an HQ Prores test too at some point and see if it's demonstrably cleaner. The Prores files are HUGE though. I think around a gig a minute in 422.

It is possible that the NLEs have varying levels of decoding quality based on the way it's implemented in each, so I can't be sure if I'm seeing the full quality of XAVC or not. Remember the first Xing MP3 player? It played back MP3s at AM radio quality, and then a year later, I found a player that could decode the second layer and got the quality up to FM radio levels. I am wondering if something like that is going on here, but that seems illogical, as any NLE that degraded the quality of footage would be booted out of the market within a week of discovery. I realize I'm being critical, and not everyone views 200% crops of parts of the picture. But I want to make sure that what I finally shoot for high end 4K theater demo material looks as good as it possibly can. I may have to go all the way to raw dpx files for that.
 
Have you actually played any of the 4K material in a 4K home theater setting to evaluate how it actually looks in it's intended environment, yet?

I'm not one of those guys that blindly subscribes to the "it's good enough" philosophy, but you may be fretting over something that will never come into play outside of a highly scrutinized post-production environment. I know sometimes there are things that I see and hear at the acquisition level that aren't even noticed in post, much less final delivery at the home/consumer level(yes, I realize that several hundred thousand dollar 4K home theater level with six figure projectors and the expectations that go with them is different that even a high-end off-the shelf set with DirecTV). Just sayin' you may be worried over nothing.
 
Last edited:
Nick_Shaw said:
Can the FS7 not play back its internal XAVC recordings? Because it would need an h.264 decoder to do that.
Click to expand...

Urrhh... good point. Still, the idea that it would compress and then de-compress WHILE RECORDING makes little sense... for that, it would need sufficient CPU power to do both at once. And why? All this just to make the HDMI look crappy? Doesn't seem likely.

Nick_Shaw said:
It is not unheard of for the output of a camera to be tapped off far further down the processing pipeline than one might expect. What "makes sense" intuitively, and what may actually happen can be two different things.
Click to expand...

Definitely a good point. I'm sure the HDMI out has been through de-Bayering, picture profiling, white balancing, chroma subsampling, etc. But none of those cause macroblocking. To get that, you would have to be into the H.264 process, and that -- as I said above -- makes no sense to me.
 
You must log in or register to reply here.
Back
Top