KSE 0.1 released !

I just finished fixing the blocker bugs for the open source assets' manager KSE, and I pushed a release there : https://github.com/MathieuDuponchelle/Kerious-Resource-Editor on the branch 0.1.

I recorded this screencast to make a demo of the features included in this release.

I want to say thank you to Simon Corsin for his work on the windows port and manual management.

I'd be glad to see pull-requests on github, or comments, critics and feature requests here.

Here is the text of the video for those with no audio:

Hi, my name is Mathieu Duponchelle and I am glad to present you the first release of kse, which is
a tool to simplify asset's management written in python.

This release covers spritesheet creation, sprite naming, automatic sprites detection in an existing spritesheet,
animation referencing and tons of other stuff.

Spritesheet creation.

Let's create a new spritesheet, and start importing resources.
First we create what we call an "atlas", specify its width and height and the location of the resulting file.
Then we can specify the size we wish the next sprite to have, and start adding sprites by double-clicking.
Next step is to start naming all these sprites, for now the naming part is a bit tedious, but it works.

Animation referencing.
Another cool feature of KSE is that we can reference animations easily, using multiple selection.
Let's say these sprites belong to the same animation.

We now save the project, and have a look at the xml that was produced.

We can see that a simple xml parser could easily extract coordinates for a given name, here X.

Automatic sprite detection.

Let's now say that we want to use an already existing spritesheet. I have this one, which will make for a good
demonstration.
A really cool feature is automatic sprite detection, which can be configured with this button.
Match-size will specify the desired width and height multiples for the resulting sprites.
Now let's try it out !
As you can see, KSE detected the sprites and automatically highlighted them. However, if the position or size
of any sprite does not match what we intend, we can easily resize and move them using the mouse or, if we want
a more fine-grained control the comboboxes that we have here.


Conclusion.

With some friends of mine, we already developed a space shooter using KSE.
This helped me finding out the features that were most needed.
It can greatly improve the collaboration between designers and developers, by reducing the number of back and forth
trial and errors, allowing the programmer to only parse the xml file looking for the sprite or the animation name,
and thus not having to hardcode coordinates, which is an obvious advantage, and allowing the designer to try things
without having to modify the code or asking the programmer to do so.

KSE now works on both linux and Windows, it has not been tested on OSX yet.

My thoughts for future features are listed in the poll on the right-hand side of the blog, don't hesitate to comment if you have other ideas/remarks/critics. Thanks for watching !

Homework :)

I had plenty of other things to do today, so I iterated from that code :
http://encrypt3d.wordpress.com/2007/06/19/level-order-traversal/ , which I found pretty elegant.

Function of the code:

Breadth first tree traversal, display the level and show if the node is the first one of its level (starting from the left).

Missing:

As it was homework, I had to give the is_first property. What would be better would be to display the order of the node in the level.
Also, wondering about the best way to display a tree.
May'be starting by the bottom ?


Code:


typedef struct s_infos
{
  int is_first;
  int level;
  t_btree *node;
} t_infos;

t_infos    *create_new(t_infos *par, t_btree *n, int first)
{
  t_infos    *q;

  q = malloc(sizeof(t_infos));
  q->node = n;
  q->is_first = first ? 0 : 1;
  if (par)
    q->level = par->level + 1;
  else
    q->level = 0;
  return(q);
}

void    levelorder(t_btree *p,
        void (*applyf)(void *item,
                   int current_level,
                   int is_first_elem),
        int *size,
        int *qptr)
{
  t_infos    **queue;
  int    *tab;
  t_infos    *q;

  q = create_new(0, p, 0);
  tab = malloc(sizeof(int) * 100);
  queue = malloc(sizeof(t_infos *) * 100);
  while(q)
    {
      applyf(q->node->item, q->level, q->is_first);
      if(q->node->left)
    {
      queue[*size] = create_new(q, q->node->left, tab[q->level + 1]);
      *size += 1;
      tab[q->level + 1] = 1;
    }
      if(q->node->right)
    {
      queue[*size] = create_new(q, q->node->right, tab[q->level + 1]);
      *size += 1;
      tab[q->level + 1] = 1;
    }
      q = queue[*qptr];
      *qptr += 1;
    }
}

void    *btree_apply_by_level(t_btree *root,
                              void (*applyf)(void *item,
                                             int current_level,
                                             int is_first_elem))
{
  int    size;
  int    qptr;

  size = 0;
  qptr = 0;
  levelorder(root, applyf, &size, &qptr);
}

Usage:

Let root be the root of the tree, and applyf the adress of a function returning void and using as arguments the data of each processed node, its level and its is_first property (Crap how useless is that ..) Also, t_btree is a classical node structure containing the left child, the right child and the data.

Also, today I coded a function that allows you to insert a data in a red black tree.
I'll try to post that  when I have time, it's a little longer but I think it's worth it.

Weekly report number 6 and 7 for my GSoC

Hi everyone !

These last two weeks were pretty busy for me.
First off, last week I reached my mid-term evaluation goal, which was to load a GESTimeline with xptv projects thanks to my GESPitiviFormatter, then load a GESTimelinePipeline with the timeline, then connect it to the viewer in Pitivi, all of this using my python bindings for GES. This was a long sentence but quite a short job, and this was still pretty hacky.
Afterwards, I played around a little with projects, only to realize that I had a nasty bug with the interaction of effects and transitions, which obviously came from my formatter. This was in the middle of last week.

After this discovery, I moved in to another flat, and the end of the week was not really filled with working.

I started to tackle this bug by the beginning of this week, and I must admit it took me a long time to figure out where it came from (the respective priorities of transitions and effects, which determine which object is "above" and which is "under" had to be set in the appropriate way), and still longer to fix it : once I made out how everything had to fit together, I also realized that the calculating of the needs in terms of transitions had to be refactored, I needed to compare the sorted track objects one after another, and not the track objects belonging to the sorted timeline objects one after another. I hope I'm clear enough, anyway I had to add a function to the GESTrack API to achieve this, which makes me think I'll also have to update the bindings aha.

Also, during this week I broke my scooter, and that didn't help me in concentrating on my problems. It now lies in pieces in my yard waiting for me to fix it or for someone to steal it xD.

Anyway.

These bugs are now fixed, and I can now attack the rest of the integration with a free mind.

I will now explain you how to checkout my work and give it a try, if you find bugs don't hesitate to contact me.

This is if you don't use jhbuild :

First, you'll need pitivi. After that, you'll need the latest gst-python, then you'll have to get to my GES repository, which is at https://github.com/Mathieu69 as usual. You'll want to checkout the "integration" branch, autogen it *without* prefix (this is due to the CONFIGURED_PYTHON_PATH in pitivi, will fix that when I'll have time), make and make install.

To test the bindings : ipython, from gst import ges. If it imports, fine ! You're nearly done. Otherwise, mail me with the traceback.

Afterwards, all you'll have to do is go to my pitivi repo, and checkout the "intcheck" branch. Just switch to it, launch pitivi, and load a project *using the start up wizard*. You'll then be able to press play and profit :D You can also pause, undock the viewer, and that's pretty much all xD.

Anyway, what's interesting is to compare the playback between master and my branch, you'll be able to see the difference in smoothness ;) GES makes playback nearly smooth, it only lags a little when transitions start or if you think that a clip is way cooler with agingtv, chromium, color lookup table filter, vertigo TV, and whatever effect *at the same time*, where in pitivi and with my computer you can only see one picture every 2/3 seconds, with no transitions. When transitions or effects kick in, you just want to switch to pause and go ahead by hand, it's nearly smoother ;)

If you have issues at any point of the testing, mail me or directly come to pitivi's IRC channel, my nick is Mathieu_Du.

Voila !

Second weekly report for GSoC

Here is my weekly report for the second week of GSoC :

Hi !

I've spent my week refactoring my formatter, and after successfully integrating the effects handling, I've banged my head against the track objects wall.

My first version worked fine, but I had worked around the following problem in a way that was not the ideal one :

When you create a timeline object, the track objects are not immediately created, and when timeline objects are ungrouped in Pitivi, you want to access the track objects of the timeline file sources to move them accordingly. I worked that around by creating two file sources when needed, and setting one mute and the other blind.

My new version added a "track-object-added" signal to GESTimelineObject, which I caught to move the track objects accordingly. This worked fine, but there is now another trouble : transitions added after track objects were created are not taken into account, even if GST_DEBUG tells me they were really added. I have a good test case that shows that, and I pushed that yesterday for bilboed and thiblahute to have a look.

I just started to have a look at the unhandled argtypes in the bindings, and I will work this week-end to get back in my schedule.

I'll be able to use the old version of the formatter to start integrating it anyway, for the API will not change when the refactoring is done.

By the next report, I plan to have finished the bindings, to have them merged soon, cause other GSoCers will need them. I will then start the integration, to reach the goal of my mid-term evaluation : having pitivi load projects, and see them in the viewer.

Have a good week-end :)

I have been lurking and hacking Pitivi's source code for quite a while now, and I think it is now time for me to sum up my opinions about it.


The first time I launched it, I had just installed Ubuntu and the version I had was 0.13.4, without the effects and anything. I was new to coding, so the only thing I could judge about it was the user interface and how everything fitted together. And I must admit that I thought : "Wow ! This is not what I would use if I wanted to make a short movie or anything .."

Anyway, I started messing up with the code, making my way through the architecture with wild prints and crazy changes, and I quicly reckoned that Pitivi was only the visible part of a greater framework, namely GStreamer, and that this framework really rocked, and gave Pitivi an unprecedented advantage on what existed before : A solid community, with hundreds of active members, all of them dedicated on taming the wild beast which is media handling, writing a great number of plugins ranging from codec handling to effect creation or object transformation !

Pitivi was nothing but the editing emerged part of the iceberg, and a part which was still to grow to its real size. After all, the version naming is not random, the 0.13.x name means that it really is not mature yet, and misses a bunch of basic features essential to video editing, listing them would be too fastidious.

But the whole point of my argumentation is that I think Pitivi has bet on the good horse, cause now that I begin to know a little more about GStreamer's internals, I realize the power that lies in its architecture : Flexibility and Modularity, through the use of combinable elements to form new elements, which in turn can be combined to finally make complex pipelines, ready to be played or rendered at will.

I don't know well the other available frameworks, for example MLT, but what I know is that I love GStreamer, and a lot of other people look like they love it as well, shaping up the biggest media framework community by far.

That's why I stuck up to pitivi until now, eventually applying for a Summer of Code to be able to give it still more of my time, and I can say now I'm happy of my choice. Indeed, a long-awaited release has just arrived, shipping a whole lot of goodies, first of them being the effects handling, and I can see some lines moving. Pitivi's IRC channel has never been so active, and new enthusiastic developers wannabe's pop up every day. On top of that, Gstreamer and Gnome have allocated no less than 4 Summer of codes to us (against only one last year) which means we're gonna be able to take this software to a new level :

1. One GSoCer is going to implement complex object recognition algorithms (robust estimation of Optical flow), which will make pitivi conscious of the different layers (background, foreground) and moving objects in a video.
2. Another will use Gstreamer filters to provide object's transformation options to the user, and also give titling support to Pitivi, another essential feature that it was lacking until now.
3. The third one will allow users to upload videos to streaming websites such as youtube or dailymotion, and also provide them with rendering presets (IPod, YouTube, Android Phone etc..).
4. I will integrate a new C library in pitivi, which will replace a lot of its backend with C optimized functions, making it more performant in the process, and allowing new features
    integration (for example new kinds of transitions, the default one for now being the classical overused crossfade).

This is exciting isn't it ? I can't wait to see the next release, which will hopefully come way faster than the previous one. Kudos to thiblahute for bringing it to us !

My Google summer of code weekly report number 1.

Hi everyone !

I started working on my project before the actual Summer of Code began, and I already successfully compiled the static bindings with a code coverage of about 90 %, wrote the beginning of a test suite for them and a basic example script.

Since then, effects have been merged in GES master, so the .xptv file formatter I had written has got outdated, and since it's a critical component of my project, I decided to update it before going on with the bindings, in the hope of getting a near 100% code coverage.

This has involved some massive refactoring, since I had not clearly envisioned the way the formatter would work with the effects (shame on me ;), and I'm not done yet : effects are integrated, but I still have to re-integrate the transitions properly).

However, work is going well, and I'm not blocked anymore on my way to integrating GES in pitivi, given one of the members of the IRC channel gave me a hand on solving the problem of GST argtypes that were not properly handled by the code generator I use to create the bindings.

By the end of next week, I will surely have finished my work on the formatter (code cleanup, fixing of the tests), and I hope to have solved the GST argtypes problem completely as well (This could be the matter of 2 or 3 hours of coding if everything goes as intended). With some luck, I'll be able to write overrides for the last 10 or 12 functions as well, which will leave me free to attack the real meat of my project, i.e. integration in pitivi proper.

Most of my problems this week were very specific to my project, and I don't think they'd be very useful to anyone.

Change in the plans !

YouTube law-kicked us so I had to find more suitable streamers.

I just implemented archive.org and blip.tv and it rocks.
Archive has a very serious, research-oriented(but not only) database, with private collections and plenty of available formats for most videos.
The only problem I see with it is the 'picture coming soon' on 3/4 of the thumbs..
I hope it's true :)
That is not a problem with blip.tv, which is more youtube-like. You only get .flv on the other hand.
Anyway, I'm now lurking for another friendly streaming site. Any suggestions accepted :)