[popcornmix]

Obviously I have made arm_freq and sdram_freq as high as reasonable, without becoming unreliable.
My undersanding is that core_freq influences memory access speed/bandwith, which is useful for H.265, however you are also using the GPU for decoding, so presumably that also needs to be as high as reasonable.
However core_freq and gpu_freq may be set differently, in the ratio 3 to 2 (usually because the gpu won't clock as fast as the core), however I have seen several people, like Milhouse above, using the same frequency for both, whereas I tend to use as high an overclock for core as is reliable (best memory bandwith), then set gpu at 2/3 of that ie 564 & 376 (I realise there are restrictions on the devisors allowed)
So my question is for H.265/HEVC is it better to get the core up as high as possible and so probably have to accept a slower gpu, as I currently do, or to set them both to the same, as high as reliable, as Milhouse example above, or is there basically nothing in it?

gpu_freq isn't a specific clock but is a shorthand for setting core_freq, v3d_freq, h264_freq and isp_freq (if otherwise not set).
These days there are separate PLLs for core_freq and the other 3. So core_freq can be set arbitrarily compared to v3d_freq/h264_freq/isp_freq.
v3d_freq/h264_freq/isp_freq need to all be integer divisors of the PLL. The simplest option is to set them all the same.

For HEVC, the sdram, arm, core and v3d are the important clocks (roughly in that order, but they are all significant).

In Milhouse's config.txt the core_freq line is redundant (it defaults to gpu_freq if otherwise unspecified).
But it would work perfectly fine with, say core_freq=513, as core_freq has its own PLL.

However:
gpu_freq=500
v3d_freq=513

wouldn't be satisfied exactly as v3d shares a PLL with h264/isp. I think you would get 513 for all 3 clocks.