H264 RTSP Stream from Axis Cam not working with Janus - but working with VLC

[Sebastian Schmid]

Hi everyone,

I have connected some IP-Cams with Janus using the Streaming Plugin.

I got a "cheap" camera working (Samsung Wisenet) working with the Janus demo - but connecting an Axis (market leader) cam with Janus, I do not see any video. However, the same H264 stream works with VLC and the SDP looked fine to me.

What are the limitations or required features when using Janus for RTSP Streams (other than the H264 codec requirement)? 

[Alessandro Amirante]

As discussed several times, it's most likely a matter of H264 profile. Browsers only have to support baseline, even though some do support more profiles. You can also try to play with the profile_level_id setting in the streaming plugin jcfg file.

A.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/b305e023-ceb7-496d-a06b-6a69a5168a9e%40googlegroups.com.

[Sebastian Schmid]

Hi Alessandro,

Thanks for your quick response.

I have already played around with the H264 profile, but setting the profile to something else (e.g. "High") did not help. I am free to configure the Axis cam - but that is a lot of "try and error"...

What I do not fully understand: If the problem is the browser implementation, why is Janus (server side) logging RTSP-Server connectivity problems - and why is this already happening when I pressed "Start" in the demo, but before I pressed the "Watch or listen" Button?

[WARN] [rtsp-test-axis] 5s passed with no media, trying to reconnect the RTSP stream

[rtsp-test-axis] Reconnected to the RTSP server, streaming again

[Sebastian Schmid]

Sorry, I was not clear about the profile: I also did try "Baseline" but no effect.

[Mykola Mokhnach]

Can you please show the actual profile id in the SDP offer?

[Sebastian Schmid]

 Mykola Mokhnach:

Can you please show the actual profile id in the SDP offer?

Sorry for mixing certain profiles (I have tried various settings).

I attach one complete set of log and config files as follows

- Cam config screenshot

- Cam config double check via onvif query

- Janus RTSP config

- SDP Offer and Answer from Chrome WebRTC-internals

However, various cam configs have not helped yet (lower quality, lower framerate etc.)

 

[Mykola Mokhnach]

What does Chrome show in its log after the video is started? (https://webrtc.org/web-apis/chrome/)

[Sebastian Schmid]

Mykola Mokhnach:

What does Chrome show in its log after the video is started? (https://webrtc.org/web-apis/chrome/)

 

I have attached the complete log.

Interesting part may be:

[29464:30983:0702/121814.095550:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format

[29464:30983:0702/121814.089320:INFO:video_receive_stream.cc(222)] VideoReceiveStream: {decoders: [{payload_type: 96, payload_name: VP8, codec_params: {}}, {payload_type: 98, payload_name: VP9, codec_params: {profile-id: 0}}, {payload_type: 100, payload_name: VP9, codec_params: {profile-id: 2}}, {payload_type: 102, payload_name: H264, codec_params: {level-asymmetry-allowed: 1packetization-mode: 1profile-level-id: 42001f}}, {payload_type: 104, payload_name: H264, codec_params: {level-asymmetry-allowed: 1packetization-mode: 0profile-level-id: 42001f}}, {payload_type: 106, payload_name: H264, codec_params: {level-asymmetry-allowed: 1packetization-mode: 1profile-level-id: 42e01f}}, {payload_type: 108, payload_name: H264, codec_params: {level-asymmetry-allowed: 1packetization-mode: 0profile-level-id: 42e01f}}, {payload_type: 110, payload_name: H264, codec_params: {level-asymmetry-allowed: 1packetization-mode: 1profile-level-id: 4d0032}}, {payload_type: 112, payload_name: H264, codec_params: {level-asymmetry-allowed: 1packetization-mode: 1profile-level-id: 640032}}], rtp: {remote_ssrc: 2647080153, local_ssrc: 1, rtcp_mode: RtcpMode::kCompound, rtcp_xr: {receiver_reference_time_report: off}, remb: on, transport_cc: off, nack: {rtp_history_ms: 1000}, ulpfec_payload_type: 116, red_type: 114, rtx_ssrc: 0, rtx_payload_types: {97 (pt) -> 96 (apt), 99 (pt) -> 98 (apt), 101 (pt) -> 100 (apt), 103 (pt) -> 102 (apt), 105 (pt) -> 104 (apt), 107 (pt) -> 106 (apt), 109 (pt) -> 108 (apt), 111 (pt) -> 110 (apt), 113 (pt) -> 112 (apt), 115 (pt) -> 114 (apt), }, extensions: []}, renderer: (renderer), render_delay_ms: 10, sync_group: janus, target_delay_ms: 0}

[29464:7175:0702/121832.169211:WARNING:video_receive_stream.cc(717)] No decodable frame in 200 ms, requesting keyframe.

[Mykola Mokhnach]

> No decodable frame in 200 ms, requesting keyframe.

Yep, we had similar issues. The reason might be either packets drop/delay or invalid source stream (not enough keyframes).

Do you observe many dropped packets in charts generated by chrome://webrtc-internals/?

[Lorenzo Miniero]

Have you checked, e.g. with Wireshark or tcpdump, if the camera is indeed sending RTP packets to Janus, and that the ports are correct? If so, you may want to check if media is flowing on the WebRTC side as well, using the Admin API.

Lorenzo

[Sebastian Schmid]

Lorenzo Miniero:

Have you checked, e.g. with Wireshark or tcpdump, if the camera is indeed sending RTP packets to Janus, and that the ports are correct? If so, you may want to check if media is flowing on the WebRTC side as well, using the Admin API.

Thanks for your hints. I see RTP, RTCP and RTSP traffic using Wireshark, but I do not know how to verify if the ports are correct (at least not the destination port). 

More general: 

How can I be sure, that Cam -> Janus is fine and I should start investigating the Janus -> Browser side?

I still see the following Janus warning - and that RTSP Play Requests are sent continously...

[WARN] [rtsp-test-axis] 5s passed with no media, trying to reconnect the RTSP stream

This tells us, that the problem is located at the Janus -> Cam side, right?

[Sebastian Schmid]

Client RTP receive port seems to be fine tough

Transport: RTP/AVP/UDP;unicast;client_port=57944-57945

[Mirko Brankovic]

Communication with devices is left only to browsers, all you can do is chose device or codec and resolution, but the rest is done by browser

Regards,
Mirko

On Tue, Jul 2, 2019, 16:58 Sebastian Schmid <sebastian...@gmail.com> wrote:

Client RTP receive port seems to be fine tough

Transport: RTP/AVP/UDP;unicast;client_port=57944-57945

--

You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/82384942-0419-4b98-85ae-b00b26a7d747%40googlegroups.com.

[Sebastian Schmid]

Mirko Brankovic:

Communication with devices is left only to browsers, all you can do is chose device or codec and resolution, but the rest is done by browser

Hi Mirko, thanks for your response. I don't think that the problem is in the native WebRTC Implementation of Chrome. I am trying to use Janus to terminate the plain RTP stream from IP cams in order to make them "WebRTC ready". However, as long as Janus reports problems terminating the RTP stream from the cam, it makes no sense to start debugging in the browser, right?

- Sebastian

[Mirko Brankovic]

I see that in your Offer/Answer log file profile id (profile-level-id) don't match, I think they should, based on RFC:

https://tools.ietf.org/html/rfc6184?page=69

--

You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/97a35f18-1b44-4c03-9b9b-b5df2851debb%40googlegroups.com.

--

Regards,

Mirko

[Sebastian Schmid]

Mirko Brankovic:

I see that in your Offer/Answer log file profile id (profile-level-id) don't match, I think they should, based on RFC:

https://tools.ietf.org/html/rfc6184?page=69

Hi Mirko,

Thanks for your response and sorry for my late reply. I have to dive deeper in the H264 spec.

You are right, the do not match. I will try SDP mangling as next step, as some have proposed

https://groups.google.com/forum/#!topic/meetecho-janus/jKg5u9421kM

https://bugs.chromium.org/p/chromium/issues/detail?id=793038

 

[Sebastian Schmid]

Well, SDP mangling (setting profile-level-id to 42e01f) did not help - not in Chrome, nor in Firefox and Safari.

@Mirko 

Did you get it working somehow?

Btw. I don't got any packet loss - the browser receives packages but is unable to decode. Chrome still says:

Trying to create decoder for unsupported format

[Lorenzo Miniero]

Then none of those codecs or packetization mechanisms are supported by browsers. You'll probably have to transcode the media yourself and pass it to the Streaming plugin.

Lorenzo

[Mykola Mokhnach]

What if you set the cam resolution to the minimum possible value? 

Also, which encoder is used on client side? Is it possible to fine-tune encoder parameters?

[Sebastian Schmid]

Lorenzo Miniero:

Then none of those codecs or packetization mechanisms are supported by browsers. You'll probably have to transcode the media yourself and pass it to the Streaming plugin.

I went a bit deeper into H264 profiles and related Chrome and Firefox tickets. I am not sure if lack of codec support on the browse side really is the problem, because:

#1

- Rewriting the profile-level-id from 42009 to 42e01f should work (RTP should be the same), as confirmed by FF development

- see: https://groups.google.com/forum/#!topic/mozilla.dev.media/Ye29vuMTpo8

#2 

- Chrome should already support decoding not only the Constrained Baseline, but also the Baseline and the High profile.

- When offered with 640029 (High) then answers with the identical profile id to indicate it is supported - but still no visible video

- see https://bugs.chromium.org/p/webrtc/issues/detail?id=8317

#3 

- packetization-mode 1 should not be a problem for Chrome

- see https://bugs.chromium.org/p/chromium/issues/detail?id=600254 

So, assuming that codecs are not the root cause of the problem, I moved on to look at the other warning in the Chrome log:

[39917:8459:0706/195542.129035:WARNING:common_header.cc(43)] Invalid RTCP header: Version must be 2 but was 0

[39917:8459:0706/195542.129087:WARNING:rtcp_receiver.cc(406)] 31 RTCP blocks were skipped due to being malformed or of unrecognized/unsupported type, during the past 10 second period.

I checked with Wireshark, but the RTCP packets from the camera (10.0.0.78) looked OK... May there be a Janus related RTCP issue?

To be complete:

- Transcoding using FFMPEG worked - I then see a Video with the Janus demo (RTP Config). But quality is poor and I am really looking for a solution without transcoding.

- I cannot fine the encoder settings (cam settings are limited)

- Using lower resolutions did not have an effect

Thanks for your help and hints!

[Sebastian Schmid]

Addendum:

My WISENET cam works with H264 "High" Profile (profile-level-id=640032) and Chrome - without any SDP mangling.

[Lorenzo Miniero]

Which seems to confirm the issue is with the other camera. Janus doesn't touch the media, it just relays packets, so nothing we can do about it, especially if profile mangling doesn't help.

L.

On Sat, 6 Jul 2019, 21:26 Sebastian Schmid, <sebastian...@gmail.com> wrote:

Addendum:

My WISENET cam works with H264 "High" Profile (profile-level-id=640032) and Chrome - without any SDP mangling.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/359c8c33-5667-4c12-b029-6f1154ae1c4b%40googlegroups.com.

[Sebastian Schmid]

Hey Lorenzo, thanks four your response. I agree this is a media incompatibility issue between this AXIS cam and the browsers. We also can ignore this RTCP I mentioned earlier, since Chrome also logs that on working video examples.

However, I just realised that no SDP-ANSWER is sent back to the server when using RTSP and therefore, the server does not even know if the clients would like to downgrade the profile or level.

Could we use the RTSP SET_PARAMETER request to tell the server which fmtp / profile-level-id the client would like to receive?

- Sebastian

 

Lorenzo Miniero:

[Lorenzo Miniero]

Il giorno domenica 7 luglio 2019 16:51:00 UTC+2, Sebastian Schmid ha scritto:

Hey Lorenzo, thanks four your response. I agree this is a media incompatibility issue between this AXIS cam and the browsers. We also can ignore this RTCP I mentioned earlier, since Chrome also logs that on working video examples.

However, I just realised that no SDP-ANSWER is sent back to the server when using RTSP and therefore, the server does not even know if the clients would like to downgrade the profile or level.

Could we use the RTSP SET_PARAMETER request to tell the server which fmtp / profile-level-id the client would like to receive?

Not familiar enough with RTSP to know if that's an option, sorry. Pull requests always welcome, of course!
Lorenzo

[Sebastian Schmid]

Lorenzo Miniero:

Il giorno domenica 7 luglio 2019 16:51:00 UTC+2, Sebastian Schmid ha scritto:

Could we use the RTSP SET_PARAMETER request to tell the server which fmtp / profile-level-id the client would like to receive?

Not familiar enough with RTSP to know if that's an option, sorry. Pull requests always welcome, of course!
Lorenzo

Seems like RTSP does not directly define what kind of parameters can be set with this request type. I have contacted the manufacturer if this is supported by the camera. I'll let you know if I get more info and will try to implement a PR.

- Sebastian

[Anand Setlur]

Sebastian,

The reason you are having troubles with the axis cam is that it does not send the SPS/PPS packets periodically in-band. It only sends it as part of the RTSP DESCRIBE response at the start

If you are using ffmpeg, you can instruct it to relay the sps/pps information in the h264 bitstream without transcoding using the bitstream filter flag (-bsf dump_extra)

ffmpeg -i axis_input_rtsp_url -an -c:v copy -flags global_header -bsf dump_extra -f rtp rtp://ipaddress:port

[Sebastian Schmid]

Dear Anand,

Awesome! This did the trick. The Axis cam now works fine with the Janus streaming demo, and FFMPEG only runs at 0.3% CPU 

Thanks a lot!

Anand Setlur:

[Sebastian Schmid]

Hello all,

I got additional feedback from Axis. The camera can be configured to send PPS and SPS inband:

"Go to Plain config and enable the parameter Image.I0.MPEG.H264.PSEnabled"

When enabled, this will cause the camera to send PPS and SPS inband in the H.264 stream, as well as in the SDP. 

In my case, this worked with Janus using an RTSP streaming configuration -> no FFMPEG required anymore.

Cheerio,

Sebastian