decoder sets clock-rate for application/x-rtp wrong?

Fri Dec 5 05:24:14 PST 2014

Hi.

I have now tested thoroughly with the Wowza server serving Live RTSP
streams to GStreamer. The setup is as follows.

FMLE --(RTMP)--> Wowza --(RTSP)--> GStreamer-1.4.4

I have tested with Wowza 3.6.2, 4.1.0 and 4.1.1. For all tested versions of
Wowza, the server set the clock-rate (in the SDP descrion) for audio of the
stream to the sample rate of the audio. The server set the payload type (in
the SDP) to 14 for mpeg audio (MP3) and >= 96 for AAC. So when using a
sample rate of 44100, it sets the clock-rate to 44100 for both MP3 and AAC.
This is in violation with RFC3551 for MP3 because it uses payload type 14.

I have also checked the if the clock-rate is in fact as it says, 44100, and
the clock-rate actually used is verified to be 44100. So as mentioned
earlier, GStreamer fails to play it as the rtpmpadepay only accepts
clock-rate of 90000. Allowing other clock-rates (a smaller violation of
RFC3551) would make GStreamer compatible with Wowza. So unless other RTSP
servers errornously reports a clock-rate different from 90000 for payload
type 14, but actually uses 90000 for clock-rate, allowing a clock-rate
different from 90000 for rtpmpadepay should be safe and make it more
compatible.

That said, when using uridecodebin or rtpsrc, GStreamer still fails to
synchronize audio and video correctly. The audio is played approx. 2
seconds late to the video. Setting some of the parameters for rtspsrc does
not change that. As VLC can play the stream synchronized, either VLC has a
workaround to play the stream in sync or GStreamer has a bug for
synchronizing Live RTSP streams from the Wowza server. Has anybody
experiencing something similar?

Should we open a bug report?

Best regards

Peter Maersk-Moller

On Tue, Dec 2, 2014 at 11:36 PM, Peter Maersk-Moller <pmaersk at gmail.com>
wrote:

> Hi Olivier.
>
> 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
> > wrote:
>
>> Hi,
>> 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
>          parameters>]
>
> 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
> a=rtpmap:14 MPA/44100/2
> a=control:trackID=1
>
> And it should have been
>
> m=audio 0 RTP/AVP 14
> a=rtpmap:14 MPA/90000/2
> a=samplerate=44100
> a=control:trackID=1
>
> or
>
> m=audio 0 RTP/AVP 14
> a=rtpmap:14 MPA/90000/2
> a=fmtp: 14 samplerate=44100
> a=control:trackID=1
>
> RFC4566 is a bit vague on this. Do you have a reference to what is the
> right implementation?
>
>
>>
>> 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
> as entry?
>
> Thanks for the help Olivier.
>
> Regards
> Peter
>
>
>> 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
>> that.
>> >
>> > 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
>> >
>> http://lists.freedesktop.org/archives/gstreamer-devel/2014-November/050612.html
>> >
>> > 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
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141205/068883de/attachment-0001.html>