<div dir="ltr"><div>Hi Olivier.<br><br></div>See response in-line. Sorry for the details. I need it for documentation, if I contact Wowza.<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 2, 2014 at 9:27 PM, Olivier Crête <span dir="ltr"><<a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
In this case, it is a bug in the RTSP server, for MPEG ES streams (MP3)<br>
it should use 90000 as the RTP clock rate and ignore the actual sample<br>
rate of the content.<br></blockquote><div><br></div><div>I expect the server does indeed use a clock-rate at 90000 for the rtp time stamps as defined i <a href="http://tools.ietf.org/html/rfc3551#section-4.5.13">http://tools.ietf.org/html/rfc3551#section-4.5.13</a><br><br></div><div>Looking at <a href="http://tools.ietf.org/html/rfc3555#section-4.1">http://tools.ietf.org/html/rfc3555#section-4.1</a> section 4.1.17 it is described that no parameters for MPA (payload type 14 mime type MPA) is required, but it does have an optional parameter named "samplerate" for describing the samplerate.<br><br></div><div>Looking at <a href="https://tools.ietf.org/html/rfc4566#section-6">https://tools.ietf.org/html/rfc4566#section-6</a> under rtpmap I see:<br><div style="margin-left:40px"><pre class="">a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
         parameters>]</pre></div>So it is indeed the clock rate and not the sample rate to be listed in the rtpmap. So the Wowza server had the following in the sdp (RTSP DESCRIBE)<br><br><div style="margin-left:40px">m=audio 0 RTP/AVP 14<br>a=rtpmap:14 MPA/44100/2<br>a=control:trackID=1<br></div><br></div><div>And it should have been<br><br><div style="margin-left:40px">m=audio 0 RTP/AVP 14<br>a=rtpmap:14 MPA/90000/2<br>a=samplerate=44100<br>a=control:trackID=1<br></div><br></div><div>or<br><br><div style="margin-left:40px">m=audio 0 RTP/AVP 14<br>a=rtpmap:14 MPA/90000/2<br>a=fmtp: 14 samplerate=44100<br>a=control:trackID=1<br></div><br></div><div>RFC4566 is a bit vague on this. Do you have a reference to what is the right implementation?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Is it in particular very invalid to use payload type 14 with any clock<br>
rate other than 90000, they should use a 96-128 payload type for MPA<br>
with a clock-rate thyat is not 90000.<br></blockquote><div><br></div><div>True. Many places suggest the clock-rate for many dynamic types should also be 90000, but I can't find any documentation for that so I suspect using any clock-rate for a dynamic type is okay.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
That said, we care about interop, so I'll relax the caps on rtpmpadepay<br>
to accept any clock rate.<br></blockquote><div><br></div><div>I am not sure if it uses a clock-rate different from  90000 even though RTSP DESCRIBE reports 44100 (in this case) as I can't synchronize  audio and video for live RTSP streaming from the Wowza server (VLC can) and most of the time a pipeline with uridecodebin ends up with very slow video (when using H264/AAC). So for interoperability, we need to see if the Wowza server reports 44100 as clock-rate but uses 90000 or reports 44100 and uses 44100 as clock-rate. If it is the first, then for interoperability, detecting payload type 14 should set clock-rate to 90000 no matter what sdp tells you. Allowing other clock-rates for the rtpmpadepay may make things worse as it does when I stream H264/AAC. The rtpmp4adepay does accept a clock-rate of 44100, but sync between audio and video is off with 2.2 secs and most of the time, video is slow and it complains about a slow computer. (Sorry for the rant. Hope you get the meaning).<br><br></div><div>I'm not really sure how to see what clock-rate the stream from the Wowza server actually has. Any suggestion? Can also send a rtsp url if you want to try it your self and don't have access to the Wowza server.<br><br></div><div>I'll try to contact Wowza to see if we can get them to correct their software. Anybody here on the list that has contact with Wowza I could use as entry?<br><br></div><div>Thanks for the help Olivier.<br><br></div><div>Regards<br></div><div>Peter<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Olivier<br>
<div><div class="h5"><br>
On 02/12/14 11:33 AM, Peter Maersk-Moller wrote:<br>
> Hi.<br>
><br>
> Trying to decode a AV stream from a Wowza server using RTSP, GStreamer<br>
> 1.4.4 seems to fail finding a suitable decoder, when the stream contain<br>
> a mpeg audio stream (mpeg version 1 - here MP3). Looking further into<br>
> the matter, it seems like it is the rtpmpadepay that fail. Now if i use<br>
> AAC it works.<br>
><br>
> Looking at the capabilities for rtpmpadepay I notice that rtpmpadepay<br>
> ONLY accepts application/x-rtp input with a clock rate of 90000 which<br>
> indeed is the clock-rate for payload type 14 according to RFC2250,3551.<br>
> However, it appear gstreamer uridecodebin (and probably rtspsrc or<br>
> others) are setting the clock-rate for application/x-rtp from the audio<br>
> rate description in sdp rather than from payload type. If that is the<br>
> case, then that is a bug. Most payload types have a specific clock-rate<br>
> such as payload type 14, which is 90000, but the sample rate can for<br>
> MPEG1 audio be 32000, 44100 or 48000 and for MPEG2 audio 16000, 22050<br>
> and 24000. So they should set the parameters<br>
> 'application/x-rtp,clock-rate=90000,rate=44100' if the sample rate is that.<br>
><br>
> Part of the sdp file may look like this<br>
><br>
> m=audio 0 RTP/AVP 14<br>
> a=rtpmap:14 MPA/44100/2<br>
> a=control:trackID=1<br>
><br>
> So rtspsrc (and perhaps others) need to be changed to set clock-rate<br>
> primarily from the payload types.<br>
><br>
> The reason it works with AAC is that the rtpmp4adepay module accepts a<br>
> wide range of clock-rates so a clock-rate of 44100 is accepted even<br>
> though the rtp clock-rate is 90000. Perhaps however, as the clock-rate<br>
> is set to 44100, this may be the source for the annoying messages about<br>
> the the computer being slow while plenty of CPU is available. This could<br>
> also be the reason why playing a live RTSP stream  often can lead to<br>
> very very slow video, but here I am just guessing.<br>
><br>
> The mail about problems for GStreamer playing live streams may be found<br>
> here<br>
> <a href="http://lists.freedesktop.org/archives/gstreamer-devel/2014-November/050612.html" target="_blank">http://lists.freedesktop.org/archives/gstreamer-devel/2014-November/050612.html</a><br>
><br>
> Would be nice if we can find the source of why GStreamer have problems<br>
> playing live streams.<br>
><br>
> best regards<br>
> Peter<br>
><br>
> . And indeed for AAC, rtsp<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
><br>
<span class=""><font color="#888888"><br>
--<br>
Olivier Crête<br>
<a href="mailto:olivier.crete@collabora.com">olivier.crete@collabora.com</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</font></span></blockquote></div><br></div></div></div></div>