[FFmpeg-devel] FFmpeg Small Task: Optimal Huffman Tables.

[briggers]

On Sun, 22 Apr 2012 22:10:00 +0200, Reimar Döffinger wrote:
> On 22 Apr 2012, at 20:36, briggers <briggers at ninthfloor.org> wrote:
>> On Sun, 22 Apr 2012 19:29:25 +0200, Reimar Döffinger wrote:
>>> On Sun, Apr 22, 2012 at 08:23:45PM +0530, briggers wrote:
>>>> I expect to have quite a bit of free time over the next few months
>>>> which I hope I can spend constructively by contributing to the
>>>> FFmpeg project. I was looking through the small tasks list on the
>>>> wiki at multimedia.cx [1] to get an idea where I could start. I 
>>>> was
>>>> thinking I could start with the implementation of optimal huffman
>>>> tables for (M)JPEG. I'll try to tread lightly, but I hope you'll
>>>> forgive any future brain farts. Thanks.
>>>
>>> Don't worry about mistakes, reviews are there for catching it
>>> (but if you are new it helps if you can forgive if reviews seem/are
>>> a bit harsh, people generally have only time to point out all that
>>> is bad, even if most is good :-) ).
>>> After reading the task I see I may have misunderstood it.
>>> I guess you mean adding a optimal huffman table for each frame
>>> individually (i.e. more the JPEG use case)?
>>> However there are also MJPEG formats that have one huffman table
>>> in the global extradata header, in which case a proper two-pass 
>>> where
>>> the whole file is encoded first and the optimal table is calculated
>>> only in the second pass is necessary.
>>> But even without that I am not sure this is exactly the most
>>> straight-forward/easy of the tasks listed, but you are very
>>> welcome to do it :-)
>>
>> Thanks for the tips. If you have some other "small task" in mind 
>> that perhaps would be easier or more straight forward and would better 
>> serve as an introduction to contributing to FFmpeg, I'd happily work 
>> on that instead.
>
> Well, it's also important that it is interesting enough for you to 
> do.
> Demuxers usually are easy, so for example the VIVO demuxer. There
> might be more.
> I think there is also a another request in FFmpeg trac where I mostly
> reverse-engineered a rather simple format.
> Unfortunately I forget the ticket number. If such a thing motivates
> you, it might make some user happy since there's no way to read them
> yet.
> What also should be mostly simple is making the imagepipe demuxer
> autodetect the image format which would making it much more
> user-friendly to use (and make it possible for FFmpeg to open images
> without relying on the extension).
> Do whatever you feel interesting, though particularly the last one I
> think has a good chance of giving first results very quickly, in case
> that motivates you.

Thanks for the tips, I'll just go through them all and get started on 
whichever seems easiest.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel