Supported

  • AudioDecoder can decode AAC, FLAC, MP3, Opus, and Vorbis.
  • VideoDecoder can decode VP8, VP9, H.264 and AV1 (AV1 not available on Android).
  • VideoEncoder can encode VP8 and VP9.
  • VideoTrackReader.
  • ImageDecoder can decode BMP, GIF, JPG, PNG, ICO, AVIF, and WebP.

Unsupported

  • AudioEncoder is not yet implemented.
  • VideoEncoder can encode H.264, but it is limited:
    • H.264 encoding is not available on all platforms.
    • The output format is Annex B. We expect the format to be AVC in the future.
  • new VideoFrame(pixelFormat, planes, frameInit) is not available.
  • ImageDecoder  can’t decode SVG. We don’t expect SVG to ever be supported.

Caveats

  • AudioDecoder and VideoDecoder call error(undefined) to report an error. We expect the value to be a DOMException in the future.
  • VideoDecoder, VideoEncoder, and EncodedVideoChunk are not available in Worker contexts. Worker support will be added in the future.
  • VideoEncoder does not emit VideoDecoderConfig objects to describe its output. We expect configs to be emitted in the future.
  • Constructing a VideoFrame from an ImageBitmap produces an I420 frame. We expect this to change to RGBA or an opaque format in the future.
  • In some cases a valid VideoFrame has format === null and planes === null. VideoFrame.createImageBitmap() is available. We expect to add explicit conversion APIs to address these cases in the future.
  • ImageFrame  does not provide YUV access. We expect that ImageDecoder will output VideoFrame objects in the future.
  • H.264 extradata and payload must be provided in AVC format.

Known Issues

AudioDecoder, VideoDecoder, and VideoEncoder may produce outputs or errors after calling reset().

有被爽到

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: WebCodecs in Chrome M86: Limitations

最近实现了NMSv3接收GB28181设备注册,下发指令主动通知摄像头以RTP推流到NMS,转为RTMP, KMP, FLV播放。

NMSv3不是完整的GB28181实现,我将SIP信令与RTP流媒体服务器合二为一,仅作为实时视频取流的用途。

当我准备实现设备注册,密码验证时,找到一篇博文:https://blog.csdn.net/hiccupzhu/article/details/39696981

其中讲到的算法是:

HA1=MD5(username:realm:passwd) #username和realm在字段“Authorization”中可以找到,passwd这个是由客户端和服务器协商得到的,一般情况下UAC端存一个UAS也知道的密码就行了
HA2=MD5(Method:Uri) #Method一般有INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER;Uri可以在字段“Authorization”找到
response = MD5(HA1:nonce:HA2)

对比REGISTER中的response与计算的response,相同则验证通过。

但我却验证错误,仔细阅读了exosip这部分的代码后,终于找出差异:https://github.com/aurelihein/exosip/blob/master/src/jauth.c#L144

当设备第一次发送REGISTER,NMS回复401, 并附带

还有一种回复是

原来这个qop的设置与否,决定了验证算法的差异。

当不设置qop时,确实是使用上面的那种算法进行验证。而设置为”auth”后,则使用下面的这个算法:

HA1=MD5(username:realm:passwd) #username和realm在字段“Authorization”中可以找到,passwd这个是由客户端和服务器协商得到的,一般情况下UAC端存一个UAS也知道的密码就行了
HA2=MD5(Method:Uri) #Method一般有INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER;Uri可以在字段“Authorization”找到
response = MD5(HA1:nonce:nc:cnonce:qop:HA2)

可以看出,HA1、HA2是相同的,区别在于resopnse有差别。开发时需要注意这点,如果想使用简单的验证算法,回复401时,不要传qop=”auth”参数。

另外还有一种qop=”auth-int”的算法,这里由于决定权在服务端,所以不做详细研究。如果做向上级级联,则要根据上级401的参数来响应。

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: GB28181 设备注册密码验证算法