AMD Polaris (Radeon RX 4xx) H265 Encoding Samples

[KarMa]

Don't really like ReLive and the basic controls on it. Only have control over resolution, 30/60fps, and A/V bitrate in the ReLive GUI. Compared to all the encoding options with OBS Studios.

But decided to use ReLive to do a quick little unofficial comparison between it's HEVC and H264(AVC) encoders. I used the benchmark in the 2004 game Counter Strike Source, which I consider good even by today's standards. Especially the nice water rendering. Without limiting my GPU I average 270fps on this test but I'm currently limiting my GPU to 60fps. Towards the end of the benchmark when looking at the TV monitors there are some jerking movements that I have always seen. I can only guess it's the camera path changing slightly as I see it at 270fps even, so I don't think it's the encoder but a defect in the test.

As usual, the higher the bitrate the less difference there is between the two. At the current max of 50Mbit I don't see much of a difference between the two. Also I really don't like the timer in the top left but can't find any info on how to remove it during recording. Edit: Figured out how to remove the record timer.

Both of the provided samples are 1080p/60fps/5Mbit.

[Roph]

ReLive doesn't make anywhere near full usage of VCE's capabilities. It uses main profile H264, not high (even VCE 1 is capable), and I'd guess the "speed" VCE preset instead of balanced or quality. It's awful.

Which is strange, because VCE 2/3/4 (290/Fury/Polaris) can all do 1080p60 with their quality presets. And ReLive is built into Radeon settings, it knows what GPU you have and thus its VCE capabilities. For streaming I'd definitely stick to OBS with the plugin.

ReLive also seems to use a terrible downscaling filter if your stream/recording resolution isn't the same as your game's resolution.

[edit] I installed CSS and ran that benchmark, recording it using OBS with the VCE plugin and chose settings with a 5mbit/s limit. See the result for yourself, clearly superior to ReLive

[KarMa]

Should point out that you produced a 30fps video instead of a 60fps which I used. So that can heavily skew something like this. When I run a 30fps test the differences are smaller. However, what I am noticing is the RGB ---> YUV conversion is better in your sample (with OBS). Were you using the Full or Partial YUV range, and where you using 709 or 601 color space. My samples just look dull and inaccurate.

[Roph]

Oh, didn't notice yours was 60fps I'll re-do it. Partial range in 601 space, NV12 format.

[edit] Ok, here's 60fps in both H.264 from OBS, and I also recorded it with 100mbit/s then encoded it to HEVC at 5mbit/s (came out more like 4.5) with A's test build.

[KarMa]

While trying to ignore the RGB -> YUV color problems in ReLive, the OBS H.264 version is still able to retain a bit more detail. Same is true for the A's test build HEVC encoding vs the HEVC ReLive. A's being a bit better at retaining detail, especially considering the A's encoder was a 10% bitrate disadvantage. Which shows promise of what might be possible when (if ever) AMD releases their SDK for HEVC.

The biggest issue right now seems to be the RGB -> YUV in ReLive, along with the variable frame rate (while OBS is constant) which makes the HEVC encoder pretty unusable for me. Even though I would like it use it.

[KarMa]

To show what I mean by the color shifting I'm noticing, I made a simple RGB32 colorbars in avisynth with colorbars(width=1920, height=1080), to simulate a standard RGB screen capture (video game for example). My card is outputing RGB32 and I only managed to save the test bars as a RGB24 .PNG but that should not matter too much. With the generated colorbar sample I made it my desktop background and then proceeded to capture video of my desktop with both OBS Studio and AMD's ReLive software. With the two programs, I captured in YUV 4:2:0 (NV12), as well as H.264/60fps/20Mbit. Which should be plenty of bitrate for stationary color bars.

To help with comparing the two captures I used AlignExplode() from vaporeon800. The script requires a YUY2 input so everything gets converttoyuy2() before AlignExplode().



The .PNG testbars I created and eventually set as my desktop.




What it looks importing the .PNG into avisynth for alighnexplode(). The conversion to YUY2 does not seem to have hurt it much.

ImageSource("C:\....\ColorBars.png")
converttoyuy2()
AlignExplode()

What the OBS capture of my desktop looks like, with expected RGB->YUV420 chroma resolution loss. But no obvious color shift. (OBS settings used 601/Partial range)

LoadCPlugin("C:\......\ffms2.dll")
FFVideoSource("C:\.........\OBS.YUV420.mkv", threads=1)
converttoyuy2()
AlignExplode()

AMD's ReLive capture of my desktop to YUV420, giving the expected 420 chroma loss along with a major color shift. Using ReLive's default YUV settings, as the user can not configure anything with the YUV output settings. All I know is that ReLive outputs YUV420, with both the H.264 and HEVC options.

LoadCPlugin("C:\.....\ffms2.dll")
FFVideoSource("C:\........\ReLive.YUV420.mp4", threads=1)
converttoyuy2()
AlignExplode()

I could have overlooked something as I'm sure there are still things for me to learn on RGB-YUV relations, so speak up if anyone sees an issue with my testing methods.

[Roph]

Feel free to submit an issue to AMD's github for it, else I will

[KarMa]

Feel free to submit an issue to AMD's github for it, else I will

Guess I'll post something here. https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues

[vhelp]

Hi KarMa. The "original" has color 2-pixel bleeding. The color should transition into the next block color cleanly, but that has not happened in this case. So that may be the source of the problem you noticed with the remaining portions of your tests. My guess is that somewhere in your initial process, that is happening. Fix that and you will have better results imo.

EDIT: ok, never mind. The image is good. The webpage magnifier was the fault. I downloaded the png and loaded that and this time did not see any artifact. Sorry for the false-alarm.

[jagabo]

AMD's ReLive capture of my desktop to YUV420, giving the expected 420 chroma loss along with a major color shift.

Your ReLive capture is using the wrong color matrix, rec.601 instead of rec.709. Using:

ImageSource("RGB-YUV.ReLive.png") # RGB image
ConvertToYV12(matrix="rec601")
ConvertToRGB(matrix="rec709")

restores the original colors (aside from rounding errors).

[KarMa]

LoadCPlugin("C:\......\ffms2.dll")
FFVideoSource("C:\...........\ReLive.YUV420.mp4", threads=1)
convertToRGB(matrix="rec709")
converttoyuy2()
AlignExplode()

Yeah that fixes it jagabo, just has the added loss from another RGB-YUV conversion as you said.

But this brings up questions of why the OBS version looks fine despite me using rec601 in the OBS settings to record at 1080p screen. I knew that 709 is designed for 720p and above yet I went with rec601 and it looks fine for capturing 1080p. Guess the AMD drivers OBS uses are wrong, or OBS' GUI is messed up. Idk.




Capturing my 1080p screen in OBS using rec601.



Capturing my 1080p screen in OBS using rec709.

[jagabo]

Looked fine on what? Remember what shows up on the screen is always RGB. So somewhere along the line the video is converted from YUV to RGB to be displayed. Some programs/players always use rec.601, some always use rec.709, some switch depending on the resolution, and some follow what is flagged in the video (if it's flagged).

[KarMa]

The two bottom images came from.

LoadCPlugin("C:\........\ffms2.dll")
FFVideoSource("C:\.....\OBS.rec601.mkv", threads=1) #same was true with OBSrec709
converttoyuy2()
AlignExplode()

Both from recording my desktop with the provided sample image in #66. They have the same color shifting (or lack of for rec601)when playing them in VLC.

[jagabo]

How are you producing those images from AlignExplode? The output of that filter is YUY2 video so it's being converted by some program to RGB before you can save the image as PNG. VirtualDub, for example, usually converts YUV to RGB with a rec.601 matrix -- regardless of resolution, even if the video is flagged rec.709.

Maybe you should just upload short video samples for analysis.

[KarMa]

Using AvsPmod to deal with the avisynth and using it to output PNG snapshots. All of the .PNGs I have uploaded on page 3 of this thread have been saved with AvsPmod, including the original 1080p colorbar picture. Ok I'll upload video samples.

[jagabo]

You can control the final YUV to RGB conversion by adding ConvertToRGB(matrix="rec601") or rec709 at the end of your script. That way you know for sure how it was done.

Also, I misinterpreted the situation in post #70. It looks like the ReLive is using a rec.709 matrix to convert captured screen RGB to YUV in the video -- which is typical for HD video. AVSPMod is displaying it wrong, using a rec.601 matrix.

[KarMa]

I redid all my samples to just make sure I had everything in order, and I'm still seeing the same shifting. After all this stationary colorbar testing I also found that ReLive will actually duplicate much of the frames if it sees nothing is happening, so I decided to move around a small text box in the corner to get it to trigger the motion detector. All the samples were set to 50Mbit but the encoders came no where close to that with these stationary colorbars.

[jagabo]

None of the four videos has the color matrix flagged within the video. OBS.rec601.mkv has YUV 4:2:0 with rec.601 colors. The other three all have YUV 4:2:0 with rec.709 colors. This script shows them all with the same colors:

v1 = LWLibavVideoSource("OBS.rec601.mkv").ConvertToRGB(matrix="rec601").Subtitle("OBS 601")
v2 = LWLibavVideoSource("OBS.rec709.mkv").ConvertToRGB(matrix="rec709").Subtitle("OBS 709")
v3 = LWLibavVideoSource("ReLive.H.264.mp4").ConvertToRGB(matrix="rec709").Subtitle("ReLive AVC 709")
v4 = LWLibavVideoSource("ReLive.HEVC.mp4").ConvertToRGB(matrix="rec709").Subtitle("ReLive HEVC 709")
Interleave(v1,v2,v3,v4)

When I loaded that script minus the ConvertToRGB() commands Avspmod displayed the images using rec.709 colors. When I added BilinearResize(640,480) it displayed the frames with rec.601 colors. So Avspmod appears to use rec.601 for SD, rec.709 for HD. The version I have is very old so behavior might have changed.

[ezcapper]

Amf. 1.4 released scroll down to purple developer header, h265 encoding enabled
http://radeon.com/en-us/software/relive/

[Roph]

Unfortunately it's not actually released: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/48#issuecomment-268067292

It will be 2017 at the earliest.

[ezcapper]

Just found out that rx 480 will not support 4k60 encoding, that has me leaning towards Nvidia:
http://cdn.wccftech.com/wp-content/uploads/2016/12/file-page10-copy-881x1140.jpg

[jagabo]

AMD's poor track record with video encoding should be enough to sway you away from them.

[ezcapper]

AMD's poor track record with video encoding should be enough to sway you away from them.

The quality is very good, if I didn't need the 4k, I'd be more than happy with it. The HEVC encoding quality on the Polaris cards is very, very good.

[Roph]

That slide you linked pertains to AMD's relive tool's encoding, VCE's capabilities are higher. If you click each version of VCE here you can see benchmark results.

Albeit for H.264, but polaris encodes H.265 faster than it does H.264, I guess they designed it with the future in mind.

[Roph]

Beta version of A's released with preliminary VCE H265 support: http://bluesky23.yukishigure.com/en/AsVideoConv.html

[wiak]

relive hevc at maximum of 50mbps with 320kbps aac audio
https://f001.backblazeb2.com/file/nwgat-cdn/misc/relive-1080p60-50mbps-hevc.mkv (much better at streaming/seeking, mkvmerge remux)
https://f001.backblazeb2.com/file/nwgat-cdn/misc/relive-1080p60-50mbps-hevc.mp4 (streight out of amd relive)

[KarMa]

Can't seem to download your video wiak.

[wiak]

Can't seem to download your video wiak.

now it should work

[vhelp]

wiak, is this a game video or actual video?

To me, game videos are a waist of time to properly analyize and review an encoders performance.

As disappointed I am with Intel's quicksync encoder, its the best performing hardware encoder for quality videos. I am going by Intel's latest release, Kabylake, which appears to be the same *video* quality level as Skylake although that makes no sense why their latest was not improved over Skylake--i'm stumped!! But QS is still the best. I haven't seen any other examples from NVidia. But rumar has it that its worse than AMD's. At least the two of those makers release updates while on Intel's, you have to buy a new system to get a latest API which is v1.19 so that probably explains why Kabylake has the same features/function as Skylake. So, my advise is the go with Skylake since they will be cheaper by now. And Intel's newest cpu, Canalake (mid-to-late 2017) but keep an watchful eye out for the API version since that will give you an positive indication that video quality levels will have improved. If the version number is greater than 1.19, it will probably be a better performer!

[ezcapper]

That slide you linked pertains to AMD's relive tool's encoding, VCE's capabilities are higher. If you click each version of VCE here you can see benchmark results.

Albeit for H.264, but polaris encodes H.265 faster than it does H.264, I guess they designed it with the future in mind.

Wow those numbers are not good, especially at the quality setting, it can't even do 1080p60 in real-time. The reLive samples look ok, but the A's converter samples are more pertinent to the capability of the card.

But overall, I'd say AMD has done a great job at the sub $100 price range and they will only improve with vega