Asking because in this test (Intel NUC7CJYH im Test mit LibreELEC und unter Windows 10) which is running on Kodi in WIndows, the test file did run perfectly on the J5005, but not on the 4005
That same test also says:
Under LibreELEC all of our test files run smoothly
That same test also says:
You are right about this, but:
the question still is: J4005 or J5005 (UHD 600 vs 605)?
Mabe the 12 EUs or the J4005 aren't sufficient enough vs the 18 EUs of the 605.
That is what i hoped someone could tell me, since some people are already testing and may have the 4005 and 5005.
2.) I mean should J4005 (for hardware decoding) produce the same results as J5005 (concerning decoding speed, frame dropping, stutter, video quality at all)?
I see no reason why the number of EUs would affect the video playback. It can only make a difference when rendering Kodi GUI.
I see no reason why the number of EUs would affect the video playback. It can only make a difference when rendering Kodi GUI.
i thought that too.
But still would it be nice to hear that from people actually using any of those two (J4005 or J5005) or having experimented with HDR on any of those two. You have any of these 2? If yes, can you tell me something out of your own experience with these 2?
If no, still looking for any experience:
J4005 or J5005 (UHD 600 vs 605)?
I mean should J4005 (for hardware decoding) produce the same results as J5005 (concerning decoding speed, video quality)?
Did you do that?
I only have J4105 and I saw no issues with 4K/60 (non-HDR).
The experimental HDR build is too early to make any conclusions.
4K/24Hz HDR mode works fine but 4K/60Hz HDR mode does not work properly:
Maybe devs know something regarding this issue. Kwiboo ?
I only have J4105 and I saw no issues with 4K/60 (non-HDR).
The experimental HDR build is too early to make any conclusions.
4K/24Hz HDR mode works fine but 4K/60Hz HDR mode does not work properly:
Maybe devs know something regarding this issue. Kwiboo ?
I see, so you have the UHD 600. Great.
And a Samsung Tv i assume, which i also do have.
Great to see that the 4k output works, at least in 24hz.
=> J4005 should deliver then the same quality as yours does.
Only question remains: Does J4005/J4105 (UHD 600) by hardware decoding produce the same results as J5005 (UHD 605) concerning decoding speed, video quality?
Maybe devs know something regarding this issue. Kwiboo ?
This is the main "blocking" issue from my point of view, it seems to happen when mode is changed from one 4:2:0 12-bit mode to another 4:2:0 12-bit mode (and yuv plane is involved). I think LibreELEC-Generic.x86_64-9.80-devel-20200201013402-e776789.img.gz contain a limit to use 8-bit output and if I remember correctly using 4:2:0 50/60hz 8-bit works, it will activate HDR mode on my LG OLED but I am sure colors will not be optimal.
I have not been able to produce a simple reproducible test case (not using kodi) for this 4:2:0 50/60hz distorted image issue.
I think LibreELEC-Generic.x86_64-9.80-devel-20200201013402-e776789.img.gz contain a limit to use 8-bit output and if I remember correctly using 4:2:0 50/60hz 8-bit works
Nope, 8-bit does not work too. I actually have to use only 8-bit because of the above mentioned issues with Samsung TVs.
This is the main "blocking" issue from my point of view, it seems to happen when mode is changed from one 4:2:0 12-bit mode to another 4:2:0 12-bit mode (and yuv plane is involved). I think LibreELEC-Generic.x86_64-9.80-devel-20200201013402-e776789.img.gz contain a limit to use 8-bit output and if I remember correctly using 4:2:0 50/60hz 8-bit works, it will activate HDR mode on my LG OLED but I am sure colors will not be optimal.
I have not been able to produce a simple reproducible test case (not using kodi) for this 4:2:0 50/60hz distorted image issue.
Can i ask, which Hardware setup you use?
And would you say a J4005 SoC is (concerning video quality and probably HDR futurewise) same as J5005?
I am concerned if the 6 more EUs will makle any difference!
I was about to buy an INTEL NUC7 Series (with J4005 oder J5005).
Is the HDMI Port of the Intel NUCs problematic? I read some threads (although they are almost 2 years old), that the SoC can do it, but the INTEL NUC is kind of castrated
Update: i have the NUC7CJYH.
Comparison to my old Zbox ID18 (Celeron 1007U):
What i want is: fluid skin (no animations necessary), hardware decoding of h.264 and h.265, some streaming addons mostly in 1080p (youtube, etc.). That should work
- would you guys recommend giving back the NUC7CJYH (with 4GB Single Channel) and getting the NUC7PJYH (with the J5005 + 8GB Dual Channel)?
What i want is: fluid skin (no animations necessary), hardware decoding of h.264 and h.265, some streaming addons mostly in 1080p (youtube, etc.). That should work
Not sure you'll see any tangible difference going from the J4005 to the J5005, so if you wnat to upgrade go for at least an i3 or i5. In saying that an upgrade shouldn't be necessary, all Gemini Lake chips should do 4k and 1080p H264 and H265 fine. I wouldn't worry too much about CPU utilization when watching video.
I'm trying to enable YCbCr 4:2:2 mode to see if this will fix the issue with Samsung.
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index ea07084..cdb0930 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -740,6 +740,8 @@ intel_hdmi_compute_avi_infoframe(struct intel_encoder *encoder,
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
frame->colorspace = HDMI_COLORSPACE_YUV420;
+ else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR422)
+ frame->colorspace = HDMI_COLORSPACE_YUV422;
else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
frame->colorspace = HDMI_COLORSPACE_YUV444;
else
@@ -2425,7 +2427,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
return -EINVAL;
- pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+ pipe_config->output_format = INTEL_OUTPUT_FORMAT_YCBCR422;
pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi,
conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e61..fc21c66 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -771,6 +771,7 @@ enum intel_output_format {
INTEL_OUTPUT_FORMAT_INVALID,
INTEL_OUTPUT_FORMAT_RGB,
INTEL_OUTPUT_FORMAT_YCBCR420,
+ INTEL_OUTPUT_FORMAT_YCBCR422,
INTEL_OUTPUT_FORMAT_YCBCR444,
};With this patch the colors are wrong (green-ish). Does anyone have an idea how to properly enable 4:2:2 on GLK? Kwiboo ?
I compiled another image which include a series of patches for HDR on LSPCON. I don't have any devices with LSPCON so no idea if this will work. If anyone wanna try it don't forget to enable "Allow hardware acceleration - PRIME" in Settings-->Player.
I compiled another image which include a series of patches for HDR on LSPCON. I don't have any devices with LSPCON so no idea if this will work. If anyone wanna try it don't forget to enable "Allow hardware acceleration - PRIME" in Settings-->Player.
whoa .. whoa .. whoa ..
is this a LibreELEC generic build with 4k HDR in development?? If so, I will be glad to help, i THINK i might have a LSPCON .. i have an 8th gen i3 NUC.
is this a LibreELEC generic build with 4k HDR in development??
Yes. But so far HDR only worked on Intel Gemini Lake, although with some issues.
I would be happy to help testing too but I have NUC7i5BNK which is Kaby Lake as far as I know. So this won't work, right?
I would be up for testing too, but I also have an 8th gen NUC (i5), and the patches seem to specify just the 9th gen? Is it too early for 8th gen at the moment?
HDR in some degree obviously works with it as I have a windows partition purely for watching HDR content.
I would be happy to help testing too but I have NUC7i5BNK which is Kaby Lake as far as I know. So this won't work, right?
The image include linux patches for Intel which are supposed to "Enable HDR on Gen9 devices with lspcon hdr capability". So it's worth trying on Kaby Lake.
