decoder sets clock-rate for application/x-rtp wrong?
pmaersk at gmail.com
Tue Dec 2 14:36:05 PST 2014
See response in-line. Sorry for the details. I need it for documentation,
if I contact Wowza.
On Tue, Dec 2, 2014 at 9:27 PM, Olivier Crête <olivier.crete at collabora.com>
> In this case, it is a bug in the RTSP server, for MPEG ES streams (MP3)
> it should use 90000 as the RTP clock rate and ignore the actual sample
> rate of the content.
I expect the server does indeed use a clock-rate at 90000 for the rtp time
stamps as defined i http://tools.ietf.org/html/rfc3551#section-4.5.13
Looking at http://tools.ietf.org/html/rfc3555#section-4.1 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.
Looking at https://tools.ietf.org/html/rfc4566#section-6 under rtpmap I see:
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
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)
m=audio 0 RTP/AVP 14
And it should have been
m=audio 0 RTP/AVP 14
m=audio 0 RTP/AVP 14
a=fmtp: 14 samplerate=44100
RFC4566 is a bit vague on this. Do you have a reference to what is the
> Is it in particular very invalid to use payload type 14 with any clock
> rate other than 90000, they should use a 96-128 payload type for MPA
> with a clock-rate thyat is not 90000.
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.
> That said, we care about interop, so I'll relax the caps on rtpmpadepay
> to accept any clock rate.
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).
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.
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
Thanks for the help Olivier.
> On 02/12/14 11:33 AM, Peter Maersk-Moller wrote:
> > Hi.
> > Trying to decode a AV stream from a Wowza server using RTSP, GStreamer
> > 1.4.4 seems to fail finding a suitable decoder, when the stream contain
> > a mpeg audio stream (mpeg version 1 - here MP3). Looking further into
> > the matter, it seems like it is the rtpmpadepay that fail. Now if i use
> > AAC it works.
> > Looking at the capabilities for rtpmpadepay I notice that rtpmpadepay
> > ONLY accepts application/x-rtp input with a clock rate of 90000 which
> > indeed is the clock-rate for payload type 14 according to RFC2250,3551.
> > However, it appear gstreamer uridecodebin (and probably rtspsrc or
> > others) are setting the clock-rate for application/x-rtp from the audio
> > rate description in sdp rather than from payload type. If that is the
> > case, then that is a bug. Most payload types have a specific clock-rate
> > such as payload type 14, which is 90000, but the sample rate can for
> > MPEG1 audio be 32000, 44100 or 48000 and for MPEG2 audio 16000, 22050
> > and 24000. So they should set the parameters
> > 'application/x-rtp,clock-rate=90000,rate=44100' if the sample rate is
> > Part of the sdp file may look like this
> > m=audio 0 RTP/AVP 14
> > a=rtpmap:14 MPA/44100/2
> > a=control:trackID=1
> > So rtspsrc (and perhaps others) need to be changed to set clock-rate
> > primarily from the payload types.
> > The reason it works with AAC is that the rtpmp4adepay module accepts a
> > wide range of clock-rates so a clock-rate of 44100 is accepted even
> > though the rtp clock-rate is 90000. Perhaps however, as the clock-rate
> > is set to 44100, this may be the source for the annoying messages about
> > the the computer being slow while plenty of CPU is available. This could
> > also be the reason why playing a live RTSP stream often can lead to
> > very very slow video, but here I am just guessing.
> > The mail about problems for GStreamer playing live streams may be found
> > here
> > Would be nice if we can find the source of why GStreamer have problems
> > playing live streams.
> > best regards
> > Peter
> > . And indeed for AAC, rtsp
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> Olivier Crête
> olivier.crete at collabora.com
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel