On Fri, 13 Jul 2012, Adriano Pallavicino wrote:

---
libavformat/sdp.c |    8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 1867225..ec9ec41 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -457,19 +457,19 @@ static char *sdp_write_media_attributes(char *buff, int 
size, AVCodecContext *c,
            }
            break;
        case CODEC_ID_PCM_S16BE:
-            if (payload_type >= RTP_PT_PRIVATE)
+            if (payload_type <= RTP_PT_PRIVATE)
                av_strlcatf(buff, size, "a=rtpmap:%d L16/%d/%d\r\n",
                                         payload_type,
                                         c->sample_rate, c->channels);
            break;

Not quite. The RFC says that _if_ something uses the static payload ID, then it also has a certain fixed sample rate and channel. But if you don't use the fixed sample rate and channel numbers, you should not use the static payload ID.

Your change breaks things - if this code (for some reason outside of the scope of this function) uses dynamic payload types, it wouldn't get a rtpmap line at all. That's wrong.

So there's two possible solutions here:

1) Change the check into:
    if (payload_type >= RTP_PT_PRIVATE || c->sample_rate != 441000)

2) Make sure we use a dynamic payload type if we use pcm/mulaw/alaw and the sample rate is != 44100 (or 8000 for alaw/ulaw) or channels != 1. This is the more correct solution IMO, but also a bit more work. (Your modification goes into ff_rtp_get_payload_type in rtp.c in this case.)

@@ -542,7 +542,7 @@ static char *sdp_write_media_attributes(char *buff, int 
size, AVCodecContext *c,
                                         8000, c->channels);
            break;
        case CODEC_ID_ADPCM_G726: {
-            if (payload_type >= RTP_PT_PRIVATE)
+            if (payload_type <= RTP_PT_PRIVATE)
                av_strlcatf(buff, size, "a=rtpmap:%d G726-%d/%d\r\n",
                                         payload_type,

This shouldn't be here, as you noted in patch #2.

// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to