[FFmpeg-soc] SOC Qualifiction tasks

[Justin Ruggles]

Michael Niedermayer wrote:
> On Sat, Mar 15, 2008 at 12:23:05PM +0100, Bartlomiej Wolowiec wrote:
>> On czwartek, 13 marca 2008, Michael Niedermayer wrote:
>>> Hi
>>>
>>> Id like to remind SOC students that everyone should select a seperate
>>> qualification task. Having 2 students work on the same task is not good.
>>> We had 2 last year who did and it caused problems, i would like to
>>> avoid that this year.
>>>
>>> Currently we have (if i interpreted everyones mails correctly)
>>> Sascha      VIVO demuxer (or vivo audio?)
>>> Marcondes   VIVO demuxer (said so after sascha)
>>> andi        metadata or MLP patch cleanup ?
>>> thilani     MLP patch cleanup? (said so after andi)
>>>
>>> Also maybe students should add a note to the wiki below the qualification
>>> task they selected.
>> Hello, 
>>   in GSOC 2007 I wrote part of the code of E-AC3 decoder. 
>> Unfortunately, because of incomplete documentation and lack of samples for a 
>> long time I wasn't able to write all of it in the time of holidays, then, 
>> when the academic year was started I hadn't got much free time. I know, that 
>> it wasn't perfect, but I am keen to try once again to write something in 
>> GSOC. So I would be grateful if you may tell me, do I still have any chance 
>> to participate in GSOC 2008?
> 
> You do, it all of course strongly depends on the number of slots google will
> give us. As well as your last year mentors oppinion ...

The code from last year was good.  There were a few hard-to-find bugs,
but that's par-for-the-course.  Most of the work I've had to do has been
reducing code duplication, which there was a lot of.  Maybe I did not
stress this requirement enough, though I certainly tried.  You did give
a good effort last year and were certainly hindered by the late arrival
of better samples.

I agree that we should give Bartek the same chance as any other student,
based on the same criteria.

> 
>> I'm also keen to write some qualifying task (last year I wrote TIFF encoder 
>> and LZW compression), so I have a question, is any of the following tasks 
>> free: "Optimal huffman tables for (M)JPEG encoding", demuxer RL2 or Psygnosis 
>> YOP ?
> 
> What about getting the EAC3 code into SVN? It likely wont be as easy as the
> other qualification tasks but if you succeed that could have a strong effect
> on your chances of being accepted again (especially if we have many more
> qualified students than slots)

I agree that this would be a good task, and also that it won't be as
easy as the others.  The qualification task is so that we have some
example of your coding abilities and dedication to the task.  Having
another sample of your code won't really help us.  We already have that.
:)  I would like to see your dedication to last year's task by helping
to get it ready-for and into FFmpeg SVN.

I have just been very busy lately with other stuff.  If I can get help
with getting these things done, and then a final patch made which makes
it into SVN, that would go a long way.  I do want to be clear that this
would not guarantee a spot, but it would qualify you to be considered on
the merits of your proposal and all of the other factors we use to
decide which projects get chosen.

Here is my current plan of action regarding AC3 and E-AC3, which is
subject to change if needed.

1. Get the fast, simple AC3 downmixing working based on Rich's
suggestion of doing the short-block downmixing after the IMDCT but
before the overlap/add/window.  I want to do this first because it will
likely change the structure of the decoder a bit, which will be easier
before E-AC3 is integrated.  Right now I'm getting artifacts.  My plan
is to analyze a single frame, in depth, to find out where the problem lies.

2. Right now AC3 is suffering from a major stability problem. There are
many coded values which affect how many bits are read, and the bitstream
reader does not have any built-in protection from reading past the input
buffer.  So malformed or damaged streams can (and do) cause memory
access problems (detected by valgrind) and/or segfaults.  I have several
ideas for solutions to this, but I need time to test each one to see
which is the fastest.

3. Go through the list of invalid bitstream conditions in the specs and
add as many of those checks as possible.  Some may not be needed if they
 significantly decrease decoding speed and do not affect stability.  I
have already started on this...it just needs to be tested and applied.

4. Do the same condition checks for E-AC3 as well, but we don't have a
nicely prepared list to work from.

5. Update the E-AC3 decoder to include all the changes since last update
and any subsequent changes.

6. There are a couple of samples which seem to be 7.1-channel. It would
be nice to get this working before SVN inclusion.

7. Error conclealment. Simple error concealment is fairly trivial. For
more robust detection and concealment, Michael made some great
suggestions for guidelines.  It would require some reworking of the AC3
parser.

8. Prepare a final patch and go through the ffmpeg-devel review process.

So that's about it. :)  If anyone feels I should skip any of these steps
or change the priority, I am open to suggestions.

That said, I think a good SoC qualification task would be to work on #4
to #7 while I concentrate on #1 to #3.  Then once that's all ready, do
#8.  I will, of course, help with all of this and would make sure to
prioritize this over my other on-going projects.

Thanks,
Justin