On Monday, January 30, 2017 at 2:35:54 AM UTC+1, Randell Jesup wrote:
> On 1/27/2017 2:27 PM, an...@huge.geek.nz wrote:
> > On Friday, January 27, 2017 at 3:27:15 PM UTC+1, an...@huge.geek.nz wrote:
> >
> > I've been struggling with using WebRTC together with Janus.
> >
> > I have an h264 camera that I can't alter the configuration for.
> >
> > The profile-level-id seems to be 420029, which means:
> > profile is baseline (42 hex = 66 dec = baseline)
> > constraints 0
> > level-idc is 4.1
> >
> > ICE never completes because I suspect FF just barfs on this for some
> > reason, and I couldn't, no matter how much debug I enabled, find where or
> > why specifically.
> >
> > Chrome works perfectly, but not before offering back profile-id 42e01f
> > (which the main difference is level-idc is 3.1 instead of 4.1).
> >
> > When I re-encoded the content using FFMPEG using an intermediate device,
> > setting exactly 42e01f then FF finished ICE and played the video (although
> > this is not a valid solution for my purposes)
> >
> > Ideally I want to understand why FF (openh264) can't play 420029, since it
> > should be baseline, and if there is a fix.
> >
> > One more important note: if I took a small clip of the stream to a .mp4
> > file (no transcoding), and embed that in HTML5 video tag, FF plays it
> > perfectly. So the codec SHOULD work as is, but not it doesn't when it's
> > coming over webrtc.
> >
> > Very annoying!
> > Hi all, I managed to "fix" this by rewriting the profile-level-id from
> > 42009 to 42e01f before handing the SDP to FF.
> >
> > I agree it is a hack, but as FF clearly works with this, then why don't you
> > allow 42009?
>
> The WG requirement is for Constrained Baseline, not Baseline, which is
> what we offer/accept. It's the 'e0' portion that causes the problem;
> see RFC 6184 for details on what's compatible for offer/answer. Yes,
> the rules are annoying if you want to support talking to a client that
> doesn't support the same profile you prefer. Officially, to support
> ConstrainedBaseline and Baseline you need to offer both as separate
> payload types (with independent FMTPs).
>
> This is this same thing
> (https://groups.google.com/forum/#!searchin/mozilla.dev.media/4200xx%7Csort:relevance/mozilla.dev.media/9_zkibr_Bus/8LioRaUODAAJ)
>
> that was noted in the Janus list you referenced. And as you mention,
> you can 'cheat' and claim it's constrained baseline even though it's
> not, and in this case it will work. (Not every such edit will --- if
> you tell it the profile is baseline when it's high, it will likely
> fail.) And how well these edits work depend on details of
> implementation of the decoders.
>
> --
> Randell Jesup, mozilla
Thank you Randell,
If I understand you correctly, then FF checks the profile-level-id and checks
the constraint bits. If it doesn't find constrained baseline then it simply
rejects it (according to the RFC), even though the underlying decoder would be
able to play it.
In my scenario, it's an RTSP camera with no options for altering the encoding
options. And then Janus doesn't want to "know" about media or codecs, it just
maps it from RTSP to RTP.
There's only two ways to be "compliant" then:
1) To transcode the stream to constrained baseline (a heavy option ..)
2) During SDP signalling to offer both CBP and BP (not sure how that is done,
do you offer two SDPs?)
For 2), how would Firefox behave? Would it decide it could in fact accept the
BP content, and because standards were followed (two offers), it would work
rather than reject it?
I guess that, the "proper" solution is to encode in the right format in the
first place if you intend to use webrtc/rtp transport.
Regards,
Anton
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
