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

[kye]

5 hours ago, Jn- said:

Finally! ...

Use this instead ... 

ffprobe -v error -select_streams v:0 -show_entries frame=pict_type -of default=nw=1:nk=1 %1>test.txt

Thank you!

That worked like a charm - unlike the h265 intra encoding, which worked exactly the same as the non-intra encoding.  The SSIM comparison between an intra encode and a non-intra encode revealed an SSIM of 1.000000. 😂😂😂😂

Now to work out how to encode 10-bit intra.  You already need to have a different binary for h265, who knows what support for intra it has, or doesn't have.  The commentary I read was that the h264 and h265 modules have the same arguments, but obviously there are differences.

10 minutes ago, Jay60p said:

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 had previously considered buying a Mac Mini as a desktop and buying a low-spec laptop and the T2 chip caught my eye in that scenario.  I have since realised that although the 13MBP I'm buying is only quad core and the Mac Mini is 6-core, the cores are slower and are only 8th generation (IIRC) whereas the 13MBP are 10th generation and that basically makes up the difference.

I'll be getting the T2 Chip regardless, and combined with my decision to go back to 1080p and use the 200Mbps ALL-I mode on the GH5 it should cut like butter.  The question then becomes how it handles the footage from the Sony X3000 which is 100Mbps h264 IPB, and from my phone, which are h265.  I was wondering if I should render those to Prores HQ 1080 and then grade from there, or to just stick with the original files.  I guess the T2 Chip might mean I keep the originals of those files.  Interesting times.

[Xavier Plagaro Mussard]

Nice post! 

[kye]

Ok, here's the second attempt.....

and graphed:

So, it looks like:

• UHD Prores 422 HQ from Resolve can be matched in quality by ffmpeg h264 422 10-bit ALL-I at around 170Mbps and a similar bitrate for h265 which is about a 4X reduction in file size
• UHD Prores 4444 and 4444 XQ from Resolve can be matched in quality by ffmpeg h264 422 10-bit ALL-I at around 300Mbps and around 250Mbps for h265 which is about a 3-4X reduction in file size
• There doesn't appear to be a huge difference between h264 and h265 all-i efficiencies, maybe only 10-15% reduction

Happy to answer any questions and to have the results challenged.  Let's hope I didn't stuff anything up this time 🙂

[joema]

On 8/15/2020 at 12:36 AM, kye said:

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

On Mac you can use Invisor which also enables spreadsheet-like side-by-side comparison of several codecs. You can also drag/drop additional files from Finder to the comparison window, or select a bunch of files to compare using right-click>Services>Analyze with Invisor. I think it internally uses MediaInfo to get the data. It cannot extract as much as ffprobe or ExifTool but it's much easier to use and usually sufficient.

https://apps.apple.com/us/app/invisor-media-file-inspector/id442947586?mt=12

[kye]

4 hours ago, Jn- said:

Ok Kye, found it "-Intra", kinda obvious🤣.  The difference in IQ between ALL-I and IPB is so small as to not warrant me re doing.

It's a bit more complicated actually, which tripped me up.

You're right that it's "-intra" for h264, but the h265 conversion doesn't accept that - it just ignores it, thus my question.

You want "-x265-params keyint=1" for the h265 conversion.

For example:

Quote

./ffmpeg -i "Codec test REF.mov" -c:v libx265 -x265-params keyint=1 -pix_fmt yuv422p10le -crf 19 -c:a copy "Codec test h265 10bit intra crf 19.mp4" 

You can tell it's working because when you run it, it shows:

Quote

Stream mapping:

  Stream #0:0 -> #0:0 (r210 (native) -> hevc (libx265))

Press [q] to stop, [?] for help

x265 [info]: HEVC encoder version 2.6+49-7219376de42a

x265 [info]: build info [Mac OS X][clang 9.0.0][64 bit] 10bit

x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

x265 [info]: Main 4:2:2 10 Intra profile, Level-5 (Main tier)

x265 [info]: Thread pool created using 4 threads

x265 [info]: Slices                              : 1

x265 [info]: frame threads / pool features       : 2 / wpp(34 rows)

x265 [info]: Coding QT: max CU size, min CU size : 64 / 8

x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra

x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 2

x265 [info]: Keyframe min / max / scenecut / bias: 1 / 1 / 0 / 5.00

x265 [info]: Lookahead / bframes / badapt        : 0 / 0 / 0

x265 [info]: b-pyramid / weightp / weightb       : 0 / 0 / 0

x265 [info]: References / ref-limit  cu / depth  : 1 / on / on

x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 0

x265 [info]: Rate Control / qCompress            : CRF-13.0 / 0.60

x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing

x265 [info]: tools: lslices=8 deblock sao

The comparison command to render the SSIM is:

Quote

./ffmpeg -i "Codec test h264 crf 4.mp4" -i "Codec test REF.mov" -lavfi  "[0:v]settb=AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=AVTB,setpts=PTS-STARTPTS[ref];[main][ref]ssim" -f null -

 

 

10 hours ago, Jn- said:

I appreciate that this isn't your primary focus here, but worth to mention anyway ...
I also did a table (will post later) that attempted to display the Data rate/File size % gain of hevc vs h264, using UHD clips, only IPB, not ALL-I.
I found that although large % gains are available at lower data rates/file sizes that they disappear quickly as the data rates increases.

I didn't look at this specifically (and now I don't have to since you did!) but it makes sense.

In terms of an acquisition format, the question of prores vs h264/5 doesn't really come into question that much if your h264 option is below ~150Mbps, which is where I went down to.  Prores Proxy is 141Mbps and people don't really talk about using that in-camera, so in a sense that's below the conversation about acquisition.

10 hours ago, Jn- said:

Hevc is more efficient at higher resolutions, so the gain may be even better at say 8K.

It should scale perfectly, if you take the approach of bits-per-pixel.

Prores bitrates for UHD are exactly 4x that for FHD.  Thus, I would assume that you can simply translate the equivalences.

I might do a few FHD tests just to check that logic, but I can't see why it wouldn't be true.

I have two remaining questions:

• How do I get Resolve to export better h264, for upload to YT
• Is Resolves Prores export that good?  The h264 outputs didn't seem to be anywhere near ffmpeg, so maybe the Prores export is weak too?

 

On 8/13/2020 at 9:45 PM, KnightsFan said:

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'll have to return to this and investigate further.

I wonder if there's a way I can configure it to be better than 420 and 8-bit too.

[KnightsFan]

8 minutes ago, kye said:

I'll have to return to this and investigate further.

I wonder if there's a way I can configure it to be better than 420 and 8-bit too.

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.

[kye]

Here's the table sorted by SSIM:

and a closer look at the h264/5 corner:

[kye]

Just found out that ffmpeg can encode to Prores.  

The tests continue!

[kye]

Prores from ffmpeg is significantly different - different bitrates and performance.

Obviously this is rabbit hole I'm going to be falling down for a while!

[joema]

On 8/14/2020 at 8:59 PM, 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)...

I can confirm a top-spec 2019 MBP 16 using Resolve Studio 16.2.5 has greatly improved playback performance on 400 mbps UHD 4k/29.97 10-bit 4:2:2 All-Intra material from a Panasonic GH5, whereas FCPX 10.4.8 and Catalina 10.15.6 on the same hardware is much slower. 

Also Resolve export of UHD 4k 10-bit HEVC is very fast on that platform, whereas FCPX 10.4.8 is very slow (for 10-bit HEVC export, 8-bit is OK). In these two cases for some reason FCPX is not using hardware acceleration properly but Resolve is. This only changed in fairly recent versions of Resolve, and I expect the next version of FCPX will be similarly improved.

Beyond those codecs it seems the latest 2020 iMac 27 has improved hardware acceleration for some codecs. Of course this will vary based on whether the NLE leverages this, as shown above. Max Yuryev will probably post those results next week. This may be due to the Radeon Pro 5700 XT having AMD's new VCN acceleration logic. VCN is the successor to VCE. It's a confusing area since there are three separate acceleration hardware blocks: Intel's Quick Sync, Apple's T2 and AMD's UVD/VCE (and now VCN). The apps apparently just call the MacOS VideoToolBox framework and request acceleration. Why that works on Resolve 16.2.5 and not FCPX 10.4.8 for the above two cases is unknown.

[kye]

2 hours ago, joema said:

I can confirm a top-spec 2019 MBP 16 using Resolve Studio 16.2.5 has greatly improved playback performance on 400 mbps UHD 4k/29.97 10-bit 4:2:2 All-Intra material from a Panasonic GH5, whereas FCPX 10.4.8 and Catalina 10.15.6 on the same hardware is much slower. 

Also Resolve export of UHD 4k 10-bit HEVC is very fast on that platform, whereas FCPX 10.4.8 is very slow (for 10-bit HEVC export, 8-bit is OK). In these two cases for some reason FCPX is not using hardware acceleration properly but Resolve is. This only changed in fairly recent versions of Resolve, and I expect the next version of FCPX will be similarly improved.

Beyond those codecs it seems the latest 2020 iMac 27 has improved hardware acceleration for some codecs. Of course this will vary based on whether the NLE leverages this, as shown above. Max Yuryev will probably post those results next week. This may be due to the Radeon Pro 5700 XT having AMD's new VCN acceleration logic. VCN is the successor to VCE. It's a confusing area since there are three separate acceleration hardware blocks: Intel's Quick Sync, Apple's T2 and AMD's UVD/VCE (and now VCN). The apps apparently just call the MacOS VideoToolBox framework and request acceleration. Why that works on Resolve 16.2.5 and not FCPX 10.4.8 for the above two cases is unknown.

Compared to my current machine, the spec I'm looking at will be 2.6x as powerful, and that's CPU alone.  Benchmarks for the GPU will be almost double.  

That's before we get to the T2 Chip which the new one will have over this one.  Then if I decide to upgrade my eGPU, well....

13 hours ago, KnightsFan said:

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.

Exporting some trials now.  It occurs to me that the previous way I was exporting was Quicktime -> h264 so I'm trying MP4 -> h264 which has more arguments.  

On OSX and my dated Resolve I only have encoding profiles of Auto, Base, Main, and High.  I also have multi-pass mode, so I've queued up a few combinations of those.

Slowly but surely...

[KnightsFan]

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

 

5 minutes ago, kye said:

Exporting some trials now.  It occurs to me that the previous way I was exporting was Quicktime -> h264 so I'm trying MP4 -> h264 which has more arguments.  

Good call, I've read that MP4 is better than MOV. Not sure if it's true, but worth checking.

[kye]

Couldn't get much difference from Resolve using different settings:

[kye]

FHD tests, mostly complete:

Graphed:

Basically, similar to UHD.

[kye]

FHD H264 ALL-I at around 221Mbps:

FHD Prores at around 218Mbps:

[TimmiS]

3 hours ago, kye said:

FHD H264 ALL-I at around 221Mbps:

FHD Prores at around 218Mbps:

Based on that I’d conclude that it comes down to the quality of the eye rather than the quality of the camera.

[kye]

21 hours ago, TimmiS said:

Based on that I’d conclude that it comes down to the quality of the eye rather than the quality of the camera.

True, but with the caveat that it's comparing Prores with h264 221Mbps 10-bit 422 ALL-I.

Not many cameras can shoot that, even in FHD!

[kye]

13 hours ago, Geoff CB said:

This is what I have been doing recently, clients really like it because they can watch and download in one spot. Also it's doesn't take up space like dropbox/google drive or expire like wetransfer.

My usual process:
1) Export a DNxHR 12-bit 4:4:4 file  in Resolve
2) Handbrake to create a H265 10-bit 4:4:4 file that I set on slow render speed for very high quality at a lower bitrate
3) Upload to Vimeo

If I have a DCP delivery for a short film/trailer I use the DNxHR file and run it through DCP-O-MATIC.

Of course some clients I know don't care about resolution or image quality that much, for that I just export using the Vimeo preset in Resolve. 

I quoted you here from the other thread (to keep things tidy and on-topic) to ask you about using the "slow" setting you mention above.

I tried a slow encode in one of my above tests and found it to have an insignificant difference in IQ compared to the normal setting.  Have you compared the two settings directly?   I do recall the "slow" setting was dramatically slower though!