Talk:FFmpeg Summer Of Code 2009
AAC-LC encoder completion and psycho-acoustic model improvement
- Evaluate existing psycho-acoustic model implementations (3gpp and FAAC at least at this stage) to find a combination that is as good as or better than FAAC quality-wise
- Implement this combination of heuristics/algorithms
- Make sure the encoder is close to/faster than FAAC and close to/better quality than FAAC
- Evaluate other algorithms to offer better quality with reasonable encoding speed impacts and allow them to be switchable through command line options
- Implement sane brute force rate-distortion optimal method
How does that sound? I'd mentor this if Kostya was going to get it just so he could dedicate some time to it and so that he can be guided a little as to how to approach the problems at a high level. If anyone else is going to do it, I expect some more hands-on research would be needed. --Robert Swain
- Let's see. First point - working on it; second point - current code is a mess of 3GPP and FAAC (and reference encoder) functions for quantisation; third point - that's my near-future goal; fourth point - I'm making them switchable, but for now they have unreasonable encoding speed; fifth point - implemented it long ago (rather slow though). In any case I will lend my hand or hoof or whatever on this. Current code is missing rate control and fast quantisation stuff, the rest is working. --Kostya 01:51, 23 March 2009 (EDT)
- Well, you're still a student aren't you? Would you like to work on this over summer? For what do you think you will apply this year? --Robert Swain
AMR-NB and QCELP
Do people think it would be reasonable to join these two into one task? Once AMR-NB is finished off and in trunk, I suspect remaining features that are non-mandatory can be shared between multiple of the CELP codecs. I need to research which functions but I suspect things like silent frames, comfort noise and similar. --Robert Swain
S/PDIF muxer
Is there any specific qualification task you would like done for this? -- Jai
- Working Jpeg2000 decoder ;), cleaning up this http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2005-June/001673.html would be welcome. It's a rpza encoder. --Merbanan 06:22, 31 December 2008 (EST)
speex + gsm
Aren't libgsm and libspeex distributed under a permissive license? If yes, these tasks do not have very high priority, imo. Ce 14:56, 11 January 2009 (EST)
- That's not important. FFmpeg aims to support all multimedia formats. We have never let this argument stop us from implementing decoders. --DonDiego 08:22, 14 March 2009 (EDT)
- That's fine but a Speex decoder should be at least as high quality as libspeex. We already have an Ogg demuxer that fails on files libogg plays and a Theora decoder that doesn't support all of the features that libtheora does. --AConverse
- Could you point me to the roundup issue numbers? --Ce 19:36, 19 March 2009 (EDT)
- issue798 issue579 to start --AConverse 23:59, 19 March 2009 (EDT)
- AFAIU, you forgot to commit one patch and didn't ping the other (yes, this is always necessary for Mans' code).--Ce 04:54, 20 March 2009 (EDT)
- Theora stack corruption was applied I just must have forgotten the post commit message. Broken continuation was rejected. And from the Thusnelda bug we are still missing 4:2:2. --AConverse 12:50, 20 March 2009 (EDT)
- AFAIU, you forgot to commit one patch and didn't ping the other (yes, this is always necessary for Mans' code).--Ce 04:54, 20 March 2009 (EDT)
- issue798 issue579 to start --AConverse 23:59, 19 March 2009 (EDT)
- I think there are precise quality requirements for decoder: They have to produce bitexact output. So I dont see a problem with having our own Speex decoder. --DonDiego 14:13, 23 March 2009 (EDT)
- Could you point me to the roundup issue numbers? --Ce 19:36, 19 March 2009 (EDT)
- That's fine but a Speex decoder should be at least as high quality as libspeex. We already have an Ogg demuxer that fails on files libogg plays and a Theora decoder that doesn't support all of the features that libtheora does. --AConverse
DTS-HD Master Audio decoder?
Would DTS-HD Master Audio decoder make good project suggestion? Gamester17 02:51, 16 January 2009 (EST)
http://en.wikipedia.org/wiki/DTS-HD_Master_Audio
- ""DTS-HD Master Audio is a lossless audio codec created by Digital Theater System. It was previously known as DTS++ and DTS-HD. It is an extension of DTS which, when played back on devices which do not support the Master Audio extension, degrades to a 1.5 Mbit/s "core" track which is lossy. DTS-HD Master Audio is an optional audio format for both Blu-ray Disc and HD DVD"
Specs, please. From what I know the projects without spec take a looong time to complete. --Kostya 03:32, 16 January 2009 (EST)
- AFAIK, there is even no software implementation, so it would be even more difficult;-( Ce 20:14, 16 January 2009 (EST)
- How about then qualification task for at least distinguishing between normal DTS and DTS-HD Master Audio, to let the users know that the audio stream DTS-HD Master Audio but they are only getting normal DTS output out of it from FFmpeg? As today FFmpeg reports all as just "dca", (I understand that MediaInfo is an open source C++ project that is capable of distinguishing between normal DTS and DTS-HD Master Audio. Gamester17 12:20, 21 January 2009 (EST)
WTV (Microsoft Windows Media Center Recording Format) demuxer?
Would a WTV (Microsoft Windows Media Center Recording Format) demuxer make good project suggestion? Gamester17 13:14, 16 January 2009 (EST)
http://wiki.multimedia.cx/index.php?title=WTV
- "WTV is the new container format used to record television shows in Microsoft Windows Vista Media Center starting with Windows Media Center TV Pack 2008.", "WTV is the successor of DVR-MS which is is being replaced with WTV", "WRT is also the default recording format for Windows 7 Media Center"
- This is tricky. It doesn't strike me as being involved enough to qualify as one of our usual SoC projects. OTOH, it seems a little too involved to be a qualification task. --Multimedia Mike 14:24, 16 January 2009 (EST)
- That sounds great actually. Maybe this could become one of the few SoC projects that are actually finished in time...--DonDiego 07:18, 18 January 2009 (EST)
libavui (a common skins library)?
Would a common skins library make good project suggestion?
- MPlayer skin
- VLC skin
- Xine skin
- XMMS skin
- WINAMP skin
- Windows Media Player skin
- Rockbox skin
- foobar2000 skin
- Songbird feathers (skin)
-Nazo 21:29, 16 January 2009 (EST)
- Personally, I would advocate a project to stamp out skinnable UIs across the computing landscape. But that's outside of the scope of an SoC project. I hate UI skins. --Multimedia Mike 14:03, 17 January 2009 (EST)
- I second that. But I don't see how GUI stuff like promoting or discouraging skins relates to libav* in the first place. Koorogi 16:26, 17 January 2009 (EST)
- No, skins are outside the scope of FFmpeg.--DonDiego 07:18, 18 January 2009 (EST)
Refactor VDPAU patch for video editing
This might be a good project: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/059032.html but I don't know for sure, so that's why I am including it on this page. Dashcloud 16:23, 20 January 2009 (EST)
More pixel format support?
Would more pixel format support make good project suggestion? Here is crazy missing pixel format list (from HDPhoto):
- 1/2/4bpp palette - 8bpp is already supported
- 1/2/4/32bpp gray - 8bpp and 16bpp are already supported
- 16bpp gray fixedpoint
- 32bpp gray float
- 48/96bpp RGB - 24bpp is already supported
- 48/64bpp RGB half
- 48/64/96/128bpp RGB fixedpoint
- 32bpp RGB101010
- 96/128bpp RGB float
- 64/128bpp RGBA - 32bpp is already supported
- 64/128bpp RGBA fixedpoint
- 64bpp RGBA half
- 128bpp RGBA float
- 32bpp BGR - 24bpp is already supported
- 32bpp PBGRA
- 64bpp PRGBA
- 128bpp PRGBA float
- 32bpp RGBE
- 32/64bpp CMYK
- 40/80bpp CMYKAlpha
- 12bpp YUV420
- 16bpp YUV422
- 24bpp YUV444
- 24bpp 3Channels
- 32bpp 4Channels
- 40bpp 5Channels
- 48bpp 6Channels
- 56bpp 7Channels
- 64bpp 8Channels
- 48bpp 3Channels
- 64bpp 4Channels
- 80bpp 5Channels
- 96bpp 6Channels
- 112bpp 7Channels
- 128bpp 8Channels
- 32bpp 3ChannelsAlpha
- 40bpp 4ChannelsAlpha
- 48bpp 5ChannelsAlpha
- 56bpp 6ChannelsAlpha
- 64bpp 7ChannelsAlpha
- 72bpp 8ChannelsAlpha
- 64bpp 3ChannelsAlpha
- 80bpp 4ChannelsAlpha
- 96bpp 5ChannelsAlpha
- 112bpp 6ChannelsAlpha
- 128bpp 7ChannelsAlpha
- 144bpp 8ChannelsAlpha
--Nazo 07:24, 21 January 2009 (EST)
- See Small FFmpeg Tasks#Generic Colorspace system. Vitor 14:11, 22 January 2009 (EST)
VC-1 Interlaced Support
Blu-Ray media contain interlaced VC-1 which is currently not supported by lavc decoder. Since a lot of people showed the lack of interest to implement it, maybe some student will take this task. --Kostya 09:23, 26 January 2009 (EST)
- Added to article --Ce 09:53, 4 March 2009 (CST)
Interactive command ui support
Interactive command ui might be good start point to implement missing features for GUI encoders.
- more presets
- containable codec in each format
- mapping between encode options and proper UI types
- playable codecs and encode options on each player (WMP, RealPlayer, Flash Player, Silverlight, PS3, mobile phones, etc...)
- list of usable metadata tags in each format
- etc...
--Nazo 05:22, 28 February 2009 (CST)
Maybe remove/downshift some tasks
Some tasks would be hard to complete:
- Flash Screen video 2 codec - without Mike providing documentation it's a bit harder. I remember one student who was promised RV40 specs and got almost nothing; decoder was more or less completed successfully but it took slightly more time.
- GStreamer input - rather weak excuse. Better make it the task of REing WMA lossless (WMApro is almost there).
- i263 decoder - FFmpeg supports i263 to some extent. Missing bits are probably make only a small FFmpeg task.
--Kostya 10:39, 4 March 2009 (CST)
I also have my doubts about libvo (typical cleanup task, that has not worked out well in the past) and the AACS task. AACS could work out, but IMO only the "last" part, decoding when the title key has already be found fits in FFmpeg, and then I think it should at least be AACS + CSS (I hope they would be able to share some code, at least they use the same bits for flagging the encryption).
Reimar 14:26, 19 March 2009 (EDT)
ffmpeg.c factorization
Every once in a while, someone shows up at ffmpeg-devel with a patch for turning ffmpeg.c into a library (for example [1]). While this is a bad idea for several reasons, having a lot of people asking for it shows that it is very hard to use libav* in a client application while been as flexible as the command-line tool.
So I suggest a SoC project of factorizing ffmpeg.c into several public, clean, well-documented functions, to simplify the use libav* and turning ffmpeg.c into a good API example.
- Note: The tricky part of this project would be to factorize ffmpeg.c into functions that actually should be in a lib, not just mechanically moving code to libav*/something.c
-Vitor 13:45, 4 March 2009 (CST)
Rate control project
I copied this one from the 08 SoC page because I think it would be a great project- but if people think it doesn't need to be copied from last year's page, then I'll delete the entry. Dashcloud 22:08, 4 March 2009 (CST)
What does viterbi have to do with macroblock-level ratecontrol, with or without VBV constraints? I can vaguely see viterbi on frame-level VBV compliance, using "remaining VBV space" as the state to be trellised over, if you're willing to quantize possible frame sizes enough to bring the number of states down to something sane. But that isn't relevant to macroblocks: VBV doesn't impose any constraints smaller than a frame, so macroblock-level is plain old independent RDO. Pengvado 08:33, 13 March 2009 (EDT)
WMA lossless
I'm not sure this would qualify as a project unless someone (generally other than the student, unless he is really gifted) takes the responsibility of reverse engineering it
-Vitor 13:50, 6 March 2009 (CST)
The situation is the same as with WMA3 lossy and we have working decoder for it.
--Kostya 23:38, 6 March 2009 (CST)
Shoutcast support
Is adding support for shoutcast (streaming & receiving) a viable task? -- Jai
- preliminary patch here: https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/060556.html --Compn 11:42, 14 March 2009 (EDT)
Playlist/Concatenation Support
I suspect that interface can be easily extended by two options only: -playlist X and -concat, the latter tells FFmpeg to concatenate all input files instead of processing them in parallel. The problem will be mostly in formats negotiations during concatenation (i.e. frame dimensions and rate mismatch for different files). --Kostya 07:52, 19 March 2009 (EDT)
JPEG2000 project
A note should be added to this one saying that you should also make sure it handles the JPEG2000 images inside the R3D files. Dashcloud 23:00, 19 March 2009 (EDT)
- Conversion of Y1CbCrY2 data stored in r3d jpeg2k codestreams to rgb or whatever else does not belong in a jpeg2k decoder IMHO.
- Also, the exact debayer algorithm RED uses is not known iirc. But we can have some approximation which is useful for previews.-- Jai
2008 GSoC Projects
I think all 2008 GSoC projects are still being actively worked upon. kostya, atrange, sascha, mind if I remove them from this page?--Angustia 17:13, 20 March 2009 (EDT)