[FFmpeg-devel] H.261 and H.263 RTP broken?
Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL
Thu Jan 29 17:05:36 CET 2009
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.
More information about the ffmpeg-devel