As part of ARM’s fall refresh of their Mali graphics product lineup, today ARM is announcing refreshes and new products in a number of product segments. All told ARM is releasing new GPUs, a new video process, and a new display processor. Having already taken a look at the new Mali 800 series GPUs separately, let’s dive into the other part of today’s announcements from ARM, focusing on the video processor and the display processor.

As ARM seeks to be a nearly top-to-bottom processor IP vendor, alongside their well-known Cortex CPU designs and Mali-T GPU designs the company also offers the other processors needed to complete the graphics stack. Alongside the GPU designs these are the Mali-V video processors for real-time video encode and decode, and the Mali-DP display processors. In the scope of today’s announcements both parts are receiving feature updates to add new functionality and to keep them up to par with the capabilities of the new Mali GPUs. Overall ARM is making a significant emphasis on 4K this year, lining up the hardware necessary to decode and render to 4K, and to do so within the bandwidth constrains of an SoC.


Starting things off we have ARM’s new video processor, the Mali-V550. With the V550 ARM is introducing full HEVC support into their video processor, building off of the H.264 support present in the earlier V500. Like the V500 the V550 is a video decode and encode processor, so with today’s update ARM’s product stack gains the ability to do both HEVC decoding and encoding.

Overall V550 retains V500’s basic architectural design, which not unlike ARM’s GPUs is based around the concept of cores. In this case the number of cores can be scaled up to support additional streams or higher resolutions/framerates, with ARM supporting 1080p60 on a single core and scaling up to 2160p120 on the largest 8 core configuration. This of course goes for both encode and decode performance.

Along with the addition of HEVC support, V550 also introduces a couple of other new features to the Mali video processor. ARM can now process 10-bit YUV video, which is expected to see significant usage with HEVC and goes hand-in-hand with the 10-bit YUV support added to the Mali 800 GPUs.

Meanwhile ARM is introducing a new video encoding feature for V550 dubbed Motion Search Elimination, which is intended to reduce video latency and power requirements. MSE borrows heavily from ARM’s transaction elimination technology, which was introduced on the Mali 700 series and reduced memory bandwidth by using CRCs to identify unchanged screen tiles and to avoid writing those redundant tiles out to the frame buffer. In the case of MSE the idea is quite similar, only this time ARM applies the tile principle to video encoding instead of rendering. By identifying unchanged tiles, ARM can then skip the motion estimation step of H.264 video encoding for those tiles, which saves on time and power doing what would otherwise be a redundant encoding step.

Eliminating motion estimation should have an immediate impact on power consumption, as it’s generally considered the most time consuming step of the encoding process. However along with the power savings from skipping motion estimation, ARM is also touting this as a means of reducing encoding latency, something which would be very important for wireless display technologies such as Miracast. The benefits would be variable at best, but for transmitting desktops and other semi-static content it should have an impact on encode latency and therefore overall input lag on such setups.

One thing to note though is that like 10-bit YUV, MSE will require the rest of the processing pipeline to support this feature. In this case the display processor (which is piping the display output back to the video processor) needs to support the technology.


And speaking of the display processor, we have ARM’s final announcement of the day, which is the Mali-DP550 display controller. Like the V550 video processor, the DP550 is an ecosystem play that sees some general feature enhancements along with reciprocal support for other new features introduced on ARM’s latest GPUs and video processors.

From a high level overview, ARM’s display processors serve as both a display controller and a sort of simple GPU of their own, handling basic operations such as scaling and layer composition along with interfacing with the display itself. By doing this in fixed function hardware as opposed to the more flexible but power hungry GPU, ARM is able to save some power by avoiding sending off this simple work to the GPU.

For DP550, ARM has scaled up its performance to handle 4K resolutions along with more complex composition tasks. Whereas DP500 could only composite up to 3 layers and work with sub-4K panels, DP550 can drive 4K panels while compositing up to 7 layers. From a phone and tablet perspective it seems questionable if we’re going to see 4K in those devices any time soon, but for ARM’s secondary TV market, being 4K capable on DP550 will be a big deal.

Meanwhile DP550 adds reciprocal support for other features added to the Mali 800 GPUs and Mali-V550 video processor, including motion search elimination and 10-bit YUV for video. Also of note, ARM has added a co-processor interface to DP550 to allow it to directly interface with 3rd party processor blocks, though ARM hasn’t gone into detail on what they expect those 3rd party blocks to be.

Finally, like the Mali 800 GPUs, ARM is releasing these designs to SoC integrators today. Which means we should start seeing the V550 and DP550 appear in retail products by the end of next year.



View All Comments

  • npz - Tuesday, October 28, 2014 - link

    Holy crap, finally 10-bit YUV support! But I have a few questions:
    - is only for HEVC, or also for AVC (h.264)?
    - what about 10-bit YUV 4:2:2 and 10-bit YUV 4:4:4 (hi10p 444)?

    Are there still limitations in parts of the h.264 or h.265 spec that is supported by hardware? I've been hunting recently for some alternative to full cpu software encoder/decoder, but so far have not come across any fixed function decoder/encoder that supports the full spec gamut of h.264. They always choke up at something like the number of I, P or B-frames allowed for certain resolutions, limits in GOP (length between I-frames) etc. I remember that Youtube chokes if you have B-frames, but they may have fixed that now (I hope). That's just a portion of limitations I've found in my research. If you search forums for various devices, Galaxy Tabs, roku/roku-like devices, you'll find people often need to transcode again their already transcoded video. So I'm hoping something like this could be the holy grail.
  • name99 - Tuesday, October 28, 2014 - link

    I've no idea about the parts that you are dealing with, but Apple's h.264 decoders have been well defined since the iPod nano days.
    For example iPhone 6 supports High Profile at level 4.2. This is very clearly defined (eg
    ) as to both features supported and how aggressively the features can be supported.

    My experience has been that the actual HW matches the claimed capabilities. For example, when I encode using x264 and setting features according to the claimed support, I get a movie that plays. When I push beyond the claimed support,iTunes refuses to copy the movie over, telling me that it is not supported on the given HW.
  • npz - Wednesday, October 29, 2014 - link

    What I mean is that Apple's hardware does not and no other decoders so far, supports the entire spec. If you target Apple ipod 6, it won't work on Apple TV. In fact, Apple gen 1 vs 2 vs 3 are all different. Apple TV gen 3 only supports up to High@L4.0 if I recall.

    The Profile and Levels do not tell the entire picture either. There can be other restrictions in the hardware but still within the restrictions of Profile and Levels. For example many hardware decoders don't support 16 reference frames, even when they say they support High Profile @ L4.0, when 16 ref frames is valid for High Profile @ L4.0 for 480p.
  • dabotsonline - Thursday, October 30, 2014 - link

    H.265 / HEVC 4K120 4:4:4 10-bit is encouraging, although 12-bit would have been even better. Reply
  • toyotabedzrock - Tuesday, October 28, 2014 - link

    They should offer a decode only version for non phone and tablet applications.

    On another note I have yet to see any of the promised space saving advantage of HEVC. All the demo files i have seen are similar in size to the h264 copies.
  • wyewye - Wednesday, October 29, 2014 - link

    "transmitting desktops and other semi-static content"
    Nobody in their right mind would use a lossy compression for sending desktop content like operating applications.
    Loosing a few pixels in a video is nothing, but on a app UI it looks like crap.
  • extide - Wednesday, November 05, 2014 - link

    Everybody using miracast does exactly that, send desktops over a (lossy)compressed stream. Reply

Log in

Don't have an account? Sign up now