RTSP camera / Firefox-edge-safari problems

[Anton Smith]

Hi,

We have been experimenting with Janus a lot and are using it to provide streaming from a RTSP/H.264 cameras (Hikvision) to WebRTC.

So far we have it working ONLY with Chrome and it works perfectly.

But on the following devices/browsers it doesn't work:

• Firefox, PC or mac - error video doesnt start, "spinning wheel, loading"
  
• Edge, PC error video doesnt start, "spinning wheel, loading"
• Safari, iOS - no webrtc support error
  
• Chrome, iOS - no webrtc support error
• Bowser, iOS - no webrtc support error

I have confirmed that it is NOT a codec problem, even though the profile is MAIN, because I loaded a .mp4 with the exact same codec successfully in firefox using HTML5 tag with local .mp4 file, worked perfectly. Our cameras do not support changing the profile from MAIN.

The SDPs seem to have a discrepancy between the browsers:

FIREFOX:

Remote SDP (janus):

a=fmtp:96 profile-level-id=420029;

CHROME:

Remote SDP (janus):

a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

What is weird about this is that the streaming plugin is configured as per the Chrome reported Remote SDP. It's the EXACT same streaming plugin configuration.

Firefox's local SDP just indicates rejected:

m=video 0 RTP/SAVPF 120
c=IN IP4 0.0.0.0
a=inactive
a=rtpmap:120 VP8/90000

NOTE: I have applied all relevant fixes to firefox configuration to enable H264 and to prefer it over VP8, it doesn't make a difference, to be honest I think it doesn't get that far. The profile-level-id seems to be incorrectly sent from Janus with the wrong value when FF is in use.

Config:

streaming plugin:

[rtsp-test]
type = rtsp
id = 99
description = RTSP Test
audio = no
video = yes
videopt = 96
videortpmap = H264:90000
videofmtp = profile-level-id=42e01f\;packetization-mode=1;level-asymmetry-allowed=1
url=rtsp://a.b.c.d/Streaming/Channels/1
rtsp_user=admin
rtsp_pwd=abcd

Note, have tried this with/without specifying videoopt, videofmtp, videortpmap. Makes no difference: chrome always works, firefox doesn't.

We do see an "ICE failed" in the firefox web console, but I can't figure out how to see the rest of ICE debug in FF. My suspicion is this has something to do with ICE, but I can't figure it out. I've read this issue: https://github.com/meetecho/janus-gateway/issues/83 but it sounds like you fixed the trickle issues you had before. Our FF version is 50+, in particular 50.1.0.

[Mirko Brankovic]

Well if ice failed you won't get the rtp flow.

You can try to introduce the Turn server to make sure you get the flow going (coturn on 80/443 port for example)

I recently had issue where I wanted to mimic Enterprise firewall (blocking all In/Out UDP traffic) and using Coturn to get ICE Stun/Turn candidates and ICE kept failing because srlfx candidates were selected instead of relay ones, I'm not sure why they passed the test when UDP is blocked.

Maybe you have also UPD traffic filtered from network where you start PeerConnection? 

--
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-janus+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Anton Smith]

Here's some debug from Janus:

https://gist.github.com/anonymous/1fab6b94f90d925fbb57216f2c603f32

Firefox just seems to "blank" janus, even though Janus sends what I think should be valid SDPs (with the exception of the profile-level being different). And it never sends any valid candidates back to Janus, just rejection.

[Anton Smith]

Hi Mirko,

we have tried it on local LAN as well and it still fails. Note that Chrome works, and I don't think TURN is necessary as we are not using symmetric NAT in any location.

My suspicion is FF doesn't like something about the SDPs it sees coming from Janus and just throws back a rejection immediately (you can see the Janus debug output in my previous message).

Regards,
Anton

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Lorenzo Miniero]

Janus doesn't send different SDPs to different clients/browser. The reason why you see a different SDP in Firefox is because you're probably looking at about:webrtc, which presents an SDP rewritten by Firefox according to what it parsed. To see what we received and sent, refer to the Admin API instead:

http://www.meetecho.com/blog/understanding-the-janus-admin-api/

I have no idea how main and baseline profiles differ, but AFAIK only support for baseline profiles is mandated. Anything higher than that is not guaranteed to work, and that's not something you can blame on Janus (we relay what you send). You should probably ask mozilla.dev.media why decoding is failing there: there probably are debugging flags you can use for that.

If ICE is failing, then it's not a matter of codecs at all, but something different. Again, look at the Admin API to see why that's happening, The link I gave you above provides some tutorial on how to look at the info there.

Lorenzo

[Anton Smith]

Thanks Lorenzo,

ICE is indeed failing, but I cannot figure out why. I tested STUN works in general with FF by going to https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ - worked well.

I have been using the admin page, and what I see is just that candidate state is stuck in "gathering" and that the local components look fine (i.e. janus server is getting valid candidates).

Remote candidates is just empty, and of course no DTLS information populated.

Debug logs for FF show that when going to e.g. the test page above, a lot of activity is generated as it generates candidates etc. But when using Janus it doesn't do much. Here you can see an example where first I test the URL above, lot of activity, and at the very bottom of the file in the last 10 lines or so you can see when I try to open my janus streaming test page - it has two candidates that are not valid.

https://gist.github.com/anonymous/b759063819b120729e6e6935cc427d30

I don't think there is anything wrong with Janus, so please don't take it that way. I've been diving as much as possible into the code, read the docs, and read every single thread about FF and Janus, tried basically everything.

Just so I understand, how does Janus interact with the browser for doing ICE? Does the browser do it, after Janus asks it to via. an API, or is the ICE actually implemented in Janus javascript files itself?

[Mirko Brankovic]

Browser should be gathering candidates as soon as you call peerconnection.createOffer and inside of it pc.setLocalDestription. they will be triggered on event handler pc.onicecandidate.

Are you sending them with 'trickle' method, as they are gathered or old way, gather all and send offer? 

If you send them one by one make sure you catch endOfCandidates and send that one too as {handle_id: handle, completed: true} 

Sorry of this is something you already know and im in wrong path here.

But last cand i see in   that log was type: null which was wired and i suspected this ;)

--

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-janus+unsubscribe@googlegroups.com.

[Anton Smith]

you mean the cands that have type "unknown"?

Regards,
Anton

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

[Anton Smith]

I think the code already does what you suggest in janus.js, when the event candidate is null it means nore more candidates, the logic statement here seems to catch that, and it sends what you described:

 

                       if (event.candidate == null ||
1275                                         (adapter.browserDetails.browser === 'edge' && event.candidate.candidate.indexOf('endOfCandidates') > 0)) {
1276                                 Janus.log("End of candidates.");
1277                                 config.iceDone = true;
1278                                 if(config.trickle === true) {
1279                                         // Notify end of candidates
1280                                         sendTrickleCandidate(handleId, {"completed": true});
1281                                 } else {
1282                                         // No trickle, time to send the complete SDP (including all candidates)
1283                                         sendSDP(handleId, callbacks);
1284                                 }

Rgds Anton

On Thursday, January 26, 2017 at 10:20:18 PM UTC+1, Mirko Brankovic wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

[Mirko Brankovic]

Oh oki,

Maybe you can test with some older version of FF if possible to rule that out?

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.

[Lorenzo Miniero]

Do you see the remote SDP in the Admin API, or is it missing as well? If so, Firefox may be barfing on the offer for some reason and throwing an error. If the SDP is there but the candidates aren't, good chances are Firefox is not sending any for some reason: a look at about:webrtc may tell you more.

L.

[Anton Smith]

Hi Lorenzo,

It's there, but it's just a rejection and contains m=video 0 RTP/SAVPF 120.

I have done some more digging and discovered a few things:

1) FF does NOT like profile-level-id 420029
2) If I transcode the h264 stream from my camera using FFMPEG and present it as RTP to Janus, then FF successfully negotiates everything, all ICE, SDPs etc look ok. When I transcode, I map it to 42e01f.
3) As I mentioned earlier, Chrome just sends back 42e01f in the answer, and things just work.
4) Janus doesn't allow me to override the profile-level-id, I have it set to 42e01f but it still sends 420029. I don't know if this is intended behaviour or not, but if I can find a way to override this and force 42e01f it may provide a solution

I also found this on the mozilla  dev media group that may explain it. It says you can't answer profile-level 42e0xx  with profile-level 4200xx, it's similar to my problem but back to front - I'm sending 4200xx and the other side doesn't like it. Chrome seems to break this RFC and just answers with 42e0xx anyway, and it works.

RFC 6184 8.2.2:

    o  The parameters identifying a media format configuration for H.264
       are profile-level-id and packetization-mode.  These media format
       configuration parameters (except for the level part of profile-
       level-id) MUST be used symmetrically; that is, the answerer MUST
       either maintain all configuration parameters or remove the media
       format (payload type) completely if one or more of the parameter
       values are not supported.  Note that the level part of profile-
       level-id includes level_idc, and, for indication of Level 1b when
       profile_idc is equal to 66, 77, or 88, bit 4
       (constraint_set3_flag) of profile-iop.  The level part of profile-
       level-id is changeable.

i.e. you can't answer profile-level-id=42e0xx with 4200xx - they don't
match.  Many H264 impls ignore the constraint bits and hope things just
work.   As it's invalid, we should probably call the error callback, but
I think instead it just didn't start send or receive for video.

Also: I would generally suggest using Mode 1 and not mode 0.  While it
may not matter (most implementations that support both handle this) but
mode 0 has a bug where we send SPS/PPS in a STAP-A packet (which is
mode-1 only).

    Randell Jesup

[Anton Smith]

Tried 40.0, same problem, thanks for the suggestion. I'm convinced it's something with FF silently rejecting the SDP given to it and related to the signalled codec, but not the codec itself. In my original post here, I said I could play a .mp4 saved from the same source with no transcoding in HTML5 tag in FF, so it's capable of playing the content, it's just barfing (quietely) on the signalling of the content ...

I haven't spent any time investigating Edge yet, only that it doesn't work.

[Lorenzo Miniero]

Il giorno venerdì 27 gennaio 2017 14:44:18 UTC+1, Anton Smith ha scritto:

Hi Lorenzo,

It's there, but it's just a rejection and contains m=video 0 RTP/SAVPF 120.

I have done some more digging and discovered a few things:

1) FF does NOT like profile-level-id 420029
2) If I transcode the h264 stream from my camera using FFMPEG and present it as RTP to Janus, then FF successfully negotiates everything, all ICE, SDPs etc look ok. When I transcode, I map it to 42e01f.
3) As I mentioned earlier, Chrome just sends back 42e01f in the answer, and things just work.
4) Janus doesn't allow me to override the profile-level-id, I have it set to 42e01f but it still sends 420029. I don't know if this is intended behaviour or not, but if I can find a way to override this and force 42e01f it may provide a solution

Janus and the Streaming plugin have no idea what 420029 or 42e01f are (they're nowhere in the code) so it's definitely not Janus that is preventing you to do that or messing with the SDP. Make sure you're escaping all the semicolons and not just the first one in the fmtp when configuring the mountpoint. Besides, if you're changing the configuration file you need to restart Janus for it to have effect. If you don't want to do that, you have to destroy the mountpoint and create a new one via Streaming plugin API.

  

I also found this on the mozilla  dev media group that may explain it. It says you can't answer profile-level 42e0xx  with profile-level 4200xx, it's similar to my problem but back to front - I'm sending 4200xx and the other side doesn't like it. Chrome seems to break this RFC and just answers with 42e0xx anyway, and it works.

The difference is not in what Chrome answers with. Chrome probably supports the profile you're negotiating (and whatever profile it puts in the answer we ignore anyway, so we don't care), while Firefox doesn't. As I said, with WebRTC you're very much constrained in which flavour of H.264 you can use.

L.

[Anton Smith]

Hi,

On Friday, January 27, 2017 at 2:51:36 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 14:44:18 UTC+1, Anton Smith ha scritto:

Hi Lorenzo,

It's there, but it's just a rejection and contains m=video 0 RTP/SAVPF 120.

I have done some more digging and discovered a few things:

1) FF does NOT like profile-level-id 420029
2) If I transcode the h264 stream from my camera using FFMPEG and present it as RTP to Janus, then FF successfully negotiates everything, all ICE, SDPs etc look ok. When I transcode, I map it to 42e01f.
3) As I mentioned earlier, Chrome just sends back 42e01f in the answer, and things just work.
4) Janus doesn't allow me to override the profile-level-id, I have it set to 42e01f but it still sends 420029. I don't know if this is intended behaviour or not, but if I can find a way to override this and force 42e01f it may provide a solution

Janus and the Streaming plugin have no idea what 420029 or 42e01f are (they're nowhere in the code) so it's definitely not Janus that is preventing you to do that or messing with the SDP. Make sure you're escaping all the semicolons and not just the first one in the fmtp when configuring the mountpoint. Besides, if you're changing the configuration file you need to restart Janus for it to have effect. If you don't want to do that, you have to destroy the mountpoint and create a new one via Streaming plugin API.

Yes, I've been restarting Janus (it's a test setup). I've tried escaping all semicolons, and only having the profile-level in the line. If Janus doesn't care about what these levels are, what does the configuration option for videofmtp do in the streaming plugin configuration? I did try looking through the code and noted that janus doesn't set any values explicitly itself, but could you point me to the part where you take the videofmtp config and set the values in the SDP? (I tried looking and couldn't find it. Maybe I am a bit tired, I've been banging my head on this for over 24 hours). It may not work with FF anyway, but I want to see if it throws some different errors if I set it manually to 42e01f.

And while I would tend to agree with you that it seems like something that Chrome supports and FF doesn't, I can't understand why FF can play a file with the same codec when wrapped in normal HTML5 video tag (to do this, I simply used ffmpeg and wrote out some of the RTSP based stream to a .mp4 file).
 

[Lorenzo Miniero]

Il giorno venerdì 27 gennaio 2017 16:12:30 UTC+1, Anton Smith ha scritto:

Hi,

On Friday, January 27, 2017 at 2:51:36 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 14:44:18 UTC+1, Anton Smith ha scritto:

Hi Lorenzo,

It's there, but it's just a rejection and contains m=video 0 RTP/SAVPF 120.

I have done some more digging and discovered a few things:

1) FF does NOT like profile-level-id 420029
2) If I transcode the h264 stream from my camera using FFMPEG and present it as RTP to Janus, then FF successfully negotiates everything, all ICE, SDPs etc look ok. When I transcode, I map it to 42e01f.
3) As I mentioned earlier, Chrome just sends back 42e01f in the answer, and things just work.
4) Janus doesn't allow me to override the profile-level-id, I have it set to 42e01f but it still sends 420029. I don't know if this is intended behaviour or not, but if I can find a way to override this and force 42e01f it may provide a solution

Janus and the Streaming plugin have no idea what 420029 or 42e01f are (they're nowhere in the code) so it's definitely not Janus that is preventing you to do that or messing with the SDP. Make sure you're escaping all the semicolons and not just the first one in the fmtp when configuring the mountpoint. Besides, if you're changing the configuration file you need to restart Janus for it to have effect. If you don't want to do that, you have to destroy the mountpoint and create a new one via Streaming plugin API.

Yes, I've been restarting Janus (it's a test setup). I've tried escaping all semicolons, and only having the profile-level in the line. If Janus doesn't care about what these levels are, what does the configuration option for videofmtp do in the streaming plugin configuration? I did try looking through the code and noted that janus doesn't set any values explicitly itself, but could you point me to the part where you take the videofmtp config and set the values in the SDP? (I tried looking and couldn't find it. Maybe I am a bit tired, I've been banging my head on this for over 24 hours). It may not work with FF anyway, but I want to see if it throws some different errors if I set it manually to 42e01f.

videofmtp is something we manually add as a=fmtp: for video in the SDP. Since codecs may differ, we let developers choose what should be there (in this case to describe H.264). This is what we specify in the H.264 example as well, for instance:

https://github.com/meetecho/janus-gateway/blob/master/conf/janus.plugin.streaming.cfg.sample.in#L93

Anyway, please beware that this only applies to plain RTP mountpoints, that is mountpoints you feed yourself by sending RTP packets to the ports you configured. Since you mentioned RTSP cameras in your title, if you're having Janus connect via RTSP to your camera then settings like videofmtp will be ignored, as the whole SDP template that is used is whatever the camera sends in the SDP the RTSP answer contains. For RTSP mountpoints the whole configuration is basically automatically generated out of the negotiation with the RTSP server. Not sure if this is what is happening in your tests?

 

And while I would tend to agree with you that it seems like something that Chrome supports and FF doesn't, I can't understand why FF can play a file with the same codec when wrapped in normal HTML5 video tag (to do this, I simply used ffmpeg and wrote out some of the RTSP based stream to a .mp4 file).
 

The WebRTC media stack in browsers is separated from the simple decoding stuff used for file-based playout. For WebRTC, Firefox uses openH264 as an external library to encode/decode H.264, while for MP4 I guess something else is used.

Lorenzo

[Anton Smith]

On Friday, January 27, 2017 at 4:33:00 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 16:12:30 UTC+1, Anton Smith ha scritto:

Hi,

On Friday, January 27, 2017 at 2:51:36 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 14:44:18 UTC+1, Anton Smith ha scritto:

Hi Lorenzo,

It's there, but it's just a rejection and contains m=video 0 RTP/SAVPF 120.

I have done some more digging and discovered a few things:

1) FF does NOT like profile-level-id 420029
2) If I transcode the h264 stream from my camera using FFMPEG and present it as RTP to Janus, then FF successfully negotiates everything, all ICE, SDPs etc look ok. When I transcode, I map it to 42e01f.
3) As I mentioned earlier, Chrome just sends back 42e01f in the answer, and things just work.
4) Janus doesn't allow me to override the profile-level-id, I have it set to 42e01f but it still sends 420029. I don't know if this is intended behaviour or not, but if I can find a way to override this and force 42e01f it may provide a solution

Janus and the Streaming plugin have no idea what 420029 or 42e01f are (they're nowhere in the code) so it's definitely not Janus that is preventing you to do that or messing with the SDP. Make sure you're escaping all the semicolons and not just the first one in the fmtp when configuring the mountpoint. Besides, if you're changing the configuration file you need to restart Janus for it to have effect. If you don't want to do that, you have to destroy the mountpoint and create a new one via Streaming plugin API.

Yes, I've been restarting Janus (it's a test setup). I've tried escaping all semicolons, and only having the profile-level in the line. If Janus doesn't care about what these levels are, what does the configuration option for videofmtp do in the streaming plugin configuration? I did try looking through the code and noted that janus doesn't set any values explicitly itself, but could you point me to the part where you take the videofmtp config and set the values in the SDP? (I tried looking and couldn't find it. Maybe I am a bit tired, I've been banging my head on this for over 24 hours). It may not work with FF anyway, but I want to see if it throws some different errors if I set it manually to 42e01f.

videofmtp is something we manually add as a=fmtp: for video in the SDP. Since codecs may differ, we let developers choose what should be there (in this case to describe H.264). This is what we specify in the H.264 example as well, for instance:

https://github.com/meetecho/janus-gateway/blob/master/conf/janus.plugin.streaming.cfg.sample.in#L93

Anyway, please beware that this only applies to plain RTP mountpoints, that is mountpoints you feed yourself by sending RTP packets to the ports you configured. Since you mentioned RTSP cameras in your title, if you're having Janus connect via RTSP to your camera then settings like videofmtp will be ignored, as the whole SDP template that is used is whatever the camera sends in the SDP the RTSP answer contains. For RTSP mountpoints the whole configuration is basically automatically generated out of the negotiation with the RTSP server. Not sure if this is what is happening in your tests?

Yes, that's right. It's an RTSP based camera, so your description matches what is happening.
 

 

 

And while I would tend to agree with you that it seems like something that Chrome supports and FF doesn't, I can't understand why FF can play a file with the same codec when wrapped in normal HTML5 video tag (to do this, I simply used ffmpeg and wrote out some of the RTSP based stream to a .mp4 file).
 

The WebRTC media stack in browsers is separated from the simple decoding stuff used for file-based playout. For WebRTC, Firefox uses openH264 as an external library to encode/decode H.264, while for MP4 I guess something else is used.

OK - that would explain the discrepancy. I have a thread now on the FF media dev google group, I will report back what I find. Thank you ever so much for your time and patience.

Regards,
Anton
 

[Lorenzo Miniero]

Il giorno venerdì 27 gennaio 2017 16:53:48 UTC+1, Anton Smith ha scritto:

On Friday, January 27, 2017 at 4:33:00 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 16:12:30 UTC+1, Anton Smith ha scritto:

Hi,

On Friday, January 27, 2017 at 2:51:36 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 14:44:18 UTC+1, Anton Smith ha scritto:

Hi Lorenzo,

It's there, but it's just a rejection and contains m=video 0 RTP/SAVPF 120.

I have done some more digging and discovered a few things:

1) FF does NOT like profile-level-id 420029
2) If I transcode the h264 stream from my camera using FFMPEG and present it as RTP to Janus, then FF successfully negotiates everything, all ICE, SDPs etc look ok. When I transcode, I map it to 42e01f.
3) As I mentioned earlier, Chrome just sends back 42e01f in the answer, and things just work.
4) Janus doesn't allow me to override the profile-level-id, I have it set to 42e01f but it still sends 420029. I don't know if this is intended behaviour or not, but if I can find a way to override this and force 42e01f it may provide a solution

Janus and the Streaming plugin have no idea what 420029 or 42e01f are (they're nowhere in the code) so it's definitely not Janus that is preventing you to do that or messing with the SDP. Make sure you're escaping all the semicolons and not just the first one in the fmtp when configuring the mountpoint. Besides, if you're changing the configuration file you need to restart Janus for it to have effect. If you don't want to do that, you have to destroy the mountpoint and create a new one via Streaming plugin API.

Yes, I've been restarting Janus (it's a test setup). I've tried escaping all semicolons, and only having the profile-level in the line. If Janus doesn't care about what these levels are, what does the configuration option for videofmtp do in the streaming plugin configuration? I did try looking through the code and noted that janus doesn't set any values explicitly itself, but could you point me to the part where you take the videofmtp config and set the values in the SDP? (I tried looking and couldn't find it. Maybe I am a bit tired, I've been banging my head on this for over 24 hours). It may not work with FF anyway, but I want to see if it throws some different errors if I set it manually to 42e01f.

videofmtp is something we manually add as a=fmtp: for video in the SDP. Since codecs may differ, we let developers choose what should be there (in this case to describe H.264). This is what we specify in the H.264 example as well, for instance:

https://github.com/meetecho/janus-gateway/blob/master/conf/janus.plugin.streaming.cfg.sample.in#L93

Anyway, please beware that this only applies to plain RTP mountpoints, that is mountpoints you feed yourself by sending RTP packets to the ports you configured. Since you mentioned RTSP cameras in your title, if you're having Janus connect via RTSP to your camera then settings like videofmtp will be ignored, as the whole SDP template that is used is whatever the camera sends in the SDP the RTSP answer contains. For RTSP mountpoints the whole configuration is basically automatically generated out of the negotiation with the RTSP server. Not sure if this is what is happening in your tests?

Yes, that's right. It's an RTSP based camera, so your description matches what is happening.
 

Then in order to get it to work you have to either make the camera send a different fmtp, or edit the SDP in JavaScript before passing it to the browser in setRemoteDescription (in janus.js terms, before calling handleRemoteJsep), e.g., by doing a simple string replace on the profile code.

L.

[Anton Smith]

On Friday, January 27, 2017 at 5:00:15 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 16:53:48 UTC+1, Anton Smith ha scritto:

On Friday, January 27, 2017 at 4:33:00 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 16:12:30 UTC+1, Anton Smith ha scritto:

Hi,

On Friday, January 27, 2017 at 2:51:36 PM UTC+1, Lorenzo Miniero wrote:

Il giorno venerdì 27 gennaio 2017 14:44:18 UTC+1, Anton Smith ha scritto:

Hi Lorenzo,

It's there, but it's just a rejection and contains m=video 0 RTP/SAVPF 120.

I have done some more digging and discovered a few things:

1) FF does NOT like profile-level-id 420029
2) If I transcode the h264 stream from my camera using FFMPEG and present it as RTP to Janus, then FF successfully negotiates everything, all ICE, SDPs etc look ok. When I transcode, I map it to 42e01f.
3) As I mentioned earlier, Chrome just sends back 42e01f in the answer, and things just work.
4) Janus doesn't allow me to override the profile-level-id, I have it set to 42e01f but it still sends 420029. I don't know if this is intended behaviour or not, but if I can find a way to override this and force 42e01f it may provide a solution

Janus and the Streaming plugin have no idea what 420029 or 42e01f are (they're nowhere in the code) so it's definitely not Janus that is preventing you to do that or messing with the SDP. Make sure you're escaping all the semicolons and not just the first one in the fmtp when configuring the mountpoint. Besides, if you're changing the configuration file you need to restart Janus for it to have effect. If you don't want to do that, you have to destroy the mountpoint and create a new one via Streaming plugin API.

Yes, I've been restarting Janus (it's a test setup). I've tried escaping all semicolons, and only having the profile-level in the line. If Janus doesn't care about what these levels are, what does the configuration option for videofmtp do in the streaming plugin configuration? I did try looking through the code and noted that janus doesn't set any values explicitly itself, but could you point me to the part where you take the videofmtp config and set the values in the SDP? (I tried looking and couldn't find it. Maybe I am a bit tired, I've been banging my head on this for over 24 hours). It may not work with FF anyway, but I want to see if it throws some different errors if I set it manually to 42e01f.

videofmtp is something we manually add as a=fmtp: for video in the SDP. Since codecs may differ, we let developers choose what should be there (in this case to describe H.264). This is what we specify in the H.264 example as well, for instance:

https://github.com/meetecho/janus-gateway/blob/master/conf/janus.plugin.streaming.cfg.sample.in#L93

Anyway, please beware that this only applies to plain RTP mountpoints, that is mountpoints you feed yourself by sending RTP packets to the ports you configured. Since you mentioned RTSP cameras in your title, if you're having Janus connect via RTSP to your camera then settings like videofmtp will be ignored, as the whole SDP template that is used is whatever the camera sends in the SDP the RTSP answer contains. For RTSP mountpoints the whole configuration is basically automatically generated out of the negotiation with the RTSP server. Not sure if this is what is happening in your tests?

Yes, that's right. It's an RTSP based camera, so your description matches what is happening.
 

Then in order to get it to work you have to either make the camera send a different fmtp, or edit the SDP in JavaScript before passing it to the browser in setRemoteDescription (in janus.js terms, before calling handleRemoteJsep), e.g., by doing a simple string replace on the profile code.

IT WORKS!!! Wow, I'm so happy right now!

OK for the record, this is what I did. I know it could be a bit tidier.

So obviously FF is just parsing for the profile-level-id and discarding it without even trying the video.

Thank you Lorenzo!

 

                // Create offer/answer now
                 if(jsep === null || jsep === undefined) {
                         createOffer(handleId, media, callbacks);
                 } else {
                         if(adapter.browserDetails.browser === "edge") {
                                 // This is Edge, add an a=end-of-candidates at the end
                                 jsep.sdp += "a=end-of-candidates\r\n";
                         }
                         var oldsdp = jsep["sdp"];
                         var pattern=/420029/gi;
                         var newsdp = oldsdp.replace(pattern,"42e01f");
                         Janus.log(newsdp);
                         jsep["sdp"]=newsdp;
                         config.pc.setRemoteDescription(
                                         new RTCSessionDescription(jsep),
                                         function() {
                                                 Janus.log("Remote description accepted!");
                                                 createAnswer(handleId, media, callbacks);
                                         }, callbacks.error);
                 }
         }

 

[daniel]

Hello!

I'm now in the same situation:
Having an IP camera which sends 42009 as profile-level-id.
Although it seems Janus now overrides everything with the defined values in janus.plugin.streaming.cfg.

So I could easily defined

[rtsp-test]
type = rtsp
id = 4
description = RTSP
url = rtsp://admin:ad...@a.b.c.d:554/11

audio = no
video = yes
videopt = 96

videortpmap = H264/90000
videofmtp = profile-level-id=42e01f\;packetization-mode=1\;sprop-parameter-sets=Z00AKpWoHgCJ+VA=,aO48gA==
secret = adminpwd

Both FF and Chrome are recieving 42e01f as level-id, however neither of them can play the stream.

I'm really wondering if the whole world have been changed since 1 year? I did not find any browser that could play this camera stream.
(Linux FF, Chrome, Win FF, Chrome).

They only display a white box instead of the video.

ps.: my RTSP camera feed is fine, working flawless in VLC.
What else can I try? (Also have tried your modification, Anton.


Thank you!

[Anton Smith]

Quick tip: change the resolution on your camera to 720p and try again

Sent from my iPhone

You received this message because you are subscribed to a topic in the Google Groups "meetecho-janus" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meetecho-janus/jKg5u9421kM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meetecho-janu...@googlegroups.com.

[daniel]

Thanks for the tip, that was my first thing to setup when started working with Janus:

Media settings from the Camera:

Resolution: 1280x720
Bitrate: 1024
Maximum Frame: 25
Bit Rate Type: Constant bitrate
I Frame Gap: 25

[Anton Smith]

Try also changing frame rate to eg 10. I have a new post here that you should read.

It has to do with what the browsers accept in terms of codecs and levels/profiles. It doesn’t matter what Janus tells them in the SDP, the decoder or something before the decoder in the browser needs to understand how to decode it as well. 

Which camera brand is it?

Regards

Anton

Sent from my iPhone

[daniel]

Ahm. With 10 is also not working in neither browser.

There is a warning upon Janus startup: "The libsrtp installation does not support AES-GCM profiles". I think it's not mandatory.

In Chrome (66.0.3359.117) when I play: "Stream Started 405 kbits/sec". White video screen, spinner is spinning.
In Firefox (59.0.2) when I play: "Stream Started 0x0 407 kbits/sec". White video screen, no spinner, no video.

So the stream is coming through the network, but they can not play it for some wierd reason.

Model is ESCam QD800.


Regards
Thanks,
D

[Anton Smith]

Okay. This means webrtc, ice, etc is all working and the stream is arriving, but the decoder is most likely failing.

Again - find my latest post/thread and read through it.

It might be the PPS/SPS is missing with each key frame. You could fix it using gstreamer or ffmpeg. If you’re using omx on rpi then only gstreamer seems to work atm.

Regards

Anton

Sent from my iPhone

[daniel]

Hello,

I'm so sorry, but this Google Groups are not very user friendly for me.
What I found from you is: https://groups.google.com/forum/#!searchin/meetecho-janus/anton$20smith|sort:date/meetecho-janus/Mwp7JSGIf-0/FnyYcpcqBwAJ
Are you referring to this topic?

I started FFMPEG with this: ffmpeg -i 'rtsp://ip-camera' -an -codec copy -f rtp 'rtp://127.0.0.1:20000'

Same situation. FF sees the stream, but nothing is displayed.
I waited 45 mins. Don't think keyframes are not generated in this interval :)

(Ofc, I use an RTP streaming plugin with FFMPEG.)

L.

Lorenzo

 

<div style="background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wid

[Anton Smith]

https://groups.google.com/forum/m/#!topic/meetecho-janus/Mwp7JSGIf-0

Sent from my iPhone

--

[Dániel Körmendi]

Yepp I saw this thread too.

The thing is that it does not matter if I restart FFMPEG, the stream does not get displayed.

I don't get why is it that difficult, sorry :) 

[daniel]

Is this the right way to use FFMPEG?

ffmpeg -i 'rtsp://ip-camera' -an -codec copy -f rtp 'rtp://127.0.0.1:20000'

Should it fix anything?

On Friday, April 27, 2018 at 8:54:13 PM UTC+2, daniel wrote:

Yepp I saw this thread too.

The thing is that it does not matter if I restart FFMPEG, the stream does not get displayed.

I don't get why is it that difficult, sorry :) 

[Sebastian Schmid]

Hello @Anton Smith

Does rewriting the profile-level-id from 42009 to 42e01f still work with your cam and current versions from Chrome or Firefox?

Unfortunately, I got no luck with my IP cam and current browsers...

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

Anton Smith: