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

[Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL]

Martin Lindhe wrote:
> 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).

The problem is, the H263(+) streaming application I use on the phone 
doesn't send audio. Hence the lack of testing of that part :-}

> 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.

See my other message. You guessed right :)

> 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);

No idea. Stolen blindly from rtp_h264.c, as is the whole skeleton of the 
rtp_h263.c file ! In the same vein, maybe we should use NULL instead of 
the no-brainer routines I have put for SDP parsing...

> Attached is a cleaned up patch that works for me.

Thanks !

-Alex