Got a Big Plan

A renegotiate event for GStreamer

2011-01-18T11:00:00.000-08:00

Currently we have a problem at GStreamer that we can only make an element renegotiate using pad buffer allocs. Check the function documentation for understanding how it works.

By using pad buffer allocs, one element can ask downstream if it wants a new caps, but it can't tell upstream to pick a new caps. This would help in dynamic pipelines and applications that do element hot-swapping, which might happen on camerabin(2).

So I started a first attempt at creating a new upstream event to make the pipeline (or a part of it) do a new caps negotiation, trying to pick optimal caps.

I had 2 basic use cases in mind:

videotestsrc ! capsfilter name=cf ! fakesink
videotestsrc ! capsfilter caps="" ! ffmpegcolorspace ! videoscale ! capsfilter name=cf ! fakesink

In both cases, the capsfilter named 'cf' would change its caps property periodically, making the pipeline renegotiate to pick a new compatible and optimal caps.

The resulting patches were really simple and I only modified basetransform and basesrc (other than adding the new event to core). Keep in mind that I'm still experimenting and we should search for regressions that this might cause. Next I'd like to go for a scenario with elements with multiple src/sink pads (demuxer/tee/selector).

The patches are on a gstreamer branch here and the test cases were added on a branch on my -base clone.

Camerabin2

2010-12-02T05:23:00.000-08:00

As some of you might know, there has been some plans for a new camerabin design on the wiki for some time.

Current camerabin uses a single pad to output data for the viewfinder, video recording and image capture. Two problems on this:

* Requires a mix of input/output-selectors and tricky switch handling code to keep buffers on their correct paths.
* Managing different caps on each output type (images/videos/viewfinder) isn't simple.

Those were the main reasons motivating us to rewrite this in a simpler way. So our adventure with camerabin2 begun. Long story short, we already have a prototype on gitorious and it has the minimum basic features: image capture, video recording and a viewfinder.

Here's a summary on the important changing parts, for more details refer to the wiki.

The key change
The big change is to have a source element (from now on called camera source) that has 3 source pads, one for each task: viewfinder, image capture, video recording.

Why doing camerabin2 and not refactoring camerabin?
The short answer is that it's a major design change we're taking here, writing from the ground up is probably safer and faster and won't bother people using current camerabin. Also, as it requires a new source element, we would cause major incompatibility with current sources.

Modules
We are aiming at a more modularized approach this time, so we have a viewfinderbin, a videorecordingbin and imagecapturebin, those are public elements that can be used outside of camerabin2.

The new 3 pad source
Thanks to Rob Clark's work from some time ago (he refactored camerabin into the new design as a proof of concept), we already got a working 3 pad source for testing our prototype. Truth be told, I haven't got really deep into the source internals working, but our goal is to provide a basecamerasrc which will make it easy (or at least, easier) to develop source elements with 3 pads.

Those are the main things I'd like to post here. I'm trying to schedule a meeting with developers interested on using camerabin2 (or that use camerabin) to discuss features, problems, requests and any camerabin2 related topic. Somewhere in the next days would be great. Nokia, Empathy and Cheese developers already showed interest on this. If you do, too, ping me on IRC (thiagoss at #gstreamer at freenode)

[Edited] Forgot to mention that the camerabin2 branch on gitorious already contains an example application under tests/examples/camerabin2.

gst-opencv design choices

2010-05-11T20:23:00.000-07:00

While continuing wrapping new OpenCV functions into GstElements yesterday, I faced an interesting design choice on the mappings of OpenCV functions' parameters to GstElement's properties.

Take a look at cvSmooth docs. You can see that it has a type parameter, followed by param1, param2, param3 and param4 that have different semantics if different type is used. The question is how to expose those in the 'cvsmooth' GstElement?

I could think of 3 different choices here:

1) Go straightforward and use the same API as OpenCV

As a result, we should have an element with the properties named after the OpenCV parameters:

"cvsmooth type=blur param1=5 param2=3 param3=0.0 param4=0.0"

This results in a very not intuitive API, but we keep it aligned with OpenCV's, making it easy to people that already know one API to use the other one. The element docs would mostly point to OpenCV's docs. Resulting code is simple and easy to maintain.

2) Have multiple elements: cvsmoothblur, cvsmoothgaussian, cvsmooth...

We could have each smooth algorithm (type) into a separate element and have its properties reflect the semantics of this type. For example, we would have cvsmoothblur, cvsmoothmedian and one for each type. The properties of each one would named accordingly to its semantics, instead of some paramX.

This provides a nice API but might increase the number of elements for every function that has this type or a similar parameter. I don't know how common this is. This might be a good solution if there are a few of those. A downside is that switching the type has to use hot-swapping but I don't think this is a common use case.

3) Expose properties for each semantics and use them only if their type is selected.

We still keep it to one element, but we add one property for each semantic a parameter can assume. Those would only be used it we have its corresponding type is selected.

For example: param3 might be the "gaussian standard deviation" or the "color sigma" if type is gaussian or bilateral respectively. We add those 2 properties (standard-deviation and color-sigma) that are only going to be used if their types are selected.

This makes those lines possible:

"cvsmooth type=gaussian standard-deviation=5.0" or

"cvsmooth type=bilateral color-sigma=1.0"

Code is a little messier than options above.

Given those options, I really don't like option 3. I'm considering 1 or 2. From a quick look at some pages of OpenCV's transformations API I could see that this is not very common, and when it happens, only one parameter has a 'variable semantic', looks like I picked the trickiest one as my example.

So, which option would you chose?

Hacking in gst-opencv

2010-05-06T14:29:00.000-07:00

It has been years since I last used OpenCV. We (me and friends working on a lab at the university) used it to process images on batches or to process frames live from a webcam. Things could have been much easier if I knew GStreamer back then. Said so, I decided to take a look at gst-opencv to see what we already can do with it.

There are a few features wrapped as elements at this moment and they work quite well, but it could have a much larger feature set and it seems no one has been recently working on this. Given those and having a little spare time these days, I decided to start hacking on gst-opencv and trying to put it together with the other modules. I'd prefer to have a gst-opencv module, but adding it as a new plugin into gst-plugins-bad is also an option. What do you think?

Current features

[Edited: It seems the videos can only be seen directly on the post at blogspot]

Some nice stuff can already be done with the current elements. Let me show some.

I recorded this video outside some minutes ago:

We can use edgedetect on it and see its edges:

Command: gst-launch uridecodebin uri=youruri ! queue ! ffmpegcolorspace ! edgedetect ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location=result.ogg

Or we can segment it with pyramidsegment and have a nice effect (some people would enjoy this in PiTiVi?) or use it in machine vision stuff?

Command: gst-launch uridecodebin uri=youruri ! queue ! ffmpegcolorspace ! pyramidsegment ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location=result.ogg

OpenCV already ships some face detection profiles for you (at Ubuntu, it goes into /usr/share/opencv/haarcascades/), so you can use them with facedetect element, or train your own classifiers to use with it. I stood with the default and tried on some pictures, here are 2 of them:

I think it works pretty well :)

You can disable the circles and just get messages with the faces' positions and do whatever you want with them.

Other than those, there's also 'textwrite', 'templatematch' and 'faceblur' elements.

Current work

I've been working on a simple base class that will make it easier to map simple 1 to 1 OpenCV functions into elements and providing some common properties (like ROI and COI) and GstBuffer-IplImage conversion. This will help covering more functions and should be enough to get me acquainted again to the API, after it I can go for the fancier stuff.

For example, take cvSmooth function, we should only have to write code to map its parameters into properties and a simplified chain function that already works on IplImages instead of GstBuffers.

Repositories

gst-opencv's main repository is at github, I have my personal branches here. From time to time I ping Elleo to upgrade at github, but I hope we can get this upstream in the next weeks.

Trying GStreamer at Windows

2009-11-09T13:13:00.000-08:00

Since I've started working with GStreamer I had never tried it out on Windows and tonight I decided to try it out. Edward pointed me to the winbuilds and it took no more than pressing 'next' 4 or 5 times to have default applications (gst-launch, gst-inspect...) and lots of plugins. Easy enough.

That must be the reason it has been some time since I've heard complaints about installing/using GStreamer on Windows. I wonder if there are any other builds out there like these?

Thanks ylatuya!

GstCollectPads2 branch

2009-08-12T21:31:00.000-07:00

This week I decided to grab the GstCollectPads2 patch (from bug #415754) and start a branch in my freedesktop repository for porting muxers to it. So far we've got:

oggmux
avimux
matroskamux (patch by Mark)
asfmux
qtmux

If you always wanted GStreamer to be able to mux subtitles into your movies, now is the time to provide specs/samples/patches for it. And installing from this branch (I try to keep them up-to-date with current git master) and test it a lot in you favorite applications would help to find regressions from the porting process.

Suggestions to improve GstCollectPads2 or other use cases are also welcome.

asfmux is now at gstreamer-plugins-bad

2009-07-24T11:05:00.000-07:00

I just pushed asfmux plugin into gstreamer-plugins-bad. So, forget the old repository, the recent code will now be at -bad.

And it now has mp3, wmv3 and wma3 support!

Live streaming of ASF content

2009-07-16T18:36:00.000-07:00

Just pushed a couple of changes to ASF muxer plugin that enable streaming live content of ASF media. Basically it contains some fixes to timestamping and a new boolean property to asfmux called "is-live". When enabled, asfmux won't attempt to push indexes at the end of the file (as this has no sense in live streams) and also won't try to seek back to the headers to rewrite some values that it couldn't predict when started the file.

Here is the simplest example of its use in gst-launch commands:

The sender:

gst-launch-0.10 -ve videotestsrc ! ffenc_wmv2 ! asfmux name=m is-live=true ! rtpasfpay ! udpsink host=127.0.0.1 port=3333 audiotestsrc ! ffenc_wmav2 ! m.
gst-launch-0.10 udpsrc port=3333 ! "put the caps here" ! rtpasfdepay ! decodebin2 name=d ! queue ! ffmpegcolorspace ! autovideosink d. ! queue ! audioconvert ! autoaudiosink

Remember to replace the caps after udpsrc with the caps of the srcpad of the rtpasfpay element in the first pipeline. If you have any problems using it, please report!

The asf plugin can be found here.

ASF: we need a parser

2009-06-23T13:24:00.000-07:00

While developing rtpasfpay I found out that I can't just do (in gst-launch syntax):

somesrc ! asfmux ! rtpasfpay ! udpsink

because the ASF headers need to be updated after the stream ends and those values are needed by rtpasfpay.

Additionally, I can't get an ASF from a file and feed it to rtpasfpay because the buffers would be unaligned with the ASF objects and packets, requiring rtpasfpay to parse the data before doing anything related to RTP. I'd say we need a parser.

The idea is to do all the parsing at the parser (obvious) and only some checks of conformance at the rtp payloader. As I had already started developing the payloader, I took it as farther as I could (without using a parser) and its current state is now at the repository. It is still unfinished (read: doesn't work).

The parser

Now I'm starting to develop the asfparse element. ASF files have 3 main parts: first there are headers, then the data (where the packets are) and lastly a series of indexes objects. The parser would, sequentially:

Group all the headers into a single buffer and push it
Push the "Data object" header (everything but the packets)
Put each packet into a separate buffer and push them
Put each of the indexes object into a separate buffer and push them
EOS

The parser should work both in pull or push mode, I'll start with push mode.

asfmux: index fixed, new formats

2009-06-15T06:35:00.000-07:00

Latest asfmux changes:

fixed simple index (seeking works)
Support for wma version 1
Support for wmv version 1
Preroll time property
Packet size property
file id generation (instead of a previous hardcoded all zeroes)

I'd consider it ready to be called a basic asf muxer.

Feature suggestions are welcome.

ASFMux progress report

2009-06-09T13:26:00.000-07:00

I ran some tests with asfmux yesterday and it is now capable of muxing wma2 and wmv2 nicely. Played the resulting files at totem, mplayer and media player.

The file indexes are still badly broken, so trying to seek might result in unexpected behaviours or crashing. I'm trying to fix that.

GSoC Status

2009-05-25T20:13:00.000-07:00

GSoC's coding period started saturday and, as I've been coding a little since the accepted students announcements, I've got some results.

With a lot of help from Mike, that is also working with ASF, asfmux currently is capable of muxing WMAv2 and WMVv2, which means that most of the base code of the muxer is ready. It still lacks the indexes, but that's what I'm working on these days.

Unfortunately, I still won't be working full speed at GSoC 'till the end of next week, when I'll be on university vacation.

If you'd like to take a look at the code, my repository is here.

ASF Inspect Tool

2009-05-06T18:33:00.000-07:00

So, if you are learning/working on ASF media, Microsoft has this tool[1] for Windows (it's free) that might help you, I just found it and haven't really tested it, just explored some files and it is much better than opening them in ghex.

[1] http://www.microsoft.com/windows/windowsmedia/forpros/format/asfviewer.aspx

GSoC '09 Start up

2009-04-29T20:15:00.000-07:00

Finally got some time to post here about me getting accepted into GSoC this year! Yay!!!

The project

Basically, develop ASFMux and RTPASFPay (or something more readable than this). ASFMux will be featureful, supporting stream prioritization, stream mutual exclusion and timed scritpting. David Schleef will be my mentor this year.

The GIT Repository (http://cgit.freedesktop.org/~thiagoss/)

I'll be hosting my code in my personal freedesktop git repositories. Initially I thought on using a branch out of -plugins-bad, but then I thought that it would be better to have a single plugin tree, because people can build and install without destroying their -plugins-bad install.

Current stage

So far I got a basic muxer stub and started working on sending the header bytes. The code at git has a trunk base folder, but that's because I started working with svn and them migrated to git, I'll remove that in my next push.

I just wanted to make the project start public. I'll be updating the status of it here regularly.

Now I need to get some sleep, it's getting late here. Good night!

GSoC '09 UFCG Status

2009-04-22T07:01:00.000-07:00

UFCG (Universidade Federal de Campina Grande) is the university I study at, and last year it seems that I was the only one that applied to GSoC.

This year, I decided to spread the word about it and motivate people to participate. When the program was announced I kept sending information and tips on the students mailing lists and giving short presentations about the program. Happily, we got 5 students accepted this year! Much better than only 1 last year. They are (name - project - course):

André Dieb Martins - Enlightenment - Electrical Engineering
Danilo Araújo de Freitas - Python - Computer Science
Felipe Ribeiro Nogueira Barbosa - PHP - Computer Science
Thiago de Freitas Oliveira Araújo - NuiGroup - Electrical Engineering
Thiago Sousa Santos (me) - GStreamer - Computer Science

Congrats you all and to all other accepted students. Time to work hard and complete your projects!

Telepathy tutorial

2009-04-09T07:40:00.001-07:00

That was the search I tried at google while I started to study telepathy, but it was amazing and funny the amount of tutorials I found on telepathy (the psychic stuff). I didn't try them, if someone feels up to it, please tell me how did it go :-P

After reading telepathy wiki, I went to #telepathy and davyd pointed me to the book they're writing, and so far it was the better source of information about it. If you are willing to learn about telepathy, try it out and give them feedback.

New feature on gst-launch

2009-03-27T05:30:00.000-07:00

Now you can add the flag --eos-on-shutdown (or simply -e), meaning that you want it to send EOS to the pipeline even when you stop it by sending a sigint (ctrl + c). This way, the EOS will travel through the elements, and they can finish properly their work. This is important for muxers.

When -e is enabled, if you press ctrl+c and it hangs while waiting for the EOS, just press again and the default behaviour will be executed (shut down the pipeline immediately and quit).

A example use case for the feature: to receive and mux live streams using gst-launch.

For the devels: the commit - the bug

Happy new year!

2009-03-12T16:49:00.000-07:00

This year had a slow start, but it seems that things are heating up.

1) I decided to be back on bikes (after 5 years), going twice a week for about 30km, starting at 5 AM. Surprisingly, I'm riding with the same group I used to and they remember me (I was 15 by that time!). Note: I need a new bike.

2) Google's Summer of Code is starting again this year and I'll try to participate again for GStreamer. From the tasklist, ASF muxing support and mpeg2ts interested me the most. But I'm open to suggestions.

Also, I've been asked to do a small presentation at the university to the Computer Science department (students and teachers) next wednesday. And I've already started reading ASF spec.

3) University classes are back (1 year to finish it!)

4) As my undergraduation is almost over, the amount of requests for small parallel projects has increased, which is good, most of them are simple web-based CRUD applications. They take little time and are a good source of money for a student.

Finally it is starting! Happy new year, everyone!

mpeg4 trouble

2008-09-18T04:12:00.000-07:00

Expanding qtmux to support mpeg4 was going all well, everything was almost ready! Then the ES Descriptor appeared. For .mov files it was only used for AAC description atoms. For mpeg4 it has to be used for every format, and:

This ES Descriptor has a DecoderConfigDescriptor that has 'objecttype' and 'streamtype' integer fields that would identify the stream format and I can find no info on how to map the formats to those values (other than AAC).
The DecoderConfigDescriptor has some 'bitrate' and 'decoding buffer size' fields which aren't usually provided by GStreamer, so I'm just filling that up with zeros.

If there is someone out there that knows how to map formats to those fields or any idea on how GStreamer could provide bitrate (perhaps tag events?) I'd really appreciate some help. I've been stuck for almost a week.

Also I've started to test the mpeg4 files in a PS3, too bad it doesn't give meaningful error messages.

AAC and MP3 at qtmux

2008-09-09T13:26:00.000-07:00

I know I just posted, but I'd like to make a separate post for this.

Jan Schmidt(thaytan) sent me a patch that got AAC and MP3 to work! Thanks!

And he also sent me an optimization patch!

GSoC summary and thanks

2008-09-05T06:39:00.000-07:00

Now that Summer of Code ended, I'd like to summarize what has been done around qtmux and some random thoughts around it.

Firstly, I'd like to thank the guys from GStreamer for letting me participate with them, specially to Win (my mentor) and Christian(AFAIK, the org leader for GSoC). Also to those that answered my daily questions at IRC (mainly Mike, David and Tim). This was a great experience, learned lots of stuff about muxing, GStreamer and quicktime/mp4 file formats. Thanks also to the guys from pitivi for reporting problems and their effort for already adding qtmux to it.

It feels great to see the community actively using, testing, reporting bugs and requesting features at this early stage of qtmux, this is really motivating! Also, it will be moving soon to GStreamer repos. That means more developers working on it, consequently better quality code and more supported formats.

Looking at the application proposal, most of the formats promised are already working, but qtmux still lacks the flavor selection. That's why the next step is adding isomedia ('isom') output format, some work is already commited, but it is still at an early experimental state.

Lastly, another thanks to you all (GStreamer and Google), I really enjoyed participating and I hope that qtmux is already usable and meeting the expectations.

A lot of help

2008-08-30T08:27:00.000-07:00

The last week has been unusually productive due to 3 people helping me with qtmux (well, everyday I get help from people at #gstreamer, but those 3 were directly helping).

In a non chronological order:

Edward Hervey (bilboed at IRC) did some changes to faac plugin and now we can have qtmux muxing mov files that contain AAC which play at totem (gstreamer) and mplayer. (Quicktime Player still can't play those).
Chris Cooksey is a possible future user of qtmux (one that really understands from the mov container) and while testing qtmux spotted 7 or 8 problems in the resulting files and reported me, so we fixed them (most related to timescale, dates and durations in the file).
David Schleef (ds at IRC) sent me a patch for adding Dirac support into qtmux (it works!).

Thanks to you 3.

finally h264!

2008-08-26T15:29:00.000-07:00

Just for letting you know: qtmux now supports h264 (and also a-law and mu-law)

Yay! \o/

Update on qtmux

2008-08-22T05:57:00.000-07:00

I've been through the semester final exams the last weeks (my university timeline is all messed up) and time was short, so I couldn't update here with news on qtmux, but the semester in now finally over, so here are the new features:

raw formats (both audio and video) and mp3 are working correctly in all players I tested (totem, vlc, mplayer and quicktime)
support for h263 has been added and also works on the players above
support for aac and amr has been added and it still doesn't work at quicktime, but works in totem and mplayer (vlc went nuts on my machine, and I still haven't got it to work again)
ilst atom metadata support (used by itunes and qtdemux) has been added

I couldn't get aac and amr working, after some days searching for specs and testing applications that could generate qt files with amr or aac with no success, I noticed too much time was being lost and started working on other features.
None of the applications I tested could generate a qt file (with amr or aac) that quicktime would actually play, and I couldn't find any useful spec. I also tried inspecting bytes in some files that played successfully, but just looking at them wasn't enough, the different bytes are easy to find, but not easy to understand.

I said that I would add flavor selection in the previous post, but I was advised to work on some widely used formats first, so I did it.

GSoC is comming to an end in the next days, but work won't, qtmux has still a lot to be worked on and I'll keep it up.

Good news!

2008-07-22T10:44:00.000-07:00

Qtmux has just generated the first mov files that have audio and video that plays synchronously. MPlayer and GStreamer were able to successfully play it, VLC couldn't (not sure why, yet). Still have to test it in another players. But this is a huge step.

Now, I'll probably be working on adding flavour selection (qt, mp4 or 3gpp) using a property in the element (maybe using caps?).

Raw video into qtmux

2008-07-21T11:32:00.000-07:00

Raw video formats were added to qtmux: 'rgb' and 'yuv' (only one 'yuv' format, but easily extensible to others). The current state is that it is possible to package video 'xor' audio into a mov file, and they are played fine.

What's keeping me busy now is to add support for synchronized audio and video. Some work has already been done, but it is still not as expected. I've re-read the spec trying to identify what info am I missing, still no clue, but I'll keep looking :)

New audio formats for qtmux

2008-07-10T12:29:00.001-07:00

Support for 8-bit and 16-bit pcm audio have just been added to qtmux.

I'm stepping now into video data. As it requires less knowledge about profiles and codecs, I'll start with raw rgb video. And then try to insert one format for compressed data (h263 or h264).

Inserting 8bit and 16bit pcm audio made me found a possible bug in qtdemux, already reported in bugzilla: #542410

The first one

2008-07-08T03:44:00.000-07:00

I should announce that the first mp4 file has been created using qtmux (at least, the first one capable of playing nicely). It is still only able of handling mp3 audio. But that means that the underlying mp4 library reached some stable level and now the work focus should be into the qtmux element itself.

Next steps:

Add another audio format support (probably raw audio)
Add video support (h263? Suggestions?)
Add multiplexing support (finally!)

I thought I was going to reach this goal before, but my graduation required some extra hours in the last weeks and mp4 atoms' fields given me some headache on understanding its semantics, mainly in how to define what media type (and parameters) for a track. 'qtdemux' has been a great help, it outputs some really helpful debug messages. Thanks for the guys who developed it! Great job!

Code is here: http://gforge.embedded.ufcg.edu.br/scm/?group_id=122

Refactoring

2008-06-19T17:10:00.000-07:00

I should have posted this before, but the code for GSoC is already hosted online at http://gforge.embedded.ufcg.edu.br/scm/?group_id=122 (there's info about checkout there, and also you can browse the code online)

After writing a lot of repetitive code for atoms serialization I decided to stop and rethink it. So, creating a function for serializing each type of property an atom can have made the code much shorter and better to read. This refactoring proved even more useful, when I found out that mp4 files had to be big endian, I did the changes to support it in no time, as I only had one spot to change.

Other than that, I've been using qtdump for validating my generated files, but sometimes it only reports "unsupported file type", and I need more than that. So, I'm also adding more verbosity to qtdump (and also qtinfo). I'm trying to make it able to tell why it is not a valid mp4 file.

As always, comments and critics on my code are very welcome.

GSoC First Lines of Code

2008-05-13T06:11:00.000-07:00

Since last week, I started coding the first lines of the qtmux (yes, that will be the name of the new plugin/element).
The muxer is still at an early 'draft state', but what concerns me more at this point is creating the MPEG4 Atoms hierarchy to be used by the muxer. This hierarchy will last during the whole project and it could cause some headaches later.

I thought of two main options:

Create a gobject class hierarchy: it is better organized and we could have some common interfaces, but it would be probably too much of a overhead
Create a 'struct hierarchy': composing structs is pretty easy and straightforward to do. Having common structs at the top place might also provide some common methods, but probably difficult to maintain

Structs seems better to me at this point, I'm for the KISS (Keep It Simple, Stupid) principle. And I also don't expect to be changing those atoms often (after my code gets stable, at least). But, of course, I'm accepting comments and sugestions and critics.

Other than that, I'll be starting a repository to put the code in the following days, so that interested people might take a look at it.

Let the games begin

2008-04-24T04:58:00.000-07:00

GSoC has just started this year (I've been accepted :D) and I'll use this space to provide information about my ongoing work. My project is to create and develop the quicktimemp4mux plugin for GStreamer.

For the past weeks, I've been studying specs and code on mpeg4. Right now, I'm starting to think on how to validate the resulting files my plugin will be able to generate. Some options that have already been suggested to me:

use qtdump to inspect the files
use a GStreamer pipeline to play the files

Other than that, I'm also wondering what could be my first goal at the plugin implementation, and I think that being able to create a mpeg4 file that contains only one audio track (possibly mp3) would be a nice start.

That's it, I hope that GSoC will be fun and, mostly, that I manage to finish a good quality plugin so that everybody gets happy :D