[FFmpeg-devel] RTP mark bit not passed to parse_packet

Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL alexandre.ferrieux
Thu Jan 15 11:42:38 CET 2009


Hi Luca,

First thanks for the fast response !

>> In the process of writing an RTP depayloader for H263 (RFC2429, simple 
>> follow-on packet mode), I see that the current API doesn't pass the RTP 
>> Mark bit (buf[1]&0x80) to the payload handler callback.
> 
> Yes, the parse_packet() calback looks quite strange to me too...
> It is not considering important information (like the M bit) and
> has some other "interesting features", like the "*timestamp"
> parameter...

OK. Glad to see we share the feeling :)

> 
> I think the RTP de-packetiser is not supposed to split the stream in
> frames, but simply to simply return the payload. libavcodec then contains
> a parser (see libavcodec/h263_parser.c) that is in charge of splitting the
> stream in frames. You just have to ensure that rtp_parse_open() sets
> st->need_parsing = AVSTREAM_PARSE_FULL for H.263 too (as it already does
> for mpeg video, and audio, H.264, etc...).

Thanks, that is indeed the key info I was missing.

Discovering this, I realize I may not have read all the relevant 
documentation. I apologize for this. I'd appreciate a pointer to the 
part describing the interaction between the encapsulation and codec layers.

In the meantime, just one point I'd like to clarify regarding H263:
The follow-on-packet method just uses a payload-header of 2 bytes, with 
values 0x0400 for the first packet (P bit set) and 0x0000 for 
follow-ons. In addition, the P bit in the first packet "encode" two zero 
bytes of the subsequent bitstream (which are thus removed on 
encapsulation). Then, when depacketizing the first packet, should I pass 
to the decoder:

	- the 0400 header + bitstream without 0000
	- the 0400 header + bitstream with 0000
         - bitstream with 0000 but no payload header

(and similar question for follow-ons).

> I agree that this should be improved (the current design is not robust
> against packet loss, for example), but this is how things currently work
> (as far as I understand). Anyway, I think that patches in this regard
> are highly welcome ;-)

I'll be glad to contribute once I get it right :)

But here is already what I did on the other side, to allow ffmpeg to 
stream H263 out. Of course it is just the simple follow-on method, hence 
no error resilience. It is notably less ambitious than what is currently 
done for H264; but I have the plan to improve it later).

I do realize this is naive code, and I'd be happy to see you take over. 
It's just that I found it a bit frustrating to see the H263+ codec 
supported but virtually nothing on the RTP side...


HTH,

-Alex



Index: rtpenc.c
===================================================================
--- rtpenc.c    (revision 16614)
+++ rtpenc.c    (working copy)
@@ -243,6 +243,47 @@
      }
  }

+static void rtp_send_h263p(AVFormatContext *s1,
+                                                  const uint8_t *buf1, 
int size)
+{
+  RTPDemuxContext *s = s1->priv_data;
+  int maxs,first,len;
+  char locbuf[65536]; /* overestimation of MTU !!! */
+
+  /* RFC2429 payload header == 16 bits */
+
+  maxs = s->max_payload_size - 2 - 32 /* margin */;
+
+  /* we remove the two leading zeroes as per P bit */
+
+  buf1+=2;
+  size-=2;
+
+  first=1;
+  while(size>0)
+       {
+         len = size;
+         if (len > maxs)
+               len = maxs;
+
+         /* simple payload header, no-resilience mode: 0400 for 
beginning, 0000 for following */
+         if (first)
+               {
+                 first=0;
+                 locbuf[0]=4;
+               }
+         else
+               {
+                 locbuf[0]=0;
+               }
+         locbuf[1]=0;
+         memcpy(locbuf + 2, buf1, len);
+         ff_rtp_send_data(s1, locbuf, len + 2, (len == size));
+         size -= len;
+         buf1 += len;
+       }
+}
+
  static void rtp_send_raw(AVFormatContext *s1,
                           const uint8_t *buf1, int size)
  {
@@ -339,6 +380,10 @@
      case CODEC_ID_H264:
          ff_rtp_send_h264(s1, buf1, size);
          break;
+    case CODEC_ID_H263:
+    case CODEC_ID_H263P:
+        rtp_send_h263p(s1, buf1, size);
+        break;
      default:
          /* better than nothing : send the codec raw data */
          rtp_send_raw(s1, buf1, size);
Index: rtp.c
===================================================================
--- rtp.c       (revision 16614)
+++ rtp.c       (working copy)
@@ -70,7 +70,8 @@
    {32, "MPV",        CODEC_TYPE_VIDEO,   CODEC_ID_MPEG1VIDEO, 90000, -1},
    {32, "MPV",        CODEC_TYPE_VIDEO,   CODEC_ID_MPEG2VIDEO, 90000, -1},
    {33, "MP2T",       CODEC_TYPE_DATA,    CODEC_ID_MPEG2TS, 90000, -1},
-  {34, "H263",       CODEC_TYPE_VIDEO,   CODEC_ID_H263, 90000, -1},
+  /*  {34, "H263",       CODEC_TYPE_VIDEO,   CODEC_ID_H263, 90000, -1}, */
+  {96, "H263",       CODEC_TYPE_VIDEO,   CODEC_ID_H263, 90000, -1},
    {-1, "",           CODEC_TYPE_UNKNOWN, CODEC_ID_NONE, -1, -1}
  };





More information about the ffmpeg-devel mailing list