Extremely weird FPS issue!

[quartz flare]

I've always had low FPS with my webcam, between 5 and 10 on average. I've been running like this for months. Today, I decided to use the /dev/v4l/by-id/my-webcam-device-name instead of /dev/video0 and I suddenly got a steady 30 FPS! I thought that I finally had a solution, until I had a second look at the name of the device that I copy-pasted. I got the device name by executing ls /dev/v4l/by-id and copied everything without realizing that there were two devices, so I had this in my crowsnest.conf:

device: /dev/v4l/by-id/usb-EMEET_HD_Webcam_eMeet_C960_A231117000901624-video-index0  usb-EMEET_HD_Webcam_eMeet_C960_A231117000901624-video-index1

I removed the second device name and then boom, I was back to 5-10 FPS! I tried putting some garbage after the device name and FPS went up to 30! I thought I was crazy so I tried at least 15 times with different settings and the only way I could get 30 FPS was to add some garbage after the device name. It also works with /dev/video0 (as it should because it's only a symlink I think?)

This is so weird! What could cause this?!

[paper flame]

Upload a log

But no idea, right now, why it should act like that

Only thing coming to my mind would be that the resolution doesn't get set correct and you are having a lower res or something like that, with the garbage at the end

To check that, you can activate debug logging

[mortal echo]

Ahoi @quartz flare!
It looks like you did not provide all the necessary information we need to help you.
Please upload your logfiles and a detailed description of your problem.
For further information see: https://docs.mainsail.xyz/faq/getting-help/discord#provide-information
Note: We only accept .log and .txt files as log files.
This is an automated message

[quartz flare]

Here's a log with the last two service restarts (first one with proper device name). It is indeed starting ustreamer with different parameters and for the second one, it complains that the resolution is unavailable and defaults to 640x480. I also just noticed that the aspect ratio is different, but otherwise, the quality is surprisingly good at 640x480. I'm just not sure I understand why ustreamer complains that the resolution is unavailable because it should be available.

[paper flame]

I also just noticed that the aspect ratio is different
640/480 is ofc different to 1920/1080....

I'm just not sure I understand why ustreamer complains that the resolution is unavailable because it should be available.
I bet it's the nonsense value, that messes things up somehow

You have some random foo in your start parameters and I think ustreamer interprets it as something, resulting in this weird behaviour

Seems like the format is messed up

INFO  [69920.052    stream] -- Using resolution: 640x480
INFO  [69920.052    stream] -- Using format: YUYV```vs```INFO  [69855.585    stream] -- Using resolution: 1920x1080
INFO  [69855.585    stream] -- Using format: MJPEG```

Your cam doesn't support 1920x1080 with YUYV

So this seems like nothing I want to invest time into fixing, as this is just some user error that's easy to avoid on the user site and harder to fix correctly on the program side (currently)

[quartz flare]

The parameters passed to ustreamers are not the same in both cases:
--host 127.0.0.1 -p 8080 -d /dev/video0 --device-timeout=2 -m MJPEG --encoder=HW -r 1920x1080 -f 30 --allow-origin=* --static /home/biqu/crowsnest/ustreamer-www
vs
--host 127.0.0.1 -p 8080 -d /dev/video0 foo --device-timeout=2 -r 1920x1080 -f 30 --allow-origin=* --static /home/biqu/crowsnest/ustreamer-www

The issue is with the code that generates these parameters. I think it would be nice to figure out what it is so you could let crowsnest fail with a meaningful error message instead of silently ignore it.

[paper flame]

Sry somehow missed your message

The parameters are both times the "same". The problem is just an user error messing with the final values

The first one tries to get optimal parameters for the device: /dev/video0
The second one for the device: /dev/video0 foo

But how does it now get the different parameters you might wonder.
In this code snippet it takes the device and looks if it got a MJPEG encoder, as some devices only got YUYV. So if the passed device got it, it will pass -m MJPEG --encoder=HW

But the device /dev/video0 foo doesn't exist, therefore it won't find that encoder

But now you might think, why are you starting the stream in the first place?
We start it, as someone might have disconnected it accidentally atm and will reconnect it later. That way he doesn't have to restart the service, if he accidentally unplugged it

Therefore ustreamer starts and just waits for the cam. If it cannot find the cam, you will see the infamous No signal screen.

But as you have passed /dev/video0 foo instead of /dev/video0foo, it can actually find the cam and just ignores the foo

So you got some parsing mismatches that leads to problems here. v4l2-ctl that we use to determine the encoders will throw an error, as it doesn't know the parameter foo. But ustreamer on the other hand just ignores it.

The next idea might be, "then just cut at spaces". I'm not 100% sure, but I think that's currently more work than it's worth it.
I'm currently rewriting the code in Python, there it will be easier and therefore the "(currently)" in the message before yours.

But I see a problem in there too. If for whatever reason I want to support arbitrary names in the device path, I couldn't support spaces, as I would workaround this problem.