[FFmpeg-devel] H.261 and H.263 RTP broken?

Martin Lindhe martin
Thu Jan 29 16:59:18 CET 2009


Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL wrote:
> OK here is my little contribution. With this I correctly receive 
> H263/RTP streams from a mobile phone. Forgive the naive style and 
> overall bad quality, I'm a beginner with ffmpeg internals and I really 
> thought somebody more knowledgeable would take over :-}
>   

I have poked some more with your patch this afternoon,
please disregard the previous patch i sent, I was in too much of a
hurry to post it before lunch break :(

The video is streamed at the correct speed,  but the audio is
lagging behind now. I do not know how to fix that.
It appears that audio is lagging about 3 seconds behind the video.
Does your streams suffer the same issue? I am using PCMA audio,
which plays back at correct speed by itself (ie no video).

I tried commenting out your added call to finalize_packet() in rtpdec.c
but it does not make a difference for me (video looks good but
audio is lagging with or without it).

I renamed your functions to from "h263" to "h263p", in the hope
that a H263/1996 RTP handler can be added aswell in the future.

> ------ File h263.patch ---------------------------
>
> Index: libavformat/rtpdec.c
> ===================================================================
> --- libavformat/rtpdec.c	(revision 16849)
> +++ libavformat/rtpdec.c	(working copy)
> @@ -31,6 +31,7 @@
>
>   #include "rtp.h"
>   #include "rtp_h264.h"
> +#include "rtp_h263.h"
>
>   //#define DEBUG
>
> @@ -60,6 +61,7 @@
>       ff_register_dynamic_payload_handler(&mp4v_es_handler);
>       ff_register_dynamic_payload_handler(&mpeg4_generic_handler);
>       ff_register_dynamic_payload_handler(&ff_h264_dynamic_handler);
> +    ff_register_dynamic_payload_handler(&ff_h263_dynamic_handler);
>   }
>
>   static int rtcp_parse_packet(RTPDemuxContext *s, const unsigned char 
> *buf, int len)
> @@ -296,6 +298,8 @@
>           case CODEC_ID_MP3:
>           case CODEC_ID_MPEG4:
>           case CODEC_ID_H264:
> +        case CODEC_ID_H263:
> +        case CODEC_ID_H263P:
>               st->need_parsing = AVSTREAM_PARSE_FULL;
>               break;
>           default:
> @@ -437,6 +441,7 @@
>           return -1;
>       }
>       payload_type = buf[1] & 0x7f;
> +	if (buf[1] & 0x80) flags |= RTP_FLAG_M_BIT;
>   

RTP_FLAG_M_BIT is not defined in the patch


Luca Abeni: The RTP marker bit is present in the standard RTP headers
(RFC 3550, section 5.1), perhaps it should be visible in the
"RTPDemuxContext" struct?

Or could this be solved instead with st->need_parsing = AVSTREAM_PARSE_FULL ?
I didnt see any generic code checking for the M bit but i might just have missed it.



>
>
> ------- File rtp_h263.c ---------------------------------------------
>
>   

> [...]
>
> static int parse_h263_sdp_line(AVFormatContext *s, int st_index,
>                                 PayloadContext *h263_data, const char *line)
> {
>      AVStream *stream = s->streams[st_index];
>      av_set_pts_info(stream, 33, 1, 90000);      // 33 should be right, 
> because the pts is 64 bit? (done elsewhere; this is a one time thing)
>
>   
I am unsure what this av_set_pts_info() call is supposed to do.
It is called already from rtp_parse_open() as

av_set_pts_info(st, 32, 1, 90000);



>
> /**
> This is the structure for expanding on the dynamic rtp protocols (makes 
> everything static. yay!)
> */
> RTPDynamicProtocolHandler ff_h263_dynamic_handler = {
>      "H263",
>   

ffmpeg calls the codec "H263-1998" (RFC 2429) internally.
sdp_parse_rtpmap() will fail to match a SDP describing H263+ here.
SDP should look like:

m=video 20000 RTP/AVP 96
a=rtpmap:96 H263-1998/90000
a=fmtp:96 QCIF=1; D=1; F=1; I=1; L=1; S=1; T=1



Attached is a cleaned up patch that works for me.

best regards
Martin Lindhe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h263p.patch
Type: application/mbox
Size: 7674 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090129/e6e89d3f/attachment.bin>



More information about the ffmpeg-devel mailing list