[prev in list] [next in list] [prev in thread] [next in thread]
List: gstreamer-devel
Subject: Re: webrtcbin, h264 profiles and iOS?
From: Trey Hutcheson <trey.hutcheson () gmail ! com>
Date: 2021-03-28 14:01:15
Message-ID: CAAd3e3P_r=YAJDXkMJrwBTm0hSuoAC1mwiyLDY0404ix7kQ8Mw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Ok so it appears Safari is in fact rejecting the profile 42001f.
When the first webrtcbin instance fires the pad-added signal for the src
pad, the caps show a profile-level-id of 42e01f. We then repayload the
stream (queue ! rtph264depay ! h264parse config-interval=-1 ! rtph264pay)
on its way to the 2nd webrtcbin instance, and the caps on the sink pad end
up having a profile-level-id of 42001f.
Is it h264parse that's modifying the caps? Is there any way to preserve the
profile-level-id here?
On Sat, Mar 27, 2021 at 10:37 AM Trey Hutcheson <trey.hutcheson@gmail.com>
wrote:
> Here's my situation:
> * remote peer (ios) produces an sdp offer with h264. I negotiate with
> webrtcbin, and the remote peer sends in video.
> * a second peer (ios) joins, and my media server creates a new webrtcbin
> instance, and depayloads/repayloads the h264 from the first webrtcbin to
> the 2nd
> * webrtcbin instance 2 creates an offer.
> * the 2nd remote peer rejects the offer with the message: "Failed to set
> remote offer sdp: Failed to set remote video description send parameters'.'
>
> From what I've read, I *believe* the 2nd peer is rejecting the offer
> because of the h264 profile offered by webrtcbin.
>
> The original offer from the video producing peer looks like this (relevant
> parameters):
> a=rtpmap:98 H264/90000
> a=rtcp-fb:98 goog-remb
> a=rtcp-fb:98 transport-cc
> a=rtcp-fb:98 ccm fir
> a=rtcp-fb:98 nack
> a=rtcp-fb:98 nack pli
> a=fmtp:98
> profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
>
> And then when webrtcbin produces the offer for the second peer, it looks
> like this:
> a=rtpmap:98 H264/90000
> a=rtcp-fb:98 nack pli
> a=fmtp:98
> packetization-mode=1;profile-level-id=42001f;sprop-parameter-sets=J0IAH6tAUB7TUCAgKkG0EQjUAA==,KM48MA==
>
> So the video sending peer offered profile level 42e01f. But for the same
> h264 stream, webrtcbin offered profile level 42001f.
>
> What's going on here? What is the correct behavior?
>
> Chrome accepts the offer and plays the video just fine. Safari does not.
>
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Ok so it appears Safari is in fact rejecting the profile 42001f. \
<div><br></div><div>When the first webrtcbin instance fires the pad-added signal for \
the src pad, the caps show a profile-level-id of 42e01f. We then repayload the stream \
(queue ! rtph264depay ! h264parse config-interval=-1 ! rtph264pay) on its way to the \
2nd webrtcbin instance, and the caps on the sink pad end up having a profile-level-id \
of 42001f.</div><div><br></div><div>Is it h264parse that's modifying the caps? Is \
there any way to preserve the profile-level-id here? </div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 27, 2021 at 10:37 \
AM Trey Hutcheson <<a \
href="mailto:trey.hutcheson@gmail.com">trey.hutcheson@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr">Here's my situation: <div>* remote peer (ios) produces an sdp offer \
with h264. I negotiate with webrtcbin, and the remote peer sends in \
video.</div><div>* a second peer (ios) joins, and my media server creates a new \
webrtcbin instance, and depayloads/repayloads the h264 from the first webrtcbin to \
the 2nd</div><div>* webrtcbin instance 2 creates an offer. </div><div>* the 2nd \
remote peer rejects the offer with the message: "Failed to set remote offer sdp: \
Failed to set remote video description send \
parameters'.'</div><div><br></div><div>From what I've read, I *believe* \
the 2nd peer is rejecting the offer because of the h264 profile offered by \
webrtcbin.</div><div><br></div><div>The original offer from the video producing peer \
looks like this (relevant parameters):</div><div>a=rtpmap:98 \
H264/90000<br>a=rtcp-fb:98 goog-remb<br>a=rtcp-fb:98 transport-cc<br>a=rtcp-fb:98 ccm \
fir<br>a=rtcp-fb:98 nack<br>a=rtcp-fb:98 nack pli<br>a=fmtp:98 \
profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1<br></div><div><br></div><div>And \
then when webrtcbin produces the offer for the second peer, it looks like \
this:</div><div>a=rtpmap:98 H264/90000<br>a=rtcp-fb:98 nack pli<br>a=fmtp:98 \
packetization-mode=1;profile-level-id=42001f;sprop-parameter-sets=J0IAH6tAUB7TUCAgKkG0EQjUAA==,KM48MA==<br></div><div><br></div><div>So \
the video sending peer offered profile level 42e01f. But for the same h264 stream, \
webrtcbin offered profile level 42001f.</div><div><br></div><div>What's going on \
here? What is the correct behavior?</div><div><br></div><div>Chrome accepts the offer \
and plays the video just fine. Safari does not. \
</div><div><br></div><div><br></div></div> </blockquote></div>
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic