[FFmpeg-devel] Google Summer of Code 2008
Tue Feb 26 15:39:48 CET 2008
Ronald S. Bultje wrote:
> On Tue, Feb 26, 2008 at 5:12 AM, Luca Abeni <lucabe72 at email.it> wrote:
>> - Fix the RTP demuxing code (not sure if it can be fixed, or if it should
>> be rewritten from scratch - in the second case, maybe this can be a
>> whole SoC project?)
> Can you elaborate on this? I may be willing to do (some of) the work
> (outside SoC).
Well, I did not look at all the details (some of the rtpdec.c code scares
me :), but:
- The RTCP RR packets generated by libavformat looks very wrong (they are
generated at the wrong rate, contain some useless information, and miss
some important statistics - the comment before rtcp_update_jitter() is
- The AAC payload parser does strange things, returning many audio frames
together (there is a comment about multiple AU Sections which seems to
imply some bug somewhere)
- finalize_packet() is just wrong. With the current version, only mpeg
video and mp2 audio have a chance to be properly synchronised. I suspect
to properly implement finalize_packet() for all the audio formats we
need to use a proper time_base for the various streams (instead of using
the default one). I did a similar change for the RTP muxer some time ago.
- I suspect that we can set need_parsing = 0 (the RTP demuxer should be
able to properly identify audio and video frames, without using the
parser). But I am not sure, maybe Michael can comment on this.
- The payload header can be used for being more robust against packet loss
(currently, it is just discarded)
- The clock_rate field of AVRtpPayloadTypes is currently used for setting
the audio sample rate. I believe this is broken, and in fact it often
creates problems when receiving mp2 audio (the audio stream is detected
with sample rate 90000). I believe this field should be used to set the
stream time base (see above).
- AVRtpPayloadTypes contains a lot of useless empty entries. I believe this
table should be truncated after the 35th entry.
I suspect there are more problems, but I think the list above is enough
to give an idea... In general, I think the whole rtpdec.c file should be
carefully checked, comparing the implementation with the relevant RFCs.
More information about the ffmpeg-devel