-
-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ambiguous handling of MJPG source format #8
Comments
Hello! Thanks for using ustreamer :)
|
A-ha! Here are few possible ways to clarify these interactions in the "--help" text... Under the encoder section, it might be good to clarify that the encoder has three options:
And then, under the quality section, it might help to add something to the effect of: For the runtime error message, I think you said it pretty well in your explanation above actually. So instead of the error reading: ... or something to that effect? |
Nice. A made a patch in master branch with this messages. Check it out: 5d270b0 Thanks! |
Hello!
I am one of probably many folks who have found uStreamer via your kind assistance with the mjpg-streamer select() timeout bug: jacksonliam/mjpg-streamer#182
In converting one of my camera servers to uStreamer for testing, I encountered some ambiguities with the way uStreamer handles MJPG sources (-m JPEG). Some may be bugs, and some may just be status output that could be clarified, but either way they cause some confusion for those migrating from mjpg-streamer.
In particular:
uStreamer attempts to utilize the HW encoder regardless of the command line encoder parameters.
if the "-c CPU" parameter is used, we still see the following output:
-- INFO [60956.549 tid=3677] -- Switching to HW encoder because the input format is (M)JPEG
-- ERROR [60956.552 tid=3677] -- Can't query HW encoder params and set quality (unsupported)
The error indicates HW encoding is unsupported, but the user is unable to avoid this error, even by specifying that CPU encoding should be used, as uStreamer tries to use hardware encoding regardless.
The JPEG quality parameter is either not functioning, or is silently ignored for MJPG sources.
When using an MJPG source, specifying a JPG compression quality level with the "-q" parameter appears to have no effect. For example, "-q 100" and "-q 10" both produce identical output in the stream. The following output is also displayed at runtime, regardless of the "-q" value:
-- INFO [60956.553 tid=3677] -- Using JPEG quality: encoder default
Perhaps this is an indication that MJPG frames from the camera source are simply being passed straight-through without re-encoding? If so, I would suggest that the user is notified of this... and/or perhaps a future feature suggestion is the ability to honor this parameter for re-encoding of MJPG to MJPG, for those of us who could benefit from a quality change for bandwidth reasons.
Slightly unrelated: In the --help output, the --encoder section lists the available options as:
'Available: CPU, HW; default: CPU.',
however your sample usage in README.md uses the line:
'--encoder=omx \ # Hardware encoding with OpenMAX'.
When specifying that hardware encoding should be used, is the correct option to use "HW" or "OMX"? Are they both accepted, and/or is there any difference between them?
Thanks in advance, I'm looking forward to seeing what uStreamer can do!
The text was updated successfully, but these errors were encountered: