Beiträge von The

I have to advise caution on the recommendation for the . I gave it a shot and it's going back to Amazon. While mikec27's situation is a bit different than mine, my research is as follows.

TLDR;

Splitter and downscaling work in some capacity, but it does not maintain the proper color pallet when downscaling 4K Dolby Vision to 1080. If you are looking for that capability, look elsewhere.

Setup/Attempt Details

1. 4K Ultra HD Disc with Dolby Vision (John Wick 3)
2. Ezcoo Device SP12H2 upgraded to latest firmware
   
3. Denon AVR-X6300H driving the Vizio and feeding the Ezcoo device
4. Vizio 4K TV supporting HDR10, Dolby Vision
5. Without the device connected, AV equipment and TV recognize the full 4K Dolby Vision Signal perfectly
6. Ezcoo Device has 3 EDID modes: 4K7.1 Dolby Vision, 4K5.1 HDR, Copy; HDMI out set to "scale"
7. 1080p HDMI2AV to convert the "split" signal into something for Raspberry PI to ingest
8. Did not test audio.

EZcoo Mode	Main Screen TV Signal	Hyperion Preview
4K7.1 Dolby Vision	4K Dolby Vision (great, expected!)	Purple; obviously bad
4K5.1 HDR	4K HDR10 (ok, less desirable)	Washed Out, lacking reds and oranges
Copy	1080p simple; device passthrough allows the HDMI chain to "see" my HDMI2AV only-1080p capable device, downgrading entire HDMI chain to 1080; 1080 not acceptable; If I had a 4K device here, maybe it would work, but I fear it would simply output purple too.	About as expected due to signal conversions; normal for my system

Questions for mikec27

1. What EDID setting are you using?
2. What device are you using downstream of the Ezcoo to digitize the signal?
3. Does you TV remain/recognize the full 4K Dolby Vision signal from your input?

Last summer I had a lightning strike in the back yard. While I had no other damage in the house besides my sprinkler controller, the raspberry PI pin used to send the signal to the LED strip was somehow damaged. I used this StackOverflow post: https://raspberrypi.stackexcha…nd-functional-on-raspi-3b to run a quick/easy test to confirm the pin was bad. Basically, it sends one byte out a pin (used to drive the LED signal) and tries to read it via another pin.

Nothing specific mentioned about HDR, HDR10, HDR10+, Dolby Vision?

Yeah, that example is pretty simplistic in that it doesn't really process a "real" image or video stream. As I don't fully understand the hyperion API, the documentation and source code aren't exactly clear if/who is responsible for obtaining an image for processing. I'd have no idea on how to handle the dewarping math and would have to rely on a library such as opencv. This StackOverflow post seems to delve into some of this and issues with dewarping a true 180 fisheye into a usable image. This was fun to look into but I'm running out of motivation due to many potential roadblocks.

I explored the V4L2 virtual camera in combination concept with the OpenCV fisheye undistort options. While I'm not 100% certain, they both look to be written for more of a still image scenario. Digging a bit more, I ran into GStreamer which seems to have some promise. It does look like it exposes a dewarp function based on opencv. I've run out of patience for today, and remain unconvinced I'll spend more time digging into this.

Interesting:

• https://raspberry-projects.com…ing-video-using-gstreamer
• https://platypus-boats.readthe…-streaming-gstreamer.html

Those install instructions didn't work for me, and I gave up. The raspivid command looks like it's piping video through gst-launch-1.0. That gst-launch smells like it has a way to construct a pipeline...maybe that dewarp can be used in some obtuse gst-launch command to construct a "pipeline" to surface a dewarped video stream originating from the camera without constructing a special gstreamer plugin or writing code. I'm only 5% certain of that statement.

Other examples:

• https://github.com/umlaeute/v4l2loopback/wiki/Gstreamer

Flovie, I was talking to a coworker about a similar concept on the way back from a tech conference this past Friday. I agree with most of your pros/cons.

Since I'm not familiar with the "proto" approach, I'd think I'm going to explore this V4L2 virtual camera in combination concept with the OpenCV fisheye undistort. I'm completely unsure of the performance impacts to the video stream. I'll play a bit with it, but I haven't purchased a true fisheye lens camera yet.

Regarding "proto", are you talking about protocol buffer? Can you provide a hyperlink please?

Zitat von Ace Malik

So when the dual AVR is using a 4k signal say xbox or ps4, and the 2nd hdmi is going into the hdmi2av device in order to get to the grabber, those 2 devices wont be able to process the 4k signal so no ambilight?

In my case, the 2nd HDMI is used for the grabber and only works in 2K(1080). The AVR automatically senses this and downscales both HDMI outputs to the 2K(1080) signal. No 4K signal for either output. However, my TV can display the 2K signal just fine. And the grabber works just fine. Just no 4K in any situation where the 2K grabber is connected.

Re: "Nice try" : I just created a sample bit of code to curve the LED regions. I haven't persisted them to JSON yet. I was hoping the DEV team could let me know if its worth pursuing.

Re: "Wash out" : Not exactly. The inexpensive 4K digitizer equipment doesn't render HDR content to the video stream properly. Colors lose their brightness and become closer to white/gray (like when you wash a bright colored shirt many times in the washing machine, the shirt loses its color) as I understand it. The camera wouldn't capture all the brightness of HDR, but it probably be better than the washed-out color the digitizer would produce.

Moved my Bezier curve conversation here to the DEV forum.

...breaking this off from another thread that got too technical for the other channel...

Curious if any of the developer could chime on if this could theoretically work to pseudo-solve 4K hardware issue (more far below).

Synopsis

• HyperionNG
• or very wide angle lens camera grabber mounted close range (assume complete view of screen)
• Creating a hyperion.config.json file with the led's hscan/vscan oriented using a tool like the screenshot below.
  

  
  

• Proof of Concept cobbled-together half-baked example using Bezier curves for definition of a fisheye LED configuration. Hacked together from this code.

Define "Theoretically Work"

• LED colors approximate the screen edges to work with movies
  

  
  

• Black bar detection would be a big plus, almost essential (most questionable in my mind)
  

  
  

• Can manually or externally tweak the config.json to adjust the LED layout in curves
• Built-in-to-TV smart streaming services would work.

Thoughts

• Kludgy hack! Yep.
• Won't work with changes in lighting! Watch TV in the dark.
• It could move! Duct tape.
• Hyperion UI doesn't work or save like that! Don't care too much if it loads my config.
• Live with HDR washout! Yeah, you're probably right.
• Spend the money on HDFury! Yeah, you're probably right.
• Wait until better 4K hardware support! Probably best course of action.

Background

• Using hyperion with proper 4K support for HDR, HDR10, Dolby Vision is very pricey. Seemingly between $500 - $700 USD for HDFury hardware
  

  
  

• Just brought a 4K TV and Disc player

Check out this cobbled-together half-baked example using Bezier curves for definition of a fisheye LED configuration. Hacked together from this code. You can drag the handles to adjust the curves on the sample image provided by Pnp.

• Needs to read in a .config file to get the LED counts for the top/left/right/bottom.
• Needs to export the .config so the LED hscan and vscan position would be proper
  

  
  

• many other missing pieces

Thinking about the fisheye/trapezoid setup. I'm thinking the black bar detection won't work so well. I imagine the black bar detection algorithm would try to traverse inward from the top/bottom outer edges in a straight horizontal line to find the non-black pixels to project to the LEDs. I could see another way to write the algorithm.

giovanne, can you comment if the black bar detection works with your trapezoid setup?

Zitat von joebar65

...not to worry with 4k hdmi 2.0 problems.

For those reading this thread, while the splitting with the Denon will work fine if both outputs (TV/converter) support 4K, you likely will have HDR/HDR10/DolbyVision issues with the HDMI converter unless you invest in a lot of hardware. I ran the joebar's same setup on 1080 HD successfully. More info here.

Zitat von joebar65

i'm using a denon AVR-X2200W, works like a charm, but i have a full hd plama 50"
https://hyperion-project.org/t…amplifier-htpc-case.1007/

Agree that your Denon will work when both the TV and the converter are the same 1080 HD capable. However, if/when you go to a UHD (4K) TV and your converter remains HD, the Denon will choose the common format (the normal 1080 HD). See manual here: http://manuals.denon.com/AVRX2200W/EU/EN/GFNFSYkabkahie.php and screenshot Then, you'll have to deal with the problems that 4K brings if you want HDR.

Zitat von Angelos Kritsotakis

thank you The for your input, now wondering if newer models can outpute separate resolutions. If your input is 4k, do both hdmi outputs send out 4k signal?

I doubt the newer models will support that, but you can check the manuals for language as I've highlighted. I don't have a secondary 4K capable device hooked to the AVR, but according the manual and logic, I'm fairly confident that both outputs would be the same 4K. Unfortunately, finding a cheap HDMI converter that deals with the HDR formats of 4K isn't possible as of Dec 2019 from what I've read.

Thanks for the fisheye lens screengrab. It looks like I suspected. How close is the camera to the TV?

Zitat von Ppn

i don't think fisheye is not a good idea...

I don't quite follow your comment due to the double negative. I think you are meaning to say "it is a bad" idea. I agree with you that the trapezoid tool will not work. At this point, I think the fisheye could work (as long as hyperion is sampling the portion of the image within those little boxes)

I'd think a tool can be developed to use 4 bezier curves (one for each side of the TV) and another example getLUT() function . The center of each of the boxes could be plotted equidistant along the curve to represent the LED zones. Those bezier curves could be adjusted (by a human) to follow the warped edge of the TV. I'd even say that a user could straighten the 4 curves to simulate the trapzoid tool. Of course, there's time/effort involved in creating a tool, as those demos simply show how to draw bezier curves in a browser window.

Zitat von giovanne

Sounds interesting, but the cam seems not that cheap ...

$50USD is substantially cheaper the known-good working solution using $500+ worth of HDFury equipment.

Any thoughts about using a (or very wide angle) sitting directly in front of the TV (below the bottom edge of the screen) by about 12 inches (30cm)?

If I understand correctly, the trapezoid tool is modifying the config.json to sample the proper areas of the screen. Fisheye would be more of a round/elliptical pattern which theoretically could be similarly adjusted (even painstakingly manually). For my setup, it may be the best option considering the placement of walls, furniture, obstructions, etc. Not sure if the 180° lens so close the the TV would work, and/or if the "internals" of HyperionNG would work.

I can verify that a normal cheapo webcam sitting on a table in front of the TV works just fine with my build of HyperionNG.

I have a Denon AVR-X6300H AVR (1 step below top of the line flagship model in May 2018) with 2 HDMI outputs functioning as a splitter and working well. Input signal is from a Windows 10 PC.

Today I upgraded my TV to a 4K Vizio model fed by a 4K signal from the PC. Now, sadly/unfortunately, when I have the 1080 digitizer attached, the AVR downgrades both outputs to 1080. Immediately after plugging in the digitizer, the signal is "noticed" (for lack of a better term) by Windows 10, and the Windows desktop switches out of the 4K mode and back to 1920x1080. Argh, I was hoping to avoid this.

Sadly, my AVR doesn't have the dual-resolution output as far as I can tell at this point.

Great! Nice work. Be interesting to see the diagram. If it is indeed the black wire to the relay signal, that may explain the "ground driven / active low" in the relay photo, in hindsight.

You could be right with the way the TV is reacting. Good thought. However, if you saying you powered the 2 meter LED cable off the TV's USB port, prior to this I'd think that the USB isn't shutting down, but more the like the relay isn't seeing or doing what it needs to do. A few thoughts:

• I'd attach a volt meter to the USB cable and watch the voltage on the + while the TV is starting/running, and its reaction when turning the TV off.
  

  
  

• Your new relay has a little jumper on it that toggles the way the relay reacts to the signal wire. Unsure if trying the other position if the default doesn't work (after reading/understanding its details)
  

  
  

• Maybe it thinks there is a short (as a worst case). I wonder if there is some setting buried within the TV menus (probably not) that may solve it.
  

  
  

• Try powering the relay from the red wire (as well as feeding it to the signal) instead powering the relay with the 5v yellow one, though I'm most apprehensive about that idea. Maybe the TV is seeing there is no significant voltage being consumed by the port, so it shuts it off. By feeding the relay with it, it may think it's okay.
  

  
  

• If you have some detectable voltage from #1, or see a "pattern" that happens when the TV turns on and off, perhaps you can feed that signal to the Raspberry Pi as an input, program some python/code to watch for the pattern, and use another gpio output pin on the Raspberry Pi to control the relay input signal. However, DO NOT FEED the TV's USB 5v into a gpio pin on the Raspberry Pi, as the pins are not 5v tolerant. See https://raspberrypi.stackexcha…-the-spi-pins-5v-tolerant it has a solution for stepping down the 5v to the 3.3v level using a voltage divider (never used one). Of course, that's not worth it unless your can see/parse/understand the signal from the USB.

Robin, Yeah, the relay will work between the power supply and the LEDs. I'm assuming you want the USB on the TV to "signal" the LEDs to turn on...and when you turn off the TV, you want the LEDs to go off.

I'm not an electronics guru. I'm making an educated guess. I would dare try this on my own TV after tooling with a volt meter. If you burn your TV up or your house, well, sorry.

See schematic below and also this.

The relay takes a 5v input signal, and needs a 5v supply and a ground. I'm assuming your TV energizes the USB cable with +5v when its on. Basically, I think that can be used as the signal to tell the relay to activate. I think the blue and black both would need to be tied to the ground on the relay. The yellow can be fed from the power supply since it's always on (otherwise I think you could feed that from the usb +5v too). The green is used as a circuit breaker to power or de-power the LEDs.

If this worked, I still wouldn't do it this way since I'm comfortable tooling with mains voltage and this method would keep the power supply energized sucking power even when everything is off. I suppose if the RaspberryPi is a media server (powered by the power supply) that would be okay though.