@Tom
I share many of your points (e.g. h265 is more effecient than 264), but it seems hard to explain my point about 'broadcast vs sharing codec':
there's actually no consumer device delivering h265; there's - aside tellies… latest ones - no hardware support for h265, camcorders, photos, phones, laptops, tablets, desktops. So, who is interesting in encoding to h265? What I call 'broadcasters', not in traditional meaning (aerial, BBC) but 'commercial mass deliverers' - netflix/amazon/… , and, actually, YT (which own their own HVCcodec)
but all those 'broadcasters' HAVE to deliver multi-standard = adaptive, because of bandwith (who's able to watch 4k-streams at primetime? that's a very narrow and priviledged group), device (my TV doesn't offer 4k …), usage (4k on handleds ...). So, as a content maker, there's little reason&need to upload in h265 - they will convert it anyhow.
And if I want to share 4k, I can use ye ol h264 anyhow. My 4k cam records in h264 ... converting to h265 would save 20% upload, then YT converts it back to h264 for most of my audience = loss of quality (the pixelpeepers upload in proRes anyhow).
… getting lengthy again, sorry …
aside trouble with patents, money and politics, there's very little need to install h265-encoding ... yet.
and de-coding either.
hen vs egg - as long h265 doesn't get hardwired on consumer chips, I don't see h265 as an 'sharing' option. (or you operate your own server ... 😉 )
for an export option, in the Apple-ecosphere it's a business opportunity for a plug-in maker (reminds me of the story with Hamburg Pro Media/MXF support etc)
…
PS: concerning LJ, I was reflecting on that
https://larryjordan.com/articles/adobe-media-encoder-and-h-265-not-ready-for-pri me-time/
but missed his update which 'fixes' a few of his concerns ....
PPS: btw that's a very refreshing and 'mature' discussion! … compared to the crusades on some other boards .... 😀