Try size decimation but the output quality for MJPEG could be terrible (I know we don't take screenshots to admire but it affects LED). Check CPU usage from previous post. If you switch to my fork the problem with lag should disappear.
Beiträge von Awawa
-
-
I GOT IT!!!!!! thhhhhhxxxxx @Awawa !!! Leds are finally going. dmesg errors are still there but leds are going. I can see a bit of delay response, I need to calibrate them.
Do you think I can connect rpi4 now or better not?
Great
Seems the Bluetooth was the root of the problem (and port misconfiguration at some point) as suggested by @Lord-Grey . If you're going to use ezcap 269 then give Rpi4 a try: quality with YUY2 encoding is better than MJPEG but it requires USB3.0 so Rpi4 is necessary.Check CPU usage for current setup (command top, then press 1). MJPEG can easily take over the whole cpu's core and then high framerate by ezcap can cause the system to meld down.
-
Code
sudo systemctl disable hciuart sudo reboot
remove it from that file. you were supposed to run it from command line after editing config.txt
and check dmesg if bluetooth disappeared and released uart. -
For latest Raspian:
https://www.raspberrypi.org/do…ion/configuration/uart.md
dtoverlay=disable-bt
fol older:
dtoverlay=pi3-disable-bt
Check dmesg to see if helped
Definatelly you dont want to see that lines as in your latest log at the end:Code
Alles anzeigen[ 13.705520] Bluetooth: Core ver 2.22 [ 13.705620] NET: Registered protocol family 31 [ 13.705631] Bluetooth: HCI device and connection manager initialized [ 13.705662] Bluetooth: HCI socket layer initialized [ 13.705681] Bluetooth: L2CAP socket layer initialized [ 13.705711] Bluetooth: SCO socket layer initialized [ 13.727224] Bluetooth: HCI UART driver ver 2.3 [ 13.727240] Bluetooth: HCI UART protocol H4 registered [ 13.727309] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 13.727529] Bluetooth: HCI UART protocol Broadcom registered [ 14.017506] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 14.017519] Bluetooth: BNEP filters: protocol multicast [ 14.017539] Bluetooth: BNEP socket layer initialized pi@HyperBian:~ $Make sure to run
Codesudo systemctl disable hciuartAnd restart.
If it doesnt help then I'm out of ideas and propable that Lightberry USB converter isnt compatible with Rpi or it needs some special settings for example: custom COM speed.
-
Hi @Awawa do you have a command line to disable Bluetooth? I tried through cyber duck but with no luck. Ok for the port setting
Modify boot/config.txt to be sure it'll remain unloaded.
If you dont want use editor (I recommend mc and its internal editor for beginners) on Rpi3 you can achieve it using commands from internet, but I havent test it:Codeecho "dtoverlay=pi3-disable-bt" | sudo tee -a /boot/config.txt sudo systemctl disable hciuart sudo rebootAnd save dmesg and Hyperion and ls -ltr /dev/tty* logs after each step (1 after modifying port configuration, 2 after modifying port configuration + disabled Bluetooth to see if something has changed)
-
<ERROR> Device disabled, device 'adalight' signals error: 'Invalid serial device name: [ttyUSB0]!'
Correct that port setting (to ttyACM0) in configuration.
And disable eventually that bluetooth, otherwise we go in circles without clue. -
Yes, I know but I suspect that your lightberry usb converter isn't compatible with Rpi4 or Hyperion.NG or it's broken: there is no communication on virtual RS/USB port (/dev/ttyACM0) in Linux.
-
OK, fast hotfix and new release v8.2.0.8A for multiformat grabbers (for ex. MJPEG and YUYV)
Format encoding can be set on the grabber config page but make sure to check logs if it works for your device because driver can override it if something doesn't fit for him.
-
2020-09-15T21:31:02.191 hyperiond V4L2:AUTO : <ERROR> Frame too small: 0 != 4147200
Plug ezcap to USB2.0 as there are some strange problems with YUV capturing in your config (or MJPEG and YUV if they both exist). Did you ever get the video preview in the web Hyperion.ng and did you upgrade firmware in the ezcap? -
@shokwaav Seems that it's the old issue with Hyperion that I mentioned before:
https://github.com/hyperion-project/hyperion.ng/issues/908 (I suspect crash it's caused by yuv high framerate, it's fixed in my fork)
Some randomness with switching between YUV and MJPEG if both are available.
I'll try to fix it on my own as I need it too. -
I have updated first few posts to step by step guide.
Benchmarks for Rpi3/4 and MJPEG/YUV decoding are posted here:
https://hyperion-project.org/t…-center.10652/#post-26684New release based on latest Hyperion.NG 2.0.0.8A:
https://github.com/awawa-dev/HyperHDR/releases -
Rpi4 has just come. YUV is working perfectly. Well, YUV HDR is broken the same as MJPEG HDR and need to be repair with LUT. Image quality is much, much better.
There is small inconvenience that we cant select YUV or MJPEG in Hyperion but YUV is default option fortunately... at least for now before restart. As for performance I will post tomorrow results. There is big gain for higher resolution but if Rpi3 get USB3.0 there wouldnt be a need of upgrade to Rpi4.
As a new Hyperion release is coming I will try to build new version of HyperHDR fork based on it soon.
-
Technically it's possible, but the LUT table object is bind to v4l2 grabber by design, some methods are in v4l2 worker and image processor and can be accessed but the main object initialization in other module can be a pain.
-
how do I install hyperion from your fork? Actually I installed hyperbian on my pi4.
Well, it can be a hard way if you dont use Linux...I dont have Hyperbian but Raspbian so the first thing you need is to uninstall Hyperbian.NG and install my fork (link in the signature, in releases there are compiled packages).how do I generate a lut with my settings?
Default settings should be sufficient if you experience bleak colors (examples are on my fork page), click only save LUT.Thanks for the answer, for the moment I think I'll wait for the yuy2 optimization, I'm in no hurry ...
In fact I think I finished it. Performance for YUV/YUY2/YUYV,UYVY increased x3 and MJPEG x10. There is of course support for multithreading but it's crucial thing rather for MJPEG decoding on Rpi.So it can be used even without HDR support just for better performance and much smaller lag.
As I'm next week offline & more testing is needed & I'm still waiting for my Rpi4 I will prepare release later or you can compile that version from master branch sources (keep in mind that the LUT format for that version has changed and is needed to be regenerated).
-
@Tyler983 As you have Rpi 4 probably you want to wait a little as I'll finish optimization for YUY2 encoding that is enabled when Ezcap 269 is connected to the USB 3.0 port of Rpi4. You can of course try my latest build to test YUY2 but the performance for that encoding isnt great: I took the procedure from Hyperion.NG 2.0.0.7A...in facts it's worse than MJPEG decoding from my fork now but I can only test on camera that supports that encoding. With LUT direct YUV>RGB translation I improved the performance nearly 50% without tone mapping and 75% with tone mapping in first tests for 1280x720. We will see how it works when my new Rpi4 will come from the China....now it's only speculation.
The penalty of MJPEG are jpg artifacts that can be visible on LED especially on dark scenes. Even if the movie is stopped but the grabber is still working there is a little noise. That's why YUY is better and the status I explained on the start. Higher resolution can help quality of MJPEG stream.
For now the old way is recommended. You have to have working LED system connected to the RPI and HDMI to USB signal converter for ex. Ezcap 269 (that's not the subject of that topic):
1 I recommend you to connect Ezcap 269 to USB 2.0 port Rpi3/Rpi4. This will force MJPEG encoding.
2 Install Hyperion from my fork
3 Generate LUT table from the LUT generator page (link in the grabber configuration page) and upload it to the Hyperion configuration folder.
Typically /home/pi/.hyperion/.....4 restart service or RPi. Then enable HDR tone mapping in the grabber properties. For better performance try Border mode (mainly for leds) or the full screen to preview result.
5 Check result in the live feed (upper right corner) and debug log (System->Log).
-
I started to dig it again and I found this:
https://gathering.tweakers.net/forum/list_messages/1986718
Another surprise. It's seems that there is one more benefit for USB3.0: YUY2 encoding that provide much more quality and better performance. Unfortunately it's disabled when the device is connected to USB2.0 and MJPEG is enabled instead. That's why I didn't see it on Rpi3 but I tested it on Win10 and it was missing either. I've connected ezcap to Windows now and YUY2 is enabled! I could swear that I didn't see that in Windows either before firmware upgrade from the ezcap page.
Performance & quality on Win10 for that light encoding are great! 1080/60FPS with almost no frame lost. My next setup is Rpi4
And LUT for fast YUY2/HDR translation is incoming ... No need to convert YUY2->RGB that is processed by Hyperion using live equations anymore -
Another surprise. It's seems that there is one more benefit for USB3.0: YUY2 encoding that provide much more quality and better performance. Unfortunately it's disabled when the device is connected to USB2.0 and MJPEG is enabled instead
So I think your question is still valid if you dont want to upgrade to Rpi4 and use Windows instead. But I dont know if there is a Windows grabber in Hyperion that enables capturing from the device. There is DX9 grabber in pull request but I think it's rather for screen capture. Meantime I've ordered Rpi4
-
I don't see any benefits for using Rpi4 beside a little better performance but it's enough just to get few frames per second, 1-2 more than Rpi3. Maybe it's better to talk @priv if you have other questions on this setup
-
The purpose of that, is avoid place an order of RPi 4 with USB 3.0 for ez269 and use the RPi 3 for SPI.
Just to clarify: that grabber works with USB 2.0 on Rpi3. USB bandwidth usage is minimal for MJPEG encoding....decoding on Hyperion.NG is another story. -
Good call.
I got it to work with a standard 4K signal, although with a delay that I need to figure out how to fix - I can't set the frames per second to anything above 5.that's quite OK according to the MS2109 spec:
1920x1080 MJPEG:30fps, YUY2:5fps
1600x1200 MJPEG:30fps, YUY2:5fpsand the input resolution/fps
4K 60,59,50,30,29,25,24,23Hz
1080p 60,59,50Hz
720p 60,59,50Hz
576p 50Hz
480p 60,59Hz
PC 60Hzseems that there is nothing less than 50hz for 1080p
I dont think that yuy2 is supported but it's a question to persons that own it and claim it works (mjpeg works but there are other problems)
case PixelFormat::UYVY,
case PixelFormat::YUYV,
case PixelFormat::BGR16,
case PixelFormat::BGR24,
case PixelFormat::RGB32,
case PixelFormat::BGR32,
case PixelFormat::MJPEG:
