[FFmpeg-devel] RTSP marker-bit packet merging

[Ronald S. Bultje]

Hi Luca,

On Sat, Jan 31, 2009 at 11:13 AM, Luca Barbato <lu_zero at gentoo.org> wrote:
> Ronald S. Bultje wrote:
>> I think I agree on second thought. Attached patch OK to apply?
>
> +    } else if (ioff == *olen) {
>
> It doesn't look right, reading the text doesn't shed much light on this,
> I guess you assume the full rtp packets have the same size. Isn't it?

So I modeled the API after what I see in X-QT and ASF. The ASF payload
header has a "offset or length" bit, and an accompanying value. If the
bit is set, the value is a "length" of the RTP data in the packet
directly after the payload header. Normally these are the same,
although in theory (according to the spec), one RTP packet could
contain multiple payload headers and multiple ASF data packets.
Anyway, not important, it gets interesting if the bit is not set.
Then, the field specifies an "offset" of the data in the complete ASF
packet, which is divided over multiple packets.

Btw, if you recount our previous increasing of the buffer size in
rtsp.c, you'll remember that indeed, for TCP as a lower transport, MS
servers give huge RTP packets so one single big ASF packet fits in one
RTP packet. For UDP, instead it divides them over multiple small RTP
packets, so that multiple RTP packets make up one big ASF packet. The
marker bit signals the completion of one ASF packet, as with other
payloads. The offset field specifies the offset of this RTP packet in
the complete ASF packet. If packets arrive in order, it means you
should get this:

RTP packet 0: offset 0, size 1000, M=0 (empty buffer, filled to 1000bytes)
RTP packet 1: offset 1000, size 1000, M=0 (buffer starts being
1000bytes, and is filled to 2000)
RTP packet 2: offset 2000, size 1000, M=1 (buffer starts being
2000bytes, and is completed to 3000)

resulting in a 3000byte ASF packet. If packets are lost or out of
order, the offset field can detect this, so if RTP packet 2 came after
0, you know it's wrong / out of order and can discard it or look for /
re-request the missing RTP packet (MS included options for this in the
protocol).

The line of code above checks to make sure that the length of the
currently concatenated buffer of the incomplete ASF packet is equal to
the value of the offset field, i.e. we didn't lose any packets, which
would lead to corrupt data being fed to the ASF demuxer.

X-QT, AFAIK, doesn't use the value and would thus just set it to the
length of the buffer being fed to it, thereby basically voiding the
check.

Let me know if that was unclear.

Ronald