[FFmpeg-devel] Google Summer of Code 2008

[Luca Abeni]

Hi Ronald,

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


				Luca