[Ffmpeg-devel] [BUG] RTP header is not stripped out of the avpacket

[Ryan Martell]

Hi Thijs-

On Nov 21, 2006, at 4:20 AM, Thijs Vermeir wrote:
> It looks like ffmpeg is not handling basic rtp.
> I have a RTP stream with the following header ( looks like a valid  
> header):
> 00000000 (0x80fc408): 90 62 d8 0b 00 a3 17 8f c1 2b 21 b2 4c 41 00 08
> 00000010 (0x80fc418): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00000020 (0x80fc428): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> (and here the mpeg4 data starts)
> 00000030 (0x80fc438): 00 00 01 b6 59 f8 48 fb ef be fb ef be fb ef be

What codecs are you using?  The latest svn version (7146) works just  
fine for me with h264/AAC rtp streaming.  I don't know about any of  
the other ones, because I don't have streams to test against.

The first 16 bytes of this header appear to be valid, but then it  
looks broken (unless I'm missing something).

It appears that the extension bit is set, which the rtp code doesn't  
currently handle (meaning immediately following the header there is a  
header extension).  Unfortunately, even if it did handle it, the  
header extension information looks wrong:

    0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      defined by profile       |           length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        header extension                       |
    |                             ....                              |

And in the above example, the length would be zero, which would be  
incorrect.

> When I try to open this stream in ffmpeg this header can still be
> found in the avpackets that are given to the codec, so the decoding
> fails.

I don't see how that would happen; I would expect the first twelve  
bytes to be stripped:

from rtp.c:
     s->seq = seq;
     len -= 12;
     buf += 12;

     if (!st) {
         /* specific MPEG2TS demux support */
,
and then you would get a packet with:

> 00000010 (0x80fc418): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00000020 (0x80fc428): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> (and here the mpeg4 data starts)
> 00000030 (0x80fc438): 00 00 01 b6 59 f8 48 fb ef be fb ef be fb ef be

Which is still wrong, but not quite what you said was happening. ;-)

Hope that helps some,
-Ryan