Skip to content
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

Closed
dstulken opened this issue Sep 11, 2019 · 3 comments
Closed

Ambiguous handling of MJPG source format #8

dstulken opened this issue Sep 11, 2019 · 3 comments
Assignees
Labels
resolution:fixed Fixed type:feature New feature or request

Comments

@dstulken
Copy link

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:

  1. 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.

  2. 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.

  3. 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!

@mdevaev
Copy link
Member

mdevaev commented Sep 11, 2019

Hello! Thanks for using ustreamer :)

  1. The -m/--format option takes precedence over -c/--encoder, so if you specify -m JPEG format, the encoder will be forced to change to HW. This is necessary to avoid setting an incorrect configuration. HW isn't the same as OMX. HW encoding means direct receipt of the encoded JPEGs from the camera, but OMX is an encoding RAW camera data using GPU. Probably to avoid confusion I should have used the CAM abbreviation instead of HW, but at that moment I didn't think of it :(

  2. Not all cameras allow you to adjust the quality of the JPEG. This is precisely the reason that the value of the parameter -q/--quality is ignored. In this case I report this: Can't query HW encoder params and set quality (unsupported). Hmm. Apparently, this wording is too "low-level". If you offer a short message that will be more clear, I will add it.

  3. HW encoder can process only MJPEG format. OMX (means GPU) and CPU can process all other formats except MJPEG.

@mdevaev mdevaev self-assigned this Sep 11, 2019
@dstulken
Copy link
Author

A-ha!
Ok, that makes a bit more sense then. Thank you for the explanations.

Here are few possible ways to clarify these interactions in the "--help" text...
feel free to use or modify however you wish.

Under the encoder section, it might be good to clarify that the encoder has three options:

  • CPU (Software MJPG encoding) (Default)
  • OMX (GPU hardware accelerated MJPG encoding with OpenMax)
  • HW (Use pre-encoded MJPG frames directly from camera hardware)

And then, under the quality section, it might help to add something to the effect of:
"Note: If HW encoding is used (JPEG source format selected), this parameter attempts to configure the camera or capture device hardware's internal encoder. It does not re-encode MJPG to MJPG to change the quality level for sources that already output MJPG."

For the runtime error message, I think you said it pretty well in your explanation above actually. So instead of the error reading:
"Can't query HW encoder params and set quality (unsupported)",
you could instead say:
"Camera hardware does not support setting of encoding quality parameters, unable to change MJPG quality for JPEG source with HW pass-through encoder type."

... or something to that effect?

@mdevaev mdevaev added the type:feature New feature or request label Sep 11, 2019
@mdevaev
Copy link
Member

mdevaev commented Sep 11, 2019

Nice. A made a patch in master branch with this messages. Check it out: 5d270b0

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution:fixed Fixed type:feature New feature or request
Development

No branches or pull requests

2 participants