[shadow]

It depends on many factors, but I can play ~10Mbit/s 1080p HEVC on overclocked Pi3 with no drops, which is very good quality.

Code:

arm_freq=1300
gpu_freq=500
over_voltage=4
core_freq=500
sdram_freq=600
over_voltage_sdram=5
sdram_schmoo=0x02000020
force_turbo=1

I just got my Raspberry Pi 3 today and I'm trying to play some 1080p HEVC video and the drop counter is constantly counting up. Am I unlucky? I was not expecting to get the 10Mbits you said you played that consistently but I'm getting drops on stuff it should be able to play

A couple videos I tested included a 720p that was dropping frames at only ~1.4 Mbits (shown by Kodi's codec info live at the time of the drops)

I have some 1080p that was un-watchable at a average of 2.5 Mbits and drops even at 1.2.


I have the Pi plugged in using a 3 amp power supply with a fixed cable for less loss (circuit test brand)
Currently no case or heatsinks (just haven't got them yet)

For heat issues I tested it at stock and it would hover around 80 degrees then just for the sake of testing I grabbed a high power 2 foot floor fan and pointed it at the Pi and ignoring the noise that makes it louder then my sound system. That brought the temperature when playing HEVC down to ~50 degrees

Even at the lower temperature it is still dropping .

I'm on a fully updated OSMC install using the Kodi 17 test builds which should have the most current HEVC patches. I of course copied the over clock settings quoted in this post.

Would samples help? I'll try to get some ready.

[Milhouse]

Would samples help? I'll try to get some ready.

Yes. As would the mediainfo for the samples as it may be obvious from that information what the problem is without even downloading the samples - for instance 10-bit video is not supported.

[shadow]

Here is a 1 minute sample cut using ffmpeg

sample http://s000.tinyupload.com/?file_id=9703...6597011541
media info http://pastebin.com/G1D2tqtB

[nooryani84]

I didn't think HEVC would be supported for RPi3, more of a "YMMV"/best effort. Either way, I suspect a heatsink is mandatory for HEVC to work reliably.

[shadow]

I didn't think HEVC would be supported for RPi3, more of a "YMMV"/best effort. Either way, I suspect a heatsink is mandatory for HEVC to work reliably.

I know that but this stuff was just above the Pi 2's abilities and like I mentioned I wasn't expecting to hit the high end of popcornmix's tests all the time. But this fraction of it I was hoping. I do have heat sinks on the way but was hoping the two foot fan would be a stop gap which at a 30 degree drop shows heat is not the problem.

[nooryani84]

The RPi3 draws more power and runs hotter than the RPi2 by default, so I'm not so surpised. I wouldn't be so sure if it will work reliably even with a heatsink. 720p may work fine, but you also have to take the bitrate into consideration. Adding fans, heatsinks etc will increase the total cost of your RPi - you may want to look into something designed for HEVC.

[popcornmix]

Here is a sample HEVC file which should play on Pi3 with Nightly (e.g. Krypton builds).
It will probably play with OSMC stable, but note that doesn't include all the HEVC optimisations somepared to nightly builds.

Does it play okay for you?

[Vimes]

All the 720p x265 files that I have seem fine with no issues. Going to 1080p x265 can be hit and miss but I suppose bitrate and other factors will determine just how good it is going to be on the Pi 3. I found that the nightly Krypton builds to be the best for the smoothest experience. But sometimes I still get the overheat warning square coming up as the temp goes beyond 85c, then video corruption etc occurs. I have a heatsink on the Pi 3 but no fan. Overclock the same as the OP. I'm not too bothered about investing more to enable the Pi to run cooler as yet - for me the point of the Pi in its location was small, cheap and quiet.

I am just amazed that it can cope at all, thanks of course for the extra bits that help with the playback in the Krypton builds, with any HEVC encoded material. I remember when x264 started to appear around 2008 the savings gained in storage for the quality of the encodes were amazing and perhaps HEVC has similar potential to improve on that.



EDIT: Just tried that file from popcornmix and it plays perfectly well with no stutters etc on the Pi 3

[shadow]

I tested that sample file quite a few times and it's more of what I was expecting from the Pi 3.

It does still drop some frames, on some runs it will drop 4-9 frames at the short bit where the bitrate jumps over 9 Mbits and on some worse runs with a total loss over the clip being around 30.

That is way more reasonable then my minute clip at a fraction of the bitrate losing over 300 frames

It must be some encoding setting on the videos that the Pi doesn't like. Hopefully you can take my sample and find a way to make it work, obviously the Pi 3 should be capable.

[Milhouse]

I'm testing the HEVC sample from popcornmix (Hobbit) with my latest OpenELEC/Kodi 17 test build and there is always 10 frames dropped at the start of playback (which is pretty normal), however there are no (zero) frame drops at any point later in the video. In fact the RPi3 is barely breaking a sweat (all cores at about 40-50%).

With your sample, I always see 9-11 dropped frames at the start of playback, and then zero frames dropped during the remainder of the video. CPU load is a little higher though, at about 70-80% per core.

You might want to try overclocking your sdram_freq as this can help with HEVC decoding. My overclock settings are, they might work for you, or they might not:

Code:

arm_freq=1300
gpu_freq=500
over_voltage=4
core_freq=500
sdram_freq=580
over_voltage_sdram=5
sdram_schmoo=0x02000020
force_turbo=1

[noggin]

I wonder if the variation in HEVC decode CPU requirements depends on the degree of complexity of the toolset used by the H265 encoder that encodes the content. AIUI not all encoders are equal, and not all the encodes they generate are equal either.

ISTR that early H264 encoders only used little more than MPEG2-style compression (and required high bitrates as a result), and it took a while for the more complex AVC/H264 tools to be deployed (allowing bitrates to drop).

I wonder if similarly some H265 encoders are not deploying the full toolset, whilst others are using more? (I remember reading an analysis of the early BBC UHD HEVC tests that suggested the encoders weren't using all the tricks in the HEVC box) Could it be that those encoders using relatively simple tools may produce content that requires less decode power than those that use more complex approaches - even at the same bit rate? (Or even that high bitrate stuff encoded simply may well require less CPU than lower bitrate stuff encoded using more complex tools?)

Or am I barking up the wrong tree?

[shadow]

I'm testing the HEVC sample from popcornmix (Hobbit) with my latest OpenELEC/Kodi 17 test build and there is always 10 frames dropped at the start of playback (which is pretty normal), however there are no (zero) frame drops at any point later in the video. In fact the RPi3 is barely breaking a sweat (all cores at about 40-50%).

With your sample, I always see 9-11 dropped frames at the start of playback, and then zero frames dropped during the remainder of the video. CPU load is a little higher though, at about 70-80% per core.

You might want to try overclocking your sdram_freq as this can help with HEVC decoding. My overclock settings are, they might work for you, or they might not:

Code:

arm_freq=1300
gpu_freq=500
over_voltage=4
core_freq=500
sdram_freq=580
over_voltage_sdram=5
sdram_schmoo=0x02000020
force_turbo=1

I was using the same over clock as posted in the first post which are the same except I actually have a higher sdram_freq

[rascas]

I wonder if the variation in HEVC decode CPU requirements depends on the degree of complexity of the toolset used by the H265 encoder that encodes the content. AIUI not all encoders are equal, and not all the encodes they generate are equal either.

ISTR that early H264 encoders only used little more than MPEG2-style compression (and required high bitrates as a result), and it took a while for the more complex AVC/H264 tools to be deployed (allowing bitrates to drop).

I wonder if similarly some H265 encoders are not deploying the full toolset, whilst others are using more? (I remember reading an analysis of the early BBC UHD HEVC tests that suggested the encoders weren't using all the tricks in the HEVC box) Could it be that those encoders using relatively simple tools may produce content that requires less decode power than those that use more complex approaches - even at the same bit rate? (Or even that high bitrate stuff encoded simply may well require less CPU than lower bitrate stuff encoded using more complex tools?)

Or am I barking up the wrong tree?

I think so, yes.

But I think that the main reason for the fact that some HEVC videos with higher bitrate work better than others with less bitrate its because of the options used in the encode. In most encoders there are options called presets. The slower presets produce lower filesize videos (more compressed) and more cpu power is needed to decode the video. The faster presets produce higher filesize videos (less compressed) and less cpu power is needed to decode the file. I remember options like me, subme, bframes reference frames etc, affect this.

[Milhouse]

I was using the same over clock as posted in the first post which are the same except I actually have a higher sdram_freq

Yes, 580 is as high as my memory will go without errors.

In that case, if you've got a spare SD card then it might be worth testing my latest OpenELEC test build just in case there's a difference between OpenELEC and OSMC which needs further investigation (though do read the last few pages of the thread first, as current Kodi master has been a pain for the last few builds).

[shadow]

I was using the same over clock as posted in the first post which are the same except I actually have a higher sdram_freq

Yes, 580 is as high as my memory will go without errors.

In that case, if you've got a spare SD card then it might be worth testing my latest OpenELEC test build just in case there's a difference between OpenELEC and OSMC which needs further investigation (though do read the last few pages of the thread first, as current Kodi master has been a pain for the last few builds).

I'll try and scrounge around for a extra memory card and try OpenELEC tomorrow.