Tweet
Originally posted by arQon
View Post
Okay, I had some time on and off over the last week to poke around at this a bit. TLDR: the situation is still almost exactly the same mess that it was a year ago. 
* ffmpeg is still missing multiple patches that the Pi needs for performance to not be destroyed at anything above 1080p even in the VERY rare cases that the HW decode actually works.
* There is still no DRM leasing, so nothing except the custom VLC build (in fullscreen only) and Kodi/etc can display a surface without copy and conversion. To give you a rough idea of the impact, that means mpv etc need to burn ~25% of the CPU just on that even at only 720p.
* The IPU (ISP, technically, but that tends to confuse people) still isn't hooked up, so, again: no HW conversion, no HW blits, etc etc.
* ffmpeg (again) is still missing multiple patches (again) to handle anything other than 8-bit h264. That is to say:
** There is no *working* HW decode for 10-bit h264 (the decode itself does use the HW, but the output is corrupted as hell).
** There is no working HW decode for *any* form of h265.
I didn't bother looking into VP8, for obvious reasons.
Note that this is with ffmpeg master, so even the usual Arch insecurity doesn't apply.
IOW, other than with the custom ffmpeg build (which is now thousands of commits diverged from master in both directions), there is still no HW accel on the Pi, other than for 8-bit h264: a format that it can easily handle in SW anyway.
Performance-wise, for that one working format, 720p h264 clocks in at ~25-30% load in semi-HW (i.e. with HW decode, but SW colorspace conversion, blit, etc), vs ~30-35% load for the whole thing being done in SW. Yay?
As a frame of reference, the custom VLC+MMAL combination on Raspbian, over 2 years ago, takes ~10% load for 1080p 10-bit HEVC.
So, yeah. Although you're right that there's technically been some progress, from a user perspective there hasn't actually been any visible improvement in the experience at all. There's also no real indication when there might be, if ever.
Amusingly, there are actually fragments of a discussion around using VK to provide the IPU functionality that's currently unavailable, since it would at least be better than having to do it all in SW.
You've completely misunderstood that post, I'm afraid. (Not that it really matters though, since the information in it is no longer relevant anyway).
The assorted hackery in it was specifically to work around a batch of defective kernels, and is not required under normal circumstances.
* ffmpeg is still missing multiple patches that the Pi needs for performance to not be destroyed at anything above 1080p even in the VERY rare cases that the HW decode actually works.
* There is still no DRM leasing, so nothing except the custom VLC build (in fullscreen only) and Kodi/etc can display a surface without copy and conversion. To give you a rough idea of the impact, that means mpv etc need to burn ~25% of the CPU just on that even at only 720p.
* The IPU (ISP, technically, but that tends to confuse people) still isn't hooked up, so, again: no HW conversion, no HW blits, etc etc.
* ffmpeg (again) is still missing multiple patches (again) to handle anything other than 8-bit h264. That is to say:
** There is no *working* HW decode for 10-bit h264 (the decode itself does use the HW, but the output is corrupted as hell).
** There is no working HW decode for *any* form of h265.
I didn't bother looking into VP8, for obvious reasons.
Note that this is with ffmpeg master, so even the usual Arch insecurity doesn't apply.
IOW, other than with the custom ffmpeg build (which is now thousands of commits diverged from master in both directions), there is still no HW accel on the Pi, other than for 8-bit h264: a format that it can easily handle in SW anyway.
Performance-wise, for that one working format, 720p h264 clocks in at ~25-30% load in semi-HW (i.e. with HW decode, but SW colorspace conversion, blit, etc), vs ~30-35% load for the whole thing being done in SW. Yay?
As a frame of reference, the custom VLC+MMAL combination on Raspbian, over 2 years ago, takes ~10% load for 1080p 10-bit HEVC.
So, yeah. Although you're right that there's technically been some progress, from a user perspective there hasn't actually been any visible improvement in the experience at all. There's also no real indication when there might be, if ever.
Amusingly, there are actually fragments of a discussion around using VK to provide the IPU functionality that's currently unavailable, since it would at least be better than having to do it all in SW.
You've completely misunderstood that post, I'm afraid. (Not that it really matters though, since the information in it is no longer relevant anyway).
The assorted hackery in it was specifically to work around a batch of defective kernels, and is not required under normal circumstances.
Comment