Profile S features and conformance #261
Unanswered
jflevesque-genetec
asked this question in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello everyone,
As we all know, Profile S and Media1 kinda show their age and with Profile T and Media2 replacing the old, I guess we will see less and less clients and devices using them.
I was looking at the Profile S features this week and found 2 mandatory features which seem like they should be conditional for clients. The 2 features are "WS-Usernametoken" and "Video Streaming - MJPEG". WS-Usernametoken has been dropped as a requirement after Profile S was published (no other profile requires it) and forcing MJPEG today when we have H264 which is so widely spread and adopted by devices seems a bit excessive.
For WS-Usernametoken, I believe I have heard that it was dropped because it is a security vulnerability. Does it make sense to still require clients to support it? Would it be acceptable nowadays to accept that very very old devices which would only support WS-Usernametoken (and not HTTP digest) would not be supported by clients. Or does that break the compatibility and promise of the Profiles to be acceptable?
For MJPEG, the wording in the Profile S specification seem to indicate a client only has to be able to decode the MJPEG, not necessarily to render it. Would this mean that a client could theoretically transcode the MJPEG into H264 for example if they don't want to have to handle MJPEG in their decoding pipeline?
Beta Was this translation helpful? Give feedback.
All reactions