Difference between revisions of "FFmpeg Summer Of Code 2006"

From MultimediaWiki
Jump to navigation Jump to search
m (MP3)
(SNOW --> Snow, plus some random typo fixes)
Line 41: Line 41:
  
 
== Dirac ==
 
== Dirac ==
[[Dirac]] is an experimental codec developed by [[BBC]] as an open standard. It employs a wide range of advanced compression tecniques and shares some features with [[SNOW]].
+
[[Dirac]] is an experimental codec developed by [[BBC]] as an open standard. It employs a wide range of advanced compression tecniques and shares some features with [[Snow]].
 
Implementing this codec based on the upcoming new specification from [http://dirac.sf.net Dirac site] will follow a roadmap/milestone approach similar to the one that will be used on the [[VC-1]] project.
 
Implementing this codec based on the upcoming new specification from [http://dirac.sf.net Dirac site] will follow a roadmap/milestone approach similar to the one that will be used on the [[VC-1]] project.
  
Line 79: Line 79:
 
''Mentor: Luca Barbato''
 
''Mentor: Luca Barbato''
  
== SNOW ==
+
== Snow ==
  
[[SNOW]] is a lossy and lossless video codec featuring wavelet transform and overlapping block based motion compensation. It shares with [[Dirac]] the choice of wavelets but it is quite simpler and with less optional features. At the present the ffmpeg implementation is partially optimized for x86, amd64 and ppc and usable on high end systems.
+
[[Snow]] is a lossy and lossless video codec featuring wavelet transform and overlapping block based motion compensation. It shares with [[Dirac]] the choice of wavelets but it is quite simpler and with less optional features. At the present the ffmpeg implementation is partially optimized for x86, AMD64 and PPC and usable on high end systems.
  
 
This project could be split in two macrotasks:
 
This project could be split in two macrotasks:
  
* Improve the optimizations and refine the implementation in order to have ffmpeg playing [[SNOW]] in more constrained environments. Most of the work will be related to avoid cache trashing and vectorize the code.
+
* Improve the optimizations and refine the implementation in order to have FFmpeg playing [[Snow]] in more constrained environments. Most of the work will be related to avoid cache trashing and vectorize the code.
  
 
* Write a formal specification of the codec and document the implementation.
 
* Write a formal specification of the codec and document the implementation.
Line 93: Line 93:
 
For this project you must know:
 
For this project you must know:
  
* How to profile an application using oprofile, valgrind and the internal timers available in ffmpeg
+
* How to profile an application using oprofile, valgrind and the internal timers available in FFmpeg
  
 
* SIMD theory and how to vectorize certain algorithms in practice
 
* SIMD theory and how to vectorize certain algorithms in practice
Line 101: Line 101:
 
* Basic knowledge of the math beside the transformations in use.
 
* Basic knowledge of the math beside the transformations in use.
  
* Altivec, MMX/SSE, VIS or any other vector extension assembly/C intrinsics for your favourite arch.
+
* AltiVec, MMX/SSE, VIS or any other vector extension assembly/C intrinsics for your favourite arch.
** Altivec would preferably be written as intrinsics
+
** AltiVec would preferably be written as intrinsics
 
** SSE/MMX/3dNow! code as inline assembly.
 
** SSE/MMX/3dNow! code as inline assembly.
  
Line 128: Line 128:
  
 
== MP3 ==
 
== MP3 ==
Implement a simple MP3 encoder. The encoder should be a fixed-point implementation and should use the already existing infrastructure in ffmpeg when possible. A bitstream compatible encoder should take 1 month to complete and 2 more months for a fairly optimized good sounding encoder.
+
Implement a simple MP3 encoder, the encoder should be a fixedpoint implementation and using the already existing infrastructure in ffmpeg when possible. A bitstream compatible encoder should take 1 month to complete and 2 more months for a fairly optimized good sounding encoder.
  
 
''Mentor: Benjamin Larsson''
 
''Mentor: Benjamin Larsson''

Revision as of 16:05, 10 May 2006

Google is sponsoring its second Summer of Code. FFmpeg has been selected as one of the approved mentoring organizations. If you have any questions, feel free to contact the FFmpeg mentoring administrator, Mike Melanson, at (mike -at- multimedia.cx). This page contains a few project ideas (which, by no means, limits any prospective proposals).

Applying

If you are interested in participating in the Google Summer of Code you will need to register at the official SoC site linked above and file an official application. Traditionally, top applications are fairly detailed. Look at this application for inspiration [1]. The Drupal project has also prepared guidelines:

Further, there is a Google Group that includes much discussion of what it takes to be accepted into this program. Good luck!

VC-1

VC-1, a.k.a. Microsoft Windows Media Video 3 or 9, is widely used and should see even wider use due to the introduction of HD-DVD. The format for this codec is open and known, but so far unimplemented in FFmpeg. This task entails implementing the VC-1 codec based on the emerging open specification Wiki document and forthcoming roadmap. This is a big task but will have very clearly defined milestones, e.g., the first major goal is to decode I-frames, and to get that point there will be a number of smaller goals, each with its own set of unit tests.

The decoder should be clean, simple, readable, and efficient. It should incorporate existing FFmpeg facilities where appropriate.

Major goals/milestones for this project include:

  • create a skeleton decoder module to ensure that you understand how the module interacts with the FFmpeg system
  • decode progressive I-frame
  • decode progressive P-frame
  • decode progressive B-frame
  • decode interlaced I-frame
  • decode interlaced P-frame
  • decode interlaced B-frame
  • SIMD optimizations

Note that the progressive frame decodes are the most important steps for decoding existing media available via the internet. Interlaced decoding is less important, but is still necessary. SIMD optimizations (optimizing certain critical functions using CPU instructions like MMX, SSE2 and Altivec) is a "nice to have" feature in the end but not strictly part of this endeavor.

Mentor: Mike Melanson

AAC

AAC is quickly becoming the new MP3. FFmpeg wants its own independent implementation. This task entails implementing a new, optimized AAC decoder in a similar manner as outlined in the VC-1 section, based on the emerging open specification Wiki document.

Mentor: Mike Melanson, Backup mentors: Benjamin Larsson, Oded Shimon

FFmpeg Refactoring And Test Suite

Multimedia programs tend to be highly modular in design and FFmpeg is no exception. However, it does not make the best use of independent modules. The major task in refactoring FFmpeg modules will be to reorganize code so that each individual codec or muxer/demuxer module can be easily enabled and disabled at compile time. This task also entails creating a test suite that can automatically enable each module, one at a time, and validate that FFmpeg still builds and works.

Mentor: Mike Melanson

Improving libavformat

libavformat is the interface of FFmpeg that is responsible for splitting apart encoded audio and video data from multimedia files (demuxing) and putting it together in new multimedia files (muxing). While libavcodec -- the FFmpeg component that encodes and decodes audio and video data -- enjoys widespread use among an impressive array of multimedia projects libavformat has not seen the same level of adoption. This task would entail investigating how to improve the libavformat API, how it interacts with client applications and input layers, developing proof of concept code for a new API and working to port existing muxers and demuxers to the new API.

Mentor: Mike Melanson

Dirac

Dirac is an experimental codec developed by BBC as an open standard. It employs a wide range of advanced compression tecniques and shares some features with Snow. Implementing this codec based on the upcoming new specification from Dirac site will follow a roadmap/milestone approach similar to the one that will be used on the VC-1 project.

Requirements:

  • Good C knowledge
  • Basic knowledge of compression techniques in multimedia

Mentor: Luca Barbato

NUT

There are already many widely used and well specified container formats like Matroska or Ogg that are open and free for use. Each of them have some shortcomings due design decisions that make them non optimal for a number of applications. NUT is designed to be simple to implement and parse, easy to seek to precise position without unnecessary reads, even on partial files, error resistant, and with the lowest possible overhead. This Summer of Code project consists of updating the current ancient ffmpeg implementation to be in line with the current specification, and benchmark it against other implementations of NUT and other container formats. Another part of the project will be helping the team to improve the documentation available; this will be mostly a side effect of the implementation task.

Roadmap:

  • Study the current specification and clarify it, putting it in a more verbose and understandable form.
    • Conversion to rst or docbook isn't really required, but would be greatly appreciated.
  • Update the demuxer using libnut-produced files as testcases
    • Testcase 1: it should demux the complete file correctly as sequential reads
    • Testcase 2: it should seek correctly in the complete file
    • Testcase 3: same as 1 but with corrupted file
    • Testcase 4: same as 2 but with corrupted file
  • Update the muxer using libnut and ffnut demuxer to validate the produced files
    • Make sure that the interleaving rules are respected.


Requirements:

  • Good C knowledge
  • Technical writing skills

Mentor: Luca Barbato

Snow

Snow is a lossy and lossless video codec featuring wavelet transform and overlapping block based motion compensation. It shares with Dirac the choice of wavelets but it is quite simpler and with less optional features. At the present the ffmpeg implementation is partially optimized for x86, AMD64 and PPC and usable on high end systems.

This project could be split in two macrotasks:

  • Improve the optimizations and refine the implementation in order to have FFmpeg playing Snow in more constrained environments. Most of the work will be related to avoid cache trashing and vectorize the code.
  • Write a formal specification of the codec and document the implementation.

A complete roadmap will be decided together with the candidates.

For this project you must know:

  • How to profile an application using oprofile, valgrind and the internal timers available in FFmpeg
  • SIMD theory and how to vectorize certain algorithms in practice
  • DocBook, rst, or doxygen for the documentation steps
  • Basic knowledge of the math beside the transformations in use.
  • AltiVec, MMX/SSE, VIS or any other vector extension assembly/C intrinsics for your favourite arch.
    • AltiVec would preferably be written as intrinsics
    • SSE/MMX/3dNow! code as inline assembly.

Mentor: Luca Barbato

AC3

Implement a LGPL/BSD/MIT licensed (E)AC3 decoder (Dolby Digital(Plus)) for FFmpeg based on the specifications found at http://wiki.multimedia.cx/index.php?title=A52.

  • The main objective is a fairly optimized floating point version of the decoder; expected time for that is one month.
  • The second objective is a fixed point version of the decoder; expected time for that is two months.

Sample files for this task can be found at http://www.mplayerhq.hu/MPlayer/samples/A-codecs/AC3-samples/. If sample files for Enhanced AC-3 (Dolby Digital Plus) turn up before the task starts, the enhanced part of the AC-3 is to be included in the task. The resulting code should be clean and commented. It should use already existing infrastructure in FFmpeg when possible.

Mentor: Benjamin Larsson

Profiling and Optimization

Profile and optimize memory usage

Vorbis

Implement a Vorbis encoder

AMR

Implement a LGPL AMR decoder (encoder). AMR (Adaptive Multi Rate) is the codec used in several new mobiles. Specifications can be found here [2]. A decoder for both AMR narrow band and wide band is the goal. The expected time for this task is 2 months.

Mentor: Benjamin Larsson

MP3

Implement a simple MP3 encoder, the encoder should be a fixedpoint implementation and using the already existing infrastructure in ffmpeg when possible. A bitstream compatible encoder should take 1 month to complete and 2 more months for a fairly optimized good sounding encoder.

Mentor: Benjamin Larsson

Psychoacoustics

Implement a good psychoacoustic model. Support the usage of this model from the AC3, MP2 and other audio encoders.