always H264 mod when streaming and cannot switch to MJPEG mod

[EngineerWill]

• The Streaming Mode in the menu is fake in launch shell always use H264 streaming

  USTREAMER_ARGS+=('--h264-sink' 'tinypilot::ustreamer::h264')
  USTREAMER_ARGS+=('--h264-sink-mode' '')
  USTREAMER_ARGS+=('--h264-sink-rm')

  If I want to use MJPEG for streaming, I still cannot switch to MJPEG mode after setting it on the web page.

Because H264 will cause higher latency, I hope users have the right to choose.

Although I have solved the problem . I still want to ask if it was intentional? If it is not intentional, am I welcome to initiate a PR?

[mtlynch]

That code makes the H264 stream available on the backend. You're correct that the H.264 is always available even if the frontend chooses MJPEG, but the stream does indeed switch between MJPEG and H.264 depending on the user's choice.

It's very unusual that H.264 should cause higher latency. It's a much more bandwidth-efficient protocol than MJPEG, so I've never heard of H.264 being higher latency.

[EngineerWill]

That code makes the H264 stream available on the backend. You're correct that the H.264 is always available even if the frontend chooses MJPEG, but the stream does indeed switch between MJPEG and H.264 depending on the user's choice.

It's very unusual that H.264 should cause higher latency. It's a much more bandwidth-efficient protocol than MJPEG, so I've never heard of H.264 being higher latency.

My test environment is two Raspberry Pi 4b, one outputs HDMI signal (output resolution is 1080p or other), and the other one is used as kvm.

I modified the maximum frame rate so that the device can stream 60fps video because I used a USB3.0 capture card.

In the two streaming modes of H264 and MJPEG, you can clearly feel that H264 will freeze and delay. In MJPEG mode, there is no such problem. I think it may be a codec problem.