MRV wrote: ↑
Sat Jan 18, 2020 6:05 pm
Is there a reason that the RAM, CPU frequency and kernels have improved yet there has been no improvement regarding the video encoder (GPU)?
Mainly expertise and ownership.
Cranking up ARM cores is relatively simple as you buy in the relevant IP from ARM. Interfacing to alternate RAM providers depends on finding a suitable package and wiring it up.
The H264/MPEG4/H263/MPEG2/VC-1 codec block is a Broadcom IP block, so support really needs to come from them. They no longer sell any other products using this block, so they have no interest in investing effort into updating it. Most of their multimedia devices are for set top boxes, so decode is their requirement, not encode.
AFAIK ARM don't sell a video encode IP block, so you can't easily buy one off the shelf and plug it to your chip. (Licencing and avoiding cross-contamination would get entertaining anyway with Broadcom making the chip and designing their own codec blocks)
CPU performance and software is catching up to the extent that the need for hardware acceleration is significantly reduced. There are parts that can be usefully hardware accelerated (eg CABAC, and motion searching), but the rest can be run on the CPU. Someone observed recently that video decode through the hardware blocks achieved around 60fps, when software decode could hit about 110fps.
We have invested in video decode for HEVC on Pi4. The block does have some other options, but I don't recall the details.
The ISP isn't rated significantly higher than the video_encode block anyway - somewhere around 150MPix/s in reality for Bayer images, so 75fps at 1080p. ARM definitely don't do a decent ISP, therefore without a new design from scratch for that you'd be struggling to create the content to encode.
It's all an area that is being looked at and the use cases considered.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.