[FFmpeg-devel] H.263 packetizing into RTP

[Yohann Martineau]

On 4/3/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Apr 03, 2009 at 07:08:26PM +0300, Martin Storsj? wrote:
>> Hi,
>>
>> There seems to have been some discussion on patches for packetizing H.263
>> into RTP, e.g. in January
>> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/060022.html,
>>
>> with a patch by Luca Abeni (or who's the original author to that patch?)
>> sent to libav-user,
>> http://lists.mplayerhq.hu/pipermail/libav-user/2009-January/002196.html.
>>
>> Attached is a updated version of that patch, rebased onto the latest
>> version of ffmpeg.
>>
>> What issues are there in getting this patch merged?
>>
> [...]
>> +void ff_rtp_send_h263(AVFormatContext *s1, const uint8_t *buf1, int size)
>> +{
>> +    RTPMuxContext *s = s1->priv_data;
>> +    int len, max_packet_size;
>> +    uint8_t *q;
>> +
>> +    max_packet_size = s->max_payload_size;
>> +
>> +    while (size > 0) {
>> +        q = s->buf;
>> +        if ((buf1[0] == 0) && (buf1[1] == 0)) {
>> +            *q++ = 0x04;
>> +            buf1 += 2;
>> +            size -= 2;
>> +        } else {
>> +            *q++ = 0;
>> +        }
>> +        *q++ = 0;
>> +
>> +        len = max_packet_size - 2;
>
>> +        if (len >= size) {
>> +            len = size;
>> +        }
>
> FFMIN()
>
> also i suspect that packets should be split at slices/gobs

RFC 2190 states that pictures should be split either at gob level
(mode A), at MB boundaries (mode B) or at MB boundaires of P-frames
with PB-frame mode.

I think it should be reasonable to implement only mode A for the
moment, but mode A also requires GOB level. The annoying thing is
that, if I understand H263 correctly, GOB level is optional, which
means somehow that pictures can be split at MB level for mode A... I
don't remember if rfc2190 or rfc4629 gives info about this case...



>
> and like with AMR, i would prefer one of the RT*P experts to review this
> i know too little about RT*P to be able to really spot non trivial issues
> ...
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is not what we do, but why we do it that matters.
>