[FFmpeg-devel] GSoC 2009: FFmpeg is in
Sun Mar 22 18:22:22 CET 2009
Luca Abeni wrote:
>>> After this first step, I believe that there are some bugs to fix (RTCP
>>> RR) and features to improve (better recovery after lost packets, handling
>>> of packets arriving in the wrong order, etc...)
>>> Only after this it will be possible to start adding new features.
>> Update the wiki =)
> Ok; I'll try to write something during the weekend
Sorry; for some reason I've not been able to create an account on the
wiki (this might be due to a terrible allergy to wikis that I developed
in the last years :).
Anyway, I searche for some old notes I took about the RTP demuxer...
Here they are:
> - 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)
> - 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 this might require some interface changes and some
> code restructuring
> - The payload header can be used for being more robust against packet
> loss (currently, it is just discarded)
> 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.
And here is something I wrote one years ago about some possible
> Some possible qualification tasks can be:
> - Implement some currently unsupported RTP packetization (and
> demuxing). For example, H.263 or H.261 video, AMR audio, some audio
> codecs used in SIP conferences, vorbis, H.264 SVC ...
> - Implement a wrapper for libnemesi
>>> I think a nice qualification task can be to get the H.263 depacketisation
>>> patch that has been recently posted and improve it so that it can be
>>> included in svn (not sure if this is too simple - an almost working patch
>>> already exists - but being able to receive H.263 over RTP seems to be a
>>> feature that many people want in svn).
>> Is it already in the wiki?
> The wiki mentions h263 and h263+ support as a goal of the SoC project.
> I'll add it as a qualification task, with a link to the email containing
> the patch.
Here it is:
The patch needs some cleanup and fixes (AFAIR it ad some a/v
synchronisation problems), but this should be a nice qualification task.
More information about the ffmpeg-devel