/dev/video0 doesn't work #888
Comments
|
Hi |
|
Hi, Thanks for the reply, Here are the logs. I used ffplay to play video0 fullscreen on the pi. I would be happy to just use the software screen grab from the pi desktop. 2024-06-28T15:24:54.025Z [LEDDEVICE0_FILE] (LedDevice.cpp:423) Refresh rate = 25.00 Hz |
Your device simply does not comply with v4l2 rules or is missing drivers: it does not inform clients in which formats it offers capture. I've encountered something like this before in prehistoric analog grabbers like here: #423 where you had to blindly assume and force some initial parameters. For example it should report such logs:
|
|
Thanks for the info. I have it setup as 1920x1080 @ 30fps yuyv. It displays fine using: |
|
The device that I am using and does work just fine in the Raspberry OS is this: https://www.amazon.com/dp/B0CYPVQRCW |
|
Then you can run these commands to find out what this device is worth in terms of v4l2 compliance (nothing more was promised here): For reference: |
Thank you. Here are the results of those commands, looks good to me. Anything else you see wrong with the input? pi@raspberrypi:~ $ v4l2-ctl --list-formats-ext pi@raspberrypi:~ $ v4l2-ctl --all User Controls Digital Video Controls |
|
If you compare this output with the reference link which includes an example of the expected correct output, this output is not correct and the situation is exactly as I described in #888 (comment) |
|
Hi, Thanks for the help, I'm still confused as to what the problem is? The device works perfect and displays with ffplay. Does it need to be mjpeg or yuyv? I can change the resolution and fps if needed along with pixel type. I just need to know what to set them to? Is there not a way to pipe the video from ffplay to the application? or scrape the desktop picture? |
|
Also here is the output from ffplay while playing, hope it can help: pi@raspberrypi:~ $ ffplay /dev/video0 |
|
To start capturing, HyperHDR must know the video format and its resolution (width x height). These values for all modern grabbers are reported by the driver in v4l2. However, this device only tells us what video formats it supports, without information about resolution. The only solution is to detect such a device in HyperHDR and treat it specially, e.g. rigidly assume that it can always capture 1080p YUV (even if it receives 720p at the input, hence a potential problem because we don't know if 1080p capturing is still valid for 720p input: it should be always reported by the device in v4l2 properties) as I implemented in PR #423 |
|
I can prepare similar workaround if you are willing to test it. But not today, tomorrow. |
Yes, I would be happy to test. Thank you |
|
Hi |
You are AWESOME!!! Thank you so much. Works perfect. "Quarter of frame mode" works and still displays correctly in preview. |
|
Ok, So now I'm running into a new issue, where it says I have to run it as root for the LEDs to work. I installed it and turned on the service like normal. The LEDs did work in the previous version. How can I run the service as root? |
|
Thank you for testing and your support 😃
This driver is not officially supported but it should work if you switch the service to root user: #52 (comment) |
|
Thank you! |
|
Hi Awawa-dev, v4l2-ctl --set-edid=file=edid.txt --fix-edid-checksums |
|
rc.local starts last, HyperHDR is probably faster. You can add sleep command to the HyperHDR service and delay it down a bit: for example like here #742 (comment) but 30 sec is overkill for this case, few sec should be enough. Then the settings in rc.local should work. Or add these commands instead of rc.local to the HyperHDR service directly (small sideeffect: the commands will be executed each time the HyperHDR service is restarted)
BTW you should use the absolute path (for edid.txt) in the script |
|
Hi Awawa, |
|
There is no such option, and adding it for such unique case would complicate the frame decoding source code and could also have a slight adverse impact on overall performance for all devices, so I don't plan to implement it. However, if nothing helps, there is a workaround: you can design the LED strip geometry in HyperHDR to be upside down as well. The live view in HyperHDR will still be broken/flipped, but the LEDs should work properly according to the video stream. |
|
Thanks, I'm not sure what the issue is but when I stopped the service then played video0 with ffplay it worked perfectly and was right side up. Then I stopped ffplay and restarted the hyperhdr service and now it displays correctly. Not sure what is causing the picture to sometimes flip. I will update the thread if I figure it out. |
Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)
Steps to reproduce
Select /dev/video0
Using HDMI to CSI which works perfect on the OS.
What is expected?
preview of video0 which is connected, working and configured with edid for 1080@30fps
What is actually happening?
No video through HyperHDR
System
HyperHDR Server:
HyperHDR Server OS:
The text was updated successfully, but these errors were encountered: