Prores vs h264 vs h265 and IPB vs ALL-I... How good are they actually?

[kye]

Some cameras shoot RAW and Prores, and some shoot h264 and a few shoot h265.  There's lots of bitrates on offer too, 50Mbps, 100Mbps, etc.  Some are ALL-I and some are IPB.

But how good are they?

I couldn't find any comparisons, so I did some myself.

What I did was take a few shots from the BM Micro Cinema Camera shot in uncompressed RAW of a tree moving in the wind, and made a single UHD frame by putting them in each corner, like this:

Also, they were of different lengths, so I just repeated each one, like this:

So we have a test clip that was shot RAW (maybe compressing already compressed footage is easier?  I don't know, anyway..), that includes decent movement but isn't some stupid test case that means nothing in real life, that doesn't repeat (because the clips are different lengths), and has some deliberately almost crushed blacks to test the pixelation that h264 and h265 sometimes get in the shadows.

Then I exported an uncompressed 10-bit 422 YUV file to use as a reference.  After some tests and seeing the file sizes and processing times, I decided to only use the first 12s of the timeline.

Then I rendered a bunch of clips, either h264 from Resolve, or h264 and h265 from ffmpeg.  I tried rendering h265 from Resolve but had issues, and in this test all the maximum bitrates I tried all created the same size file, so I abandoned that.  Common wisdom online is that Resolves h265 export mechanism isn't the best and you should use ffmpeg anyway.

Then I compared the compressed clips with the uncompressed reference file, which gives a score called SSIM, which goes from 1 (a perfect match) downwards.

Here's the results so far:

Here are some observations / thoughts, and some answers to some questions I'd had:

• In Resolve, H264 seems to top out, as I couldn't get it to export at more than about 400Mbps IPB, but ffmpeg went higher than that quite happily
• ALL-I h264 doesn't seem to be that different than IPB, at higher bitrates anyway - slightly lower quality and slightly higher file size, but not the 3x I've read around the place
• Prores isn't that much worse in terms of quality vs compression than h264 or h265, despite being an older codec (although maybe there are versions?  I have no idea how prores works.. maybe that's important for this topic?)
• Different encoders have different levels of quality, so what's in a given camera is likely to differ from these results

I guess the real question is, how much h264 do you have to have to equate to Prores?  The answer seems to be "about the same bitrate, but probably a little less for an ALL-I codec, and a little less bitrate again if it's an IPB".

[kye]

In terms of the GH5, it means that:

• the 1080p 10-bit 422 200Mbps ALL-I mode is likely to be roughly equivalent to 1080p Prores HQ which is 176Mbps
• the UHD 10-bit 422 400Mbps ALL-I mode is likely to be roughly equivalent to UHD Prores 422 which is 471Mbps

Not bad at all.

[herein2020]

6 minutes ago, kye said:

In terms of the GH5, it means that:

• the 1080p 10-bit 422 200Mbps ALL-I mode is likely to be roughly equivalent to 1080p Prores HQ which is 176Mbps
• the UHD 10-bit 422 400Mbps ALL-I mode is likely to be roughly equivalent to UHD Prores 422 which is 471Mbps

Not bad at all.

I think the biggest difference for most of these codecs is how easy or hard it is on your CPU and GPU when editing. I think with any of these compression codecs if you turn up the bitrate high enough or reduce the compression ratio far enough they will eventually all look the same, but when you are editing them in post your CPU, GPU, and NLE will definitely be affected by how much information is missing between frames.

 

I would also imagine the quality differences would be more apparent when a lot of things change between frames. For example, I live in FL, and frequently film drone footage over water.....H.264 completely falls apart when water is involved especially waterfalls because no two frames are alike. I would imagine in that scenario ALL-I would be better but I have not tested it. Timelapses are another place where I've seen YouTube completely destroy my footage. If there is too much motion in the timelapse it turns into a blocky mess on YouTube.

[kye]

48 minutes ago, herein2020 said:

I think the biggest difference for most of these codecs is how easy or hard it is on your CPU and GPU when editing. I think with any of these compression codecs if you turn up the bitrate high enough or reduce the compression ratio far enough they will eventually all look the same, but when you are editing them in post your CPU, GPU, and NLE will definitely be affected by how much information is missing between frames.

 

I would also imagine the quality differences would be more apparent when a lot of things change between frames. For example, I live in FL, and frequently film drone footage over water.....H.264 completely falls apart when water is involved especially waterfalls because no two frames are alike. I would imagine in that scenario ALL-I would be better but I have not tested it. Timelapses are another place where I've seen YouTube completely destroy my footage. If there is too much motion in the timelapse it turns into a blocky mess on YouTube.

Normally these codecs are discussed in terms of digital intermediaries, or delivery formats, but in todays cameras they are acquisition formats.  It doesn't matter what I think about Prores or h264, my GH5 won't grow Prores support regardless of how much I like it, so this investigation was to answer the question about how bad it is to have h264 instead of Prores support in your camera.

The file, which I realise I haven't shared, has a lot of very complex motion in it, and is high-resolution, so combined with a test that is relative, comparisons should be able to be made.  The SSIM is a mathematical function, not a perception-based one, so it makes it possible to compare very very high-quality files.

YT is a different story altogether and only offers a tiny tiny percentage of the bitrates we're talking about here.  If you're only interested in YT quality, shoot in 50Mbps and be done with it!

[kye]

Here's the graph of what I've done so far:

I haven't done any h265 all-i tests yet, although I'm not sure if there are any cameras that use this?

I'll also do Prores 4444 and 4444 XQ for completion, assuming Resolve has them.

I guess the only news is that h265 is better than h264 or Prores, but it's not 2x better, at least not at this end of the curve.  We're in serious bitrate territory here, so not what these h26x codecs were designed to do.

Let me know if there's anything else you want me to test while I'm setup for it.

[KnightsFan]

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?

[kye]

15 minutes ago, KnightsFan said:

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?

Any RAW file will require de-bayering in order to compare to anything else.  The only way to avoid softness from de-bayering is to downscale.  

This isn't a completely pure stress-test, but neither is real footage.  Most lenses aren't pixel sharp, and our love of bokeh, motion blur and camera stabilisation of any kind ensures that much of the image is blurry and doesn't move that much from frame to frame.  I have done stress testing of codecs before but it makes it more of a theoretical exercise rather than a practical real-world test.

How can I tell if the files are 420 or 422? I haven't got Resolve handy right now, but VLC gives me some info:

Is it the decoded format line I'm interested in?  I'm skeptical as I really want the encoded format, not the decoded format, but maybe it's just badly labelled?

I'd share the files, but the source files are currently up to 22Gb, so would take forever to upload and basically no-one would download them.  I've done things like this in the past and the download counter just sits there after a week of uploading at my end.

[KnightsFan]

1 minute ago, kye said:

Any RAW file will require de-bayering in order to compare to anything else.  The only way to avoid softness from de-bayering is to downscale.  

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

[kye]

7 hours ago, KnightsFan said:

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

Thanks.

• Reference file is "Uncompressed YUV 422 10-bit"
• Prores files from Resolve are "yuv422p10le"
• h265 IPB are "yuv422p10le"
• h264 from ffmpeg are "yuv422p"
• h264 intra from ffmpeg are "yuv422p"
• h264 from Resolve are "yuv420p"

I'm guessing then that the h264 are all 8-bit?  and it looks like Resolve outputs h264 as 420, but ffmpeg as 422?

Makes sense that you downscaled to match your workflow.  I didn't, but considering that we're comparing cameras that have UHD Prores HQ with ones that have UHD 400Mbps 422 10-bit h264 All-I with ones that have UHD 100Mbps 420 8-bit h264 IPB, it seems a reasonable comparison.

For me this comparison is the missing piece of the puzzle, as when you buy a camera you're seldom presented with the option of shooting Prores or h264 as cameras typically choose one or the other.

My motivation was really to work out how good the GH5 modes are.  People say "I shot a feature film that premiered at Cannes in 1080p Prores HQ" but what does that actually mean?  

For example, Cinemartin claimed that h265 is 100x as efficient as Prores 4444 (which Andrew reported on here along with some other new outlets, presumably before anyone could get their hands on it to actually check).  According to this excellent resource at frame.io Prores 4444 HD is 264Mbps and UHD is 1061Mbps.

If the above claim was true then h265 at 2.7Mbps for HD or 11Mbps for UHD would be better than Hollywood master files.  

Does that sound even remotely plausible?  Why would people be talking about bitrate?  My phone records at many times that rate!  The image quality obviously doesn't bear this out, but unfortunately if you google "h265 Prores" you don't really get much else, so that's why I was motivated to do this test myself.

[kye]

I just rendered a Prores 4444 and a Prores 4444 XQ from Resolve and while the file sizes are much larger, they get a lower SSIM score than Prores HQ.

Any ideas why that might happen?

They're not radically lower, so I don't think that I've stuffed it up or that there's a technical error somewhere.  

[cpc]

53 minutes ago, kye said:

I just rendered a Prores 4444 and a Prores 4444 XQ from Resolve and while the file sizes are much larger, they get a lower SSIM score than Prores HQ.

Any ideas why that might happen?

They're not radically lower, so I don't think that I've stuffed it up or that there's a technical error somewhere.  

Your "uncompressed reference" has lost information, that the 4:4:4 codecs are taking into consideration, hence the difference.

You should use uncompressed RGB for reference, not YUV, and certainly not 4:2:2 subsampled. Remember, 4:2:2 subsampling is a form of compression.

[kye]

2 hours ago, cpc said:

Your "uncompressed reference" has lost information, that the 4:4:4 codecs are taking into consideration, hence the difference.

You should use uncompressed RGB for reference, not YUV, and certainly not 4:2:2 subsampled. Remember, 4:2:2 subsampling is a form of compression.

That makes sense.  Rendering a new reference file now.

I'll test a few of the other ones I did before to see if they score differently.

[KnightsFan]

@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.

[KnightsFan]

5 hours ago, kye said:

My motivation was really to work out how good the GH5 modes are.  People say "I shot a feature film that premiered at Cannes in 1080p Prores HQ" but what does that actually mean?

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]

8 hours ago, KnightsFan said:

@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.

In my initial run the Resolve ones were from the original timeline, but all the ffmpeg ones were from my 422 reference file, which I have now replaced with a real reference file.  I'll start re-running the conversions again.

I'm thinking I'll do h264 IPB, h264 ALL-I, h265 IPB, h265 ALL-I, all in 10-bit to begin with.

The 1% of file size seemed fishy, but there isn't much out there, and people do a lot of comparing h264 and h265 but not against Prores.

8 hours ago, KnightsFan said:

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.

Considering how good ffmpeg is compared to Resolve I'm now wondering if I should export a high quality file from Resolve and then use ffmpeg to make the smaller one.  Of course, I publish to YT so probably not, though.

[joema]

On 8/12/2020 at 7:04 AM, kye said:

...I guess the real question is, how much h264 do you have to have to equate to Prores?  The answer seems to be "about the same bitrate, but probably a little less for an ALL-I codec, and a little less bitrate again if it's an IPB".

Most commonly H264 is 8-bit Long GOP, sometimes called IBP.  This may date to the original H264 standard, but you can also have All-Intra H264 and/or 10-bit H264, it's just less common.

I don't have the references at hand but if you crank up the bit rate sufficiently, H264 10-bit can produce very good quality, I think even the IBP variant. The problem is by that point you're burning so much data that you may as well use ProRes.

In post production there can be huge differences in hardware-accelerated decode and encode performance between various flavors of a given general type. E.g, the 300 mbps UHD 4k/29.97 10-bit 4:2:2 All-Intra material from a Canon XC15 was very fast and smooth in FCPX on a 2015 iMac 27 when I tested it, but similar material from a Panasonic GH5 or S1 were very sluggish. Even on a specific hardware and OS platform, a mere NLE update can make a big difference. E.g, Resolve has had some big improvements on certain "difficult" codecs, even within the past few months, at least on Mac.

Since HEVC is a newer codec, it seems that 10-bit versions are more common than H264 (especially as an NLE export format), but maybe that's only my impression. I think Youtube and Vimeo will accept and process 10-bit Long GOP HEVC OK, I tend to doubt they'd accept 10-bit All-Intra H264. There are some cameras that do 10-bit All-Intra HEVC such as the Fuji X-T3. I think some of these clips include that format https://www.imaging-resource.com/PRODS/fuji-x-t3/fuji-x-t3VIDEO.HTM

But there's a lot more involved than just perceptual quality, data rate or file size. Once you expand post production beyond a very small group, you have an entire ecosystem that tends to be reliant on a certain codec; DNxHD or ProRes are good examples. It almost doesn't matter if another codec is a little smaller or very slightly different in perceptual quality on certain scene types, or can accommodate a few more transcode cycles with slightly less generational loss. Current codecs like DNxHD and ProRes work very well, are widely supported and not tied to any specific hardware manufacturer. 

There's also ease of use in post production. Can the codec be played with common utilities or does it require a special player just to examine the material? If a camera codec, is it a tree-like hierarchical structure or is it a simple flat file with all needed metadata in the single file?

Testing perceptual quality on codecs is a very laborious  complex process, so thanks for spending time on this and posting your results. Each codec variant may react differently to certain scene types. E.g, one might do well on trees but not water or fireworks. Below are some scenes used in academic research. 

https://media.xiph.org/video/derf/
http://medialab.sjtu.edu.cn/web4k/index.html

http://ultravideo.cs.tut.fi/#testsequences

[noone]

On 8/13/2020 at 9:33 AM, kye said:

 

.I haven't done any h265 all-i tests yet, although I'm not sure if there are any cameras that use this?

 

Canon R5 8k 

DCI all I and UHD all I both 10 bit in log and 8 bit in standard profiles.

This is all WAAAAYY above me though.

[kye]

10 hours ago, joema said:

Most commonly H264 is 8-bit Long GOP, sometimes called IBP.  This may date to the original H264 standard, but you can also have All-Intra H264 and/or 10-bit H264, it's just less common.

I don't have the references at hand but if you crank up the bit rate sufficiently, H264 10-bit can produce very good quality, I think even the IBP variant. The problem is by that point you're burning so much data that you may as well use ProRes.

You're right, assuming you're talking about using these things as intermediaries, but if you've got a camera that doesn't have Prores (like most prosumer cameras) then you don't have that choice.  
OR, you do have that choice, but the option involves adding an external recorder for many hundreds of dollars, plus all the extra size, weight, and complexity of additional battery types, chargers, etc.

With things like the P4K/P6K and others making Prores more affordable now, I suspect that many will be tempted towards one camera or other because "Prores is a professional format and h26x is a consumer / delivery format" but I wanted to test if that really did matter.

After all, the only comparisons I could find were that h265 was 100x better than Prores 4444, which is obviously ridiculous.

10 hours ago, joema said:

In post production there can be huge differences in hardware-accelerated decode and encode performance between various flavors of a given general type. E.g, the 300 mbps UHD 4k/29.97 10-bit 4:2:2 All-Intra material from a Canon XC15 was very fast and smooth in FCPX on a 2015 iMac 27 when I tested it, but similar material from a Panasonic GH5 or S1 were very sluggish. Even on a specific hardware and OS platform, a mere NLE update can make a big difference. E.g, Resolve has had some big improvements on certain "difficult" codecs, even within the past few months, at least on Mac.

I'm about to update my ageing MBP and am looking forward to the better h265 support that will come with a new OSX and latest Resolve (I can't upgrade Resolve until I update OSX and there's a limit to how new your OSX version can be on a given hardware setup, so I'm kind of stuck in the mud until I upgrade my hardware).

10 hours ago, joema said:

Since HEVC is a newer codec, it seems that 10-bit versions are more common than H264 (especially as an NLE export format), but maybe that's only my impression. I think Youtube and Vimeo will accept and process 10-bit Long GOP HEVC OK, I tend to doubt they'd accept 10-bit All-Intra H264.

I just uploaded a test file to YT right now.  H264 10-bit All-I.  Worked just fine.

ffprobe reports:

Quote

Stream #0:0(und): Video: h264 (High 4:2:2 Intra) (avc1 / 0x31637661), yuv422p10le, 3840x2160 [SAR 1:1 DAR 16:9], 118438 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)

I've found YT to be pretty good with input file formats.

10 hours ago, joema said:

But there's a lot more involved than just perceptual quality, data rate or file size. Once you expand post production beyond a very small group, you have an entire ecosystem that tends to be reliant on a certain codec; DNxHD or ProRes are good examples. It almost doesn't matter if another codec is a little smaller or very slightly different in perceptual quality on certain scene types, or can accommodate a few more transcode cycles with slightly less generational loss. Current codecs like DNxHD and ProRes work very well, are widely supported and not tied to any specific hardware manufacturer. 

There's also ease of use in post production. Can the codec be played with common utilities or does it require a special player just to examine the material? If a camera codec, is it a tree-like hierarchical structure or is it a simple flat file with all needed metadata in the single file?

Absolutely.  I wouldn't advocate for h264/h265 as intermediaries at all.  

DON'T DO IT KIDS!! 😂😂😂

10 hours ago, joema said:

Testing perceptual quality on codecs is a very laborious  complex process, so thanks for spending time on this and posting your results. Each codec variant may react differently to certain scene types. E.g, one might do well on trees but not water or fireworks. Below are some scenes used in academic research. 

https://media.xiph.org/video/derf/
http://medialab.sjtu.edu.cn/web4k/index.html

http://ultravideo.cs.tut.fi/#testsequences

No worries.  Personally, I find that doing a few hours / days of testing is far more effective than doing hours / days googling (which often does not lead to the truth) or, worse still, is hanging out online and hearing from people that just repeat misinformation and you end up making a bad decision that either wastes many hundreds / thousands of dollars or means you have to deal with lower quality footage for months / years until you realise that you were mislead.

I've wasted thousands on equipment I don't use and also spent years shooting with bad settings or flat-out with the wrong equipment because of misinformation gathered online - even from EOSHD, although it's definitely been better than average for camera forums.  

I also finding that posting the results forces me to do everything properly as I will be explaining it, and it's a bit embarrassing if you get something wrong, so that's motivating too!

Of course, I stuffed up my reference file above, and am re-rendering and re-evaluating all the modes again...  such is life and learning 🙂

I'd really like to be doing perceptual quality testing, as we look at our footage with our eyes and brain, not our statistical analysis software, but typically this involves having massive double-blind tests, which are beyond my ability to perform, so I leverage off of metrics like SSIM, which are reliable and repeatable and comparable.  

Does Prores at a given SSIM have a different feel than h264 at the same SSIM - you'd imagine so.  

At this point I'm still very satisfied with my testing though, as at least I have some idea now of what is what.

5 hours ago, noone said:

Canon R5 8k 

DCI all I and UHD all I both 10 bit in log and 8 bit in standard profiles.

I would imagine that cameras would increasingly offer h265 10-bit ALL-I codecs, and I think that's a good move.

h265 is better than h264 (more efficient, giving either better quality at identical bitrates or same quality at lower bitrates) and ALL-I formats render movement nicer and are dramatically easier to deal with in post.

One thing I am very conscious of is that you can go two routes for your workflow.

The first is to render high quality intermediaries and abandon your SOOC files.  For this you'll typically choose a friendly ALL-I codec, which trades decoding load for high data volumes, requiring an investment in large and fast storage.
You will edit and grade and render from these intermediaries.

The second is to render low quality intermediaries, which you can use for editing, but then revert back to the SOOC files for grading and rendering.  
This is my workflow and I use 720p "Prores Proxy" which cuts like butter on my ageing MBP and also fits neatly on the internal SSD for editing on the go.

The challenge with the second workflow is that you can't really grade on the proxy files, and you definitely can't do things like post-stabilisation or even smooth tracking of power windows.  This means that you're back to the SOOC files for grading and which means that you can't play the graded footage in real-time.
This compromise is acceptable for me, but not for professional people who will have a client attend a grading session where they will ask for changes to be made and won't want to wait for a clip to be re-rendered before being able to view it.

Having SOOC footage that's ALL-I significantly helps with performance of grading from SOOC footage, but it's why professional colourists have five-figure (or even six-figure) computer setups in a sound-proof cupboard and run looooong USB and HDMI cables out to their grading suite.
Anyone who balks at the cost of the Mac Pro for example has never seen someone do complex colour grades with many tracked windows on 8K footage live in front of a client.

6 hours ago, noone said:

This is all WAAAAYY above me though.

Anything that cannot be explained simply isn't sufficiently understood.

I'll get there, I promise 🙂 

[kye]

Does anyone know how to confirm that my h265 files are ALL-I?

On the h264 files the ALL-I ones have this from ffprobe:

"Stream #0:0(und): Video: h264 (High 4:2:2 Intra) (avc1 / 0x31637661), yuv422p10le, 3840x2160 [SAR 1:1 DAR 16:9], 745951 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)"

and the h264 IPB have:

"Stream #0:0(und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le, 3840x2160 [SAR 1:1 DAR 16:9], 860083 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)"

but the h265 files I rendered with -intra as an argument have this:

"Stream #0:0(und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 350312 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 23.98 tbc (default)

which seems to suggest they're progressive, but I definitely used the -intra flag. I even converted another one and changed the order of the arguments in case that was stuffing things up.

[Jay60p]

23 hours ago, kye said:

I'm about to update my ageing MBP and am looking forward to the better h265 support that will come with a new OSX and latest Resolve (I can't upgrade Resolve until I update OSX and there's a limit to how new your OSX version can be on a given hardware setup, so I'm kind of stuck in the mud until I upgrade my hardware).

This is what's been working for me for a year and a half, and it's cheap.

I have the i5 Mac Mini 2018 for $1000. I have both OSX Mojave (for some older apps) and OSX Catalina (for FCPX and editing Fuji files) installed on the internal SSD on two separate volumes, selectable from the keyboard on startup. I can also boot up from OSX on my external drives.

I also have Windows installed with Parallels for some unique utilities (for processing 3d stereo pairs, unusual audio conversions, etc).

So far I have only needed the 8GB memory it came with, FCPX edits the 4K60 10bit HEVC from my X-T3 smoothly with no problems in OSX Catalina. I haven't tried Resolve, that requires 16GB.

I have never needed to use an intermediary so far, doing mostly single track editing without any heavy special effects.

I believe the reason I can do this is due to the T2 chip in the Mini, which does HEVC acceleration (besides the Security features).

I can play 4K60 10bit HEVC LongGOP at full resolution at full speed from Quicktime Player.

Inside FCPX the same files always play smoothly in the viewer's "better performance" mode.

I edit straight from my camera files, render a master to ProRes, then compress to MP4 HEVC in Handbrake.

I usually display the final Handbrake 10bit 4K HEVC files with a 256GB flashdrive that my 2017 Sony TV can play smoothly with its own internal android software.

 

Computers that have the Apple T2 Security Chip

These Mac computers have the Apple T2 Security Chip:

iMac introduced in 2020

iMac Pro

Mac Pro introduced in 2019

Mac mini introduced in 2018

MacBook Air introduced in 2018 or later

MacBook Pro introduced in 2018 or later

(from https://support.apple.com/en-gb/HT208862)