KnightsFan

I'll amend the statement... "encoders universally do better with more input data." If you keep the output settings the same, every encoder will have better results with a higher fidelity input than a lower fidelity input. Therefore, if YouTube's visual quality drops when uploading a higher quality file, then it is not using the same output settings.

My second fact wasn't about whatever YouTube is doing, I was just stating that encoders almost universally do better with more input data. So if in YouTube's case the quality is lower from the 4K upload, then they must be encoding differently based on input file--which would not be surprising actually. So I have no idea what YouTube is actually doing, I'm just explaining that it's possible @fuzzynormal does see an improvement.

I haven't used YouTube in many years, but here are two facts: 1. YouTube re-encodes everything you upload 2. The more data an encoder is given, the better the results While the 1080p bitrate is the same for the viewer whether you uploaded in 4k or HD, it's possible (but not a given) that any extra information that YouTube's encoder is given makes a better 1080p file. Though my intuition is that the margin there is so small, uploading in 4k will not give any perceptible difference for people streaming in 1080p.

With the handheld footage and moving subjects focus is lost quite a bit. The shot of the orange for example I see no difference between all 3 since the orange is moving in and out of focus. But on that first shot of the plant, which is relatively still, A is the clear winner. B and C are pretty close, but I do think that one shot has C losing ground. I'd suggest shots that are similar to what you actually use since those will be most useful. I'm on a tripod most of the time, which is where you'll see the most difference between 4K and HD especially with IPB compression.

If there's no bottleneck, I personally would save my money haha. I think that for normal editing, your 1080TI probably already outperforms your CPU so adding another would likely give no benefit.

For me A > B > C. C looks the worst to me but mainly because that shot at 1:08 looks digitally sharpened which was visible in a casual viewing. I wouldn't have noticed any other differences without watching closely. I'm not sure how matched your focus was between shots but in the first composition A seems a little clearer than B which is a little clearer than C, could easily be focus being off by just a hair though.

If the CPU is bottlenecking, then money you spend on a new GPU will be wasted until the bottleneck is resolved. Same with the SSD--if that's not working at its max currently, then you can spend all the money in the world and it won't help at all. I bring up the CPU because I had a similar CPU and GPU, and upgrading the CPU made a world of difference. If you're set on upgrading your GPU, you might want to look at the upcoming 3000 series cards before buying another 1080. The 3070 was announced at $499 for a release in October with over twice the CUDA cores as the 1080 at a TDP of 220W, which is much less than the TDP of two 1080's. Plus it will work even in software that doesn't specifically use dual GPU's.

First if you're editing high bitrate footage from an external HDD make sure that's not the bottleneck. A 7200 RPM drive reads at 120 MB/s, even even two uncompressed 14 bit HD raw streams would go over that. I have a GTX 1080 and use Resolve Studio. Earlier this year I upgraded from an i7 4770 to a Ryzen 3600, and got an enormous performance boost when editing HEVC. So while the decoding is done on the GPU, it's clear that the CPU can bottleneck as well. When I edit 4K H.264 or Raw my 1080 rarely maxes out. Overall I'd be pretty surprised if you need another/a new GPU for basic editing and color grading. Resolve studio is a better investment imo than a second 1080.

What type of editing do you do (VFX, color, etc)? Do you currently use Premiere or Resolve Lite? What parts need performance increases?

@kye Have you done any eyeballing as well? Interesting how ffmpeg's ProRes does better than Resolve's. I expected the opposite, because when I did my test, HEVC was superior to ProRes at a fraction of the bitrate, which doesn't seem to be replicated by your measured SSIM. I wondered if my using ffmpeg to encode ProRes was non-optimal. I didn't take SSIM recordings, and I have since deleted the files, but some of the pictures remain in the topic. From your graph, it seems impossible that HEVC at 1/5 the size of ProRes would have more detail, but that was my result. ProRes, however, kept some of the fine color noise in the VERY shadows, far darker than you can see without an insane luma curve. I wonder if that is enough to make the SSIM drop away for HEVC, as it's essentially discarding color information at a certain luminance? (Linking the topic for reference--in this particular test I used a Blackmagic 4.6k raw file as source so you can reproduce it if Blackmagic still has those files on their site) Good call, I've read that MP4 is better than MOV. Not sure if it's true, but worth checking.

I found that you can set the encoding profile to Main10 or Main10 444, which encodes 10 bit in 420 or 444. No 422 afaik. I only tried H.265, and this was on Windows using Resolve studio.

Makes sense. My questions are partly academic, and partly because I'm doing a lot of animation these days so picking codecs from ffmpeg is an actual part of the process haha.

@kye Yes, your H.264 files are 8 bit. So in your initial run, were all your tests generated using either resolve or ffmpeg using your reference file, or were any made directly from the source footage? 1% of the file size is not remotely true, unless you start with a tiny H.265 file and then render it into ProRes which will increase the size without extra quality. I wouldn't trust much that comes from CineMartin. Of course, the content matters a lot for IPB efficiency. So I guess you might be able to engineer a 1% scenario if your video isn't moving, and you use the worst ProRes encoder that you can find. (Stuff like trees moving in the wind is actually pretty far on the "difficult for IPB" spectrum, though it looks like only about half your frame is that tree). Just btw, in my experience Resolve does a lot better with encoding when you use a preset rather than a defined bitrate. Emphasis, a lot better.

I used 4K raw files, and exported them as uncompressed 10 bit 444 HD files and did all my tests in HD, so yes I downscaled. And that's pretty similar to my workflow, where I always work on an HD timeline using the original files with no transcoding. You can run "ffprobe -i videofile.mp4" and it'll tell you the stream format. There will be a line that goes something like: "Duration: 00:04:56.28, start: 0.000000, bitrate: 20264 kb/s Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 4096x2160 [SAR 1:1 DAR 256:135], 20006 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)" So in my example above is 8 bit 4:2:0. 10 bit 4:2:2 would have yuv422p10le

Great tests! One thing I will say is that when I did my ProRes vs H265 tests, I tested on a >HD Raw file in order to maximize the quality of the reference file, to avoid softness and artifacts from debayering. Additionally, my reference file was 4:4:4 rather than 4:2:2... fwiw. The other thing that would be nice is some files to look at, since while SSIM is great to have it's not the only way to look at compression. Also quick question: Are your H.264/H.265 files 4:2:0 or 4:2:2? 10 bit or 8 bit?

It looks so much better now, so it was indeed the workflow that was causing issues. There's still some noise in low light, but the mushiness is gone and the color has life in it. Also, I'm not sure if you slowed it down before or had a frame rate mismatch, but that opening shot of the front gate used to have jerky and unnatural movement but looks normal now. One thing though is that you've got some over exposure that wasn't present before. You might want to adjust the curves in Resolve, or experiment with the raw settings. The shot of the bust at 0:44 in the original is properly exposed, but that shots at 0:48 of the bust in the new one is blown out. But yeah, definitely looks like it was captured in Raw now, which the first video did not.

Yeah, definitely not an apples to apples. It was just what I had open at the moment.

I played at 1440p and I have to agree, it's very noisy and not sharp. When you watch the version on YouTube, how does it compare to your H265 intermediates? How about to your original MLV files, if you have a way to play those back? I haven't watch any other EOS M footage so I can't say whether this is typical of that camera, but I checked against the XT-3 footage I'm editing right now (which is on a 1080p timeline) and it's night and day the clarity and noise level--not to force a comparison but just to make sure I wasn't going in without an immediate reference. In any case, you've got some great stuff to film and practice on at that museum! Tinkering with ML was always fun.

Those new capsules look fairly interesting. It would be neat if Zoom transitioned to a modular recorder system, without compromising quality, durability and form factor. Being able to just add 4 more XLR's with phantom power, or an ambisonic capsule, is actually pretty cool. They're in a position to make a Zoom F1 sequal that is small enough to be a beltpack recorder, has remote triggering from bluetooth, but can also turn into a recorder with 4-5 XLR inputs when needed. That would be great for people at my budget/skill level who need a swiss army knife for lots of different uses. Since their new capsule can do 4 tracks apparently, it would be nice to see some capsules with, say, two XLRs plus stereo mics, though I don't know how many people would ever use those. I wonder if it's bi-directional? Could they make an output module for live mixing? It seems like they've put some effort into improving their OS as well. Touchscreen control is... not ideal, but moving towards a modern UI with more functionality is a good direction. When they say it's app based, I assume there are no 3rd party apps--but it would be REALLY interesting if they could get a Tentacle Sync app.

@dgvro Resolve can't use AMD hardware acceleration at all on Windows. It just isn't implemented, according to blackmagic forum posts from 2019. So you're stuck with CPU decoding if you're on a Windows system.

The other part of HEVC decoding is that it's not a simple question of whether your GPU supports it. Last year I upgraded my CPU from an i7 4770 to a Ryzen 3600. My GPU remained the same, and yet my HEVC decoding performance in Resolve jumped from barely usable to really smooth. This was editing the same exact project with the same exact files on the same version of Resolve studio. I don't know if it was the CPU, the new motherboard/chipset, whether Resolve just doesn't like 7-year-old systems, or what--but it's certainly false that the GPU is the only factor, even on GPU accelerated performance in Resolve.

I think Intel supports 10 bit 4:2:2 decoding, but I have AMD so I'm not sure. @gt3rs was the one who started our attempts at smooth playback with 4:2:2 files, and I'm not sure if they found anything else about CPU decoding. Fwiw, I don't see any options in Resolve for CPU decoding on my Ryzen 3600, so if it has any they aren't implemented in Resolve. Edit: actually, I did try 1Dx3 4:2:2 files on an 8th gen Intel i7 processor. With QuickSync enabled, the files didn't even show up, and with QuickSync disabled they played at ~10fps. So either Intel doesn't support 4:2:2 on that processor, or Resolve doesn't implement it.

It is true for Nvidia cards, yes.

The pocket is keeping the highlights better, yes. That doesn't necessarily equate to DR because we don't know the distribution, and I do think that the Ursa is better in the underexposure strictly in terms of amount of noise, not that you would use it because the fixed pattern is very unpleasant. But Ursa is also keeping the sharpness in the underexposure just slightly better--though that could be a slightly sharper lens. But of course that's splitting hairs as you wouldn't use either one at that point. If you do any more tests, what I would do is get a gradient of light and ensure that they clip at the same point, and then check the shadows. That would avoid any variables with them distributing DR differently around middle grey, or any discrepancies between what the two cameras use as middle grey to begin with. Maybe I'll do a similar test with my cameras just for fun.

Back when I did a ProRes vs H265 comparison, the only person to actually take a guess pointed out that the ProRes version had significant artifacts compared to H265. So in terms of plain quality, H265 can do very well with most scenes. It broke down a little bit more vs. ProRes HQ on a scene with extreme artifacting--even at very high bitrates, H265 couldn't get to ProRes HQ levels, though it did look favorable compared to ProRes 422 to me. Of course, actual camera footage will vary, so looking forward to your tests. Another test of just the codecs can be done on a Z Cam, which shoots 10 bit H265 and and flavor or Prores, internally. While H265 is harder on the PC, I actually have very little trouble editing it. I'm editing 4K IPB Fuji H265 in a project at the moment. I'm even doing motion tracking and VFX in Fusion, directly on the timeline, plus color grading. I'm not really having any issues with a GTX 1080, Ryzen 3600, 32GB ram. It's not buttery smooth, but it's not holding me back at all for the edit or VFX. The color page is very slow if I have clip thumbnails enabled and am using groups, I guess because every change re-renders all the thumbnails for each clip in the group. Seems like a place Blackmagic could optimize Resolve with some simple tweaks. So I just turn off clip thumbnails and then it's fast again. So yeah, while ProRes is easier to work with and definitely has better compatibility when working with others, H265 isn't bad at all.