4K@60Hz(FPS)

[Gormar]

whats RK101010 ?

Next RockChip SoC .

[kaefert]

ah, okey.


Well I've just bought and setup the Beelink R89, I'm not really thinking about upgrading again in the near future.. - So this RK101010 chip is of no significance to me at the moment.


I think I maybe did not phrase my question clearly enough, sorry. I'll try again:
I'm currently encoding videos with ffmpeg 8bit x265 with 3840x2160 @ 60fps with yuv420.
This plays well on my setup, without any stutterings or other problems as far as I can see.


Now I think there are several areas for potential quality improvement still:
-) using a 10bit h265 encoder instead of 8bit
-) upgrading from yuv420 to yuv422 or even yuv444


My question was, if anybody
-) knows if this will work (play with the hardware-decoder)
-) knows of problems concerning one of the above
-) or has any other hints on what route to take to accomplish my goal of best possible video quality with the hardware I have.

UPDATE: while I'm already at it (asking questions)
Does anybody know of a way to make screenshots that include the hardware-decoded picture and have the full resolution?

screencap -p filename.png
does only give me 1920x1080 png files and those files will be completely green with no picture in it when the hardwaredecoder is playing a video in full screen.
When I kill the /system/bin/mediaserver then I get screenshots contianing the current video frame downscaled, but of course it will not run without stuttering anymore because that is the software renderer of the MX-Player app.

[Rayzin]

So this RK101010 chip is of no significance to me at the moment.

[kaefert]

? care to elaborate?

[Rayzin]

He was joking with you he was talking about RGB Color space not RK chipset. Go back and read his post again.

Anyway did you say you are able to play 8bit 4K@60 content on your Beelink? It would be interesting to see a screenshot of that if you manage on figuring out how to take one.

And 4k@60 10bit content is possible with the rk3288 but only at yuv420. Same goes for 8bit 4k@60.

The consensus goes a color space higher than yuv420 is only really needed/noticeable during post production editing and if you want to use the tv as a desktop.

[Gormar]

Sorry I made some unnecessary confusion. I shouldn't mention RGB101010 color mode and even better write it as RK101010 because RK3288 HEVC decoder doesn't support that color format. It is like Rayzin wrote: YUV color coding at 8 or 10 bit per channel with 4:2:0 chroma subsampling.

But there shouldn't be a problem to decode 60fps 8bit YUV4:2:0 HEVC video stream and send it to display through HDMI 2.0 at 60fps and 10 bit per channel by means of interpolation.

[kaefert]

okey, sorry for not getting the joke.
I rendered and tested an 8bit yuv444 h265 4k 60fps file on my beelink r89 today, it falls back to software rendering and stutters out 5 frames per second or something the like

yes, 8bit yuv420 4k 60fps h265 file is working nice (I've been saying so already) with no visible problems (a screenshot wouldn't help proving that, since most problems with most players is only stuttering, not artefacts or something that you could see on a static screenshot)

I couldn't find an x265 10bit compiler yet - if you say the decoder supports h265 main10 profile, 10bits yuv420 should work too, correct?

UPDATE: so you say it can play videos encoded with RGB101010 - it was my impression that nearly all encoders encode yuv color space, is that not correct? is there some way to make x265 encode RGB instead of YUV?

[Gormar]

I downloaded some sample vidoes from: http://www.demo-uhd3d.com/categorie.php?tag=10bits and they work flawlessly. But "the fastest" which I found was 4k 10bit (main10) at 50fps (Astra SES Demo).

RK3288 doesn't support RGB101010 (10 bpc) HEVC decoding. Only YUV4:2:0 at 8 or 10 bpc (color depth).

[kaefert]

as far as I know, the possible color spaces for 10 bits have mostly the same name as in 8bit, so yuv444 yuv422 and yuv420 - do you mean yuv444 when you talk about yuv101010 ?
But I guess since the hardware-decoder doesn't understand yuv444 for 8bit video he won't for 10bit neither.

[Gormar]

@kaefert. There is so many confusing term used improperly. I'm not an expert in video encoding but as far as I understand there are at least three separate terms which people tend to mix toghether.

1. color space - it describe pallete of color thones which can be displayed. Which is connected with color components used which describes how any given color is made: RGB (primary colors), YUV or rather YCrCb (Luma, Chrominance).
2. color depth - how many different values color components can take. Higher value allow for better/fluent tone gradients. i.e 8bit per color channel=256 primary colors. 10bit=1024 primary colors and when three components are used then it will allow for 1,07bln possible colors in contrast to 16,7mln when 8bpc is used.
3. chorma subsampling - this is a method used to compress color data in YUV color space. i.e.: 4:4:4 means there is no color compression, 4:2:0 chrominace of two neighbouring pixels will be the same. It allows to save half of the bandwith in comparision to 4:4:4.

[kaefert]

yes exactly, thank you @Gormar for the good summary!

1.) at least the x265 encoder that I have will only encode YUV - when I pass a clip with RGB color space from Avisynth it seems to me as it is automatically converted to YUV.

2.) yes, for the moment I'm using a 8bit encoder, from what I read you need to have a specially compiled 10bit encoder to generate 10bit. I could not yet find an x265 10bit version compiled windows64 (or x265 enabled ffmpeg with 10bit)

3.) yuv444 means no chroma subsampling, yuv422 means chroma subsampling horizontally, but not vertically, and yuv420 means chroma subsampling both horizontally and vertically (so yuv420 has only 1 chroma pixel for 4 luma pixels)

So what is left for me to test if the RK3288 hw-decoder can decode yuv422 or only yuv420.
And if I one time will find a x265 compiled for 10bit I can continue testing with that one.

If somebody has any information for me that makes my testing easier, it would be very welcome.

[Gormar]

No other chroma subsampling format than 4:2:0

I'm almost certain that RK3288 HEVC decoder doesn't support 4:2:2 chroma subsampling. Because in this SoC datasheet RockChip mention only Main and Main 10 HEVC profiles and not Main 4:2:2 or Main 4:2:2 10. These are official names for HEVC profiles with other than 4:2:0 chroma subsampling. http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles

As for encoder x265 support Main 10 profile.

[kaefert]

oh! okey! thanks Gormar!

So the only thing left for me that might improve quality is to get a 10bit encoder.

zeranoe does not seem to offer a 10bit ffmpeg build --> http://ffmpeg.zeranoe.com/builds/
and the other way to get my avisynth output to an x265 encoder "Avs4x265" does not have a build for 64bit cpu-architecture (and my script won't run in 32bit since I need much more than 4gb ram)

So for now I'll have to stick with 8bit encoding. Either there will be an 10bit x265 enabled ffmpeg build in the future or maybe I'll restructure my video processing and encoding procedure to have (lossless) intermediate files and join them together and encode them in a last step with 32bit avisynth to be able to use Avs4x265 + x265.exe

[Gormar]

It seams that ffmpeg has some problems with passing arguments to libx265 and it doesn't have 16-bit precision version which support main10 profile.

I'm not exactly sure what are you doing but maybe Hybrid will help you.
You can also probably use some newer x265 builds for 64-bit Windows.

[kaefert]

I now found this script:

https://github.com/rdp/ffmpeg-windows-build-helpers

which has an option "--high-bitdepth=y" which allowed me to build a 10bit enabled x265+ffmpeg. I'll report back in a few days with my results, my render-server is currently busy with other tests..