Saya Video Editor official Blog

Codec Plugins, and image reading!

2011-04-30T15:36:00.000-07:00

So I've managed to finish writing the core of the codec plugins. As a result, I've been able to code an image-reading plugin using Qt's built-in image library. There are still some stability issues (i.e. crashing), but now files can be opened with the appropriate codec thanks to codec plugin auto-detection.

Here's a snapshot of a double-click on an imported resource, in this case, a .jpeg file (A nice Ultraman painting by Bruce White).

New playback controls (v2)

2010-12-10T22:15:00.000-08:00

Slowly working on the look and feel of our playback controls.

New Playback controls

2010-11-15T22:17:00.000-08:00

Hello everyone!

Just wanted to show off the new playback controls. They're integrated into one independent Qt Widget. They're 90% functional (still need to write a few routines, and some testing still needs to be done) and user friendly:

Clicking on an area of the seek slider does not jump to undefined locations anymore, but to the exact position you want. This was possible thanks to the slick event filtering code in Qt.
The shuttle slider now shows a tooltip telling you the current playback speed.
The seek slider shows the exact time corresponding to the mouse cursor position (a-la Youtube(TM) seeking)
The Play/Stop button has been magnified for easy mouse access.
The Mouse wheel has been disabled on the seek slider and the shuttle, but enabled in the volume and the jog.

Behold, ladies and gentlemen, our future playback controls!

I'm back!!! (kinda)

2010-11-13T18:33:00.000-08:00

Dear everyone: After having to bear what seemed to be the worst year of my entire life, suffering the flu, unemployment, a huge debt and personal relationships problem, I have a couple of good news for ya.

1) I have a stable job!! And a very good one, to be honest. It doesn't give me too much free time, but it has helped me to develop my programming skills. My latest toy was a JSON to HTML template engine (this project was actually what led me to the next news).

2) Development on Saya has been restarted!... kinda. Don't get your hopes up, Saya is from now on considered a long-term garage project, with very little chances of succeeding. But I'm committed to at least deliver a usable GUI for a video editor. Instead of focusing on the multithread processing and video handling, I'll start over with the GUI now. Later, if the GUI seems good, and the widgets work, I'll work on tying Saya to an existing video editing framework.

3) The latest development on the UI is the playback control, now with a jog dial for easy frame skipping:

(Yes, the buttons are ugly, but later we can work on that). Next: Making the shuttle control (to the left of the "Display" text) pretty, and functional.

4) If you would like to join the project and help me perform code archaeology on the project (and find out what the hell I was doing on some files), you're welcome to join.

See ya!

I'm sorry to inform you that the project is officially dead.

2010-01-10T05:41:00.000-08:00

Dear fans and enthusiasts:

As much as I dislike doing this, it's time to accept reality and face the fact that I don't have any time left to work on the project.

Saya has been really a great project for me, and it filled me with hope and fun. It was a great garage project, but it lacks something critical for an open source project: Leadership.

Why?

Let me tell you the story of why the project "failed". Actually, it's not the project that failed, but me. It's not about Saya but about me, and I hope that my failure will enlighten other Open Source developers out there, so that they can avoid making the same mistakes that I made.

No, the project didn't fail. It's not the project's fault. It was my fault and mine only. I want to be clear on this: I still believe that the specs are good, and that the project is viable and could become successful if I had free time to dedicate myself to it (if I received, say, a million dollars, after 6 months I would be able to finish my daytime job and dedicate myself completely to the project). I say this because I want to defend the idea behind the project (using C++ and cross-platform libraries instead of a development language like Python with an unstable spec and/or linux-only libs) and emphasize that the reason why the project "failed" (again, in quotation marks) is not because it was a bad idea, but because I lacked what it took to make it grow and mature. It was a project with a great potential, and I failed to take good care of it.

If someone wants to take my place and rewrite the main part of the project from scratch, by all means, please contact me. It will take a lot of time to understand the project, maybe even a full year, but once you do, I'm sure you'll be able to do a better job than I did.

So, here's the story:

The project was technically unstable when a personal crisis arrived (I got sick with AH1N1, all in the middle of the economic crisis of 2008/09, WHILE I was unemployed - go figure). You could say that the project got infected with the swine flu and died. Worst of all, we were in the middle of a heavy refactoring (switching from wxWidgets to Qt) and I was fixing various bugs in the still-under-development audio/video library. How could I compare the circumstances? Imagine you're performing a heart transplant on a very weak patient, and then an earthquake arrives and the hospital is in a blackout. You're the only doctor around and then you get hit by a lamp that just fell from the ceiling. You survive, but the patient dies. This is what happened to Saya.

As an apathetic open source programmer who had no interest in the economic world, Wall Street and all that, and not living outside the US, I had severely underestimated the consequences of the economic crisis. I thought that with my technical skills, I would be able to easily get another job. Welcome to the real world. This, and due to family situations, I wasn't able to remember that the project even existed. It disappeared completely from my depressed mind. See, I lived with my parents, and I discovered we had a huge credit card debt (not my fault). Being unemployed, all this gave me a nervous breakdown around July/Aug. 2009, which only made it worse. So the project was completely out of the radar for me. All I could think about was to survive, get a job, get it fast, work overtime to pay some debts (which we still have), and now save enough money to get my own house and find a girlfriend (did I mention I got hit by the mid-30's crisis, when I hadn't even considered getting a girlfriend?).

In other words, the worst of Murphy's Law applied to me. What would go wrong, did go wrong, and it went wrong when it was the worst moment to go wrong, around the worst circumstances, and when going wrong would have the worst consequences.

It would have been different without the AH1N1 outbreak, without the 2009 economic crisis, without the family credit card problem and without my depression. Perhaps the project would have reached 1.0 by now, like the Openshot Video Editor project did.

So, after clarifying the personal circumstances around the project, I'd like to go to the technical part and my mistakes when starting the project.

Around a year and a half ago, I started the project from scratch because I needed a working cross-platform video editor. After starting it, I realized that to start an open source project required much more than technical skills. It required human skills, i.e. leadership.

It took me a lot of effort to design the website, the project infrastructure, i.e. class diagrams, sell the idea to other programmers in forums, and gather a team.

For the first few months I welcomed enthusiasts, some of whom, unfortunately, lacked the technical skills and/or the perseverance that an Open Source programmer requires. Some of them just wanted a fun project to participate in; others weren't committed and never attended the monthly meetings. Others just wanted a nice stamp on their resumes. So it took me several months to gather a working team.

Then came the decision to choose a toolkit. Originally, I had chosen wxWidgets because of it being cross-platform. But it seems that this toolkit isn't quite welcome in the Linux world. It's the "ugly duckling" of GUI toolkits. People just don't take it seriously, and its community is somewhat isolated. So I realized the need to switch to Qt (which by now is stable, LGPL and with tons of features). It was needed, otherwise we would end with a crippled UI - something you don't want to deal with in a Video Editor.

Another decision I made was to choose the Audio/Video toolkit. Around the time, I was forced to choose between GStreamer+GNonlin and MLT. Having glanced at them, I found that the codec parts of the toolkits were tightly coupled to the editing parts. It was all or nothing, and which toolkit I chose would dictate the architecture for many of the classes.

So I decided to make a wrapper and stay only with the codec parts. The wrapper was going fine, and I was technically proficient to make a good wrapper and at the same time develop a low-level audio / video library that handled the streaming. I said proficient, because I was in the middle of doing all this when the crisis arrived. I could never finish the core library for the project.

So, what was my contribution to the project's failure? After studying several leadership and economic books (kudos to Robert Kiyosaki for his Rich Dad Poor Dad series of books, they made me understand many things we all need to know), I realized that starting an Open Source Project is 99% similar to starting your own company. If you want it to be successful, that is.

Before I start with this comparison, allow me to mention the "bus factor". A project's Bus Factor is an irreverent measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would need to be incapacitated, as by getting hit by a bus, to send the project into such disarray that it would not be able to proceed. Getting hit by a bus could take many different forms. This could be a person taking a new job, having a baby, changing their lifestyle or life status: the impact would have the same effect. In my case, it was the flu, the crisis, and our personal economic problems.

So yes, at the time, Saya had a Bus Factor of 1. I was aware of this. I needed to finish the audio/video framework and finish the Qt conversion as soon as I could. Otherwise, the project might not make it. And it didn't.

Having said this, please let me continue with the similarities between an Open Source project and a Startup.

According to Robert Kiyosaki, for a company to be succesful you need the following areas:

Product
Legal
Systems
Communications
Cash flow

Product: The product is the project, as a software. It was in the process of being developed.

Legal: In this, the Open Source / Free Software community has a great advantage. It has the General Public License, and the aid of the Free Software Foundation to deal with companies stealing our code for their profit.

Systems: This is a fundamental part of an open source project. In a company, the system is the office and the technical parts of the product / service. For open source projects, you need to develop good specs and documentation so that everyone can understand the project in case you're unavailable. You also need to have a website, a forum, a good issue tracker like Sourceforge or Berlios, and possibly a wiki.

Communications: Another important part. It covers part of what I mentioned under "systems", but also needs you to be a good salesman and sell the idea to others.

Cash flow: Without a good cash flow arriving to all the team members (which, in case of a company, it comes from the sales), the project is doomed to fail. No cash flow, no time to develop. If there's no time to develop, then all the other parts of the project start to crumble: People stop going to meetings, they don't read their emails, important issues stop being addressed, they just don't have time to fix bugs (patches welcome), and it's only matter of time until the project dies.

As you can see, in Saya, everything was working so far. The design and implementation was going well (product), we were using the GPLv3 (legal), we had a nice website and bug tracking system (systems), we had an IRC channel and held monthly meetings, and the blog has been receiving contributions and support from all around the world (communications).

And then we come to cash flow. I won't need to repeat myself, but you can understand why everything went down.

If you start an Open Source project, please take consider these hints:

Make sure you got a stable income. This is especially important if you're the project leader.
Make sure that the people you gather at the beginning are committed to the project. Even if you start with only one good contributor, having that one is better than having 5 or 6 people that you delegate tasks to, and then don't show up. Otherwise you'll lose several months reteaching what you had to teach the people who left the project.
Do NOT try to do it all by yourself. It's much better if you have a partner who can understand your technical view of the project, and can assist you with the modules you write. Make sure the project has a bus factor of 2, at least.
Do spend some effort on getting donations. Don't wait for the project to succeed to then ask for donations. First comes the cash flow, then everything else. Tell the donors beforehand that it's not probable the project will survive, so it's a risk their money will go to the garbage. But still, if you believe the project merits having a good donation income, train yourself in sales and practice. Find people who want to contribute. Go search for philantropists who can give the project a constant cash source. At least for you, if you feel you're going to have economic troubles.
Make sure your life is stable at the moment (no emotional problems, no economic problems, no pending baby to arrive), at least until the project reaches critical mass.

A closing note:

It is very, very sad for me to cancel this project, but I can't lie to myself anymore. I don't have the time to work on the project, and to be honest, I somewhat lost interest. Right now I have to focus on paying those debts and get a house for me and my future wife and children, and ... of course, on getting a wife in the first place. I'm too old right now, around 35, and time is running out for me.

I really can't express my grief in taking this decision. The project had so much potential, it was like my own child. The worst part is knowing that after given so much hope and ideas, I saw the project turn to dust in my own hands. It's very painful. I want to say "no, I won't give up, the project needs me, I still can do it", but that would be fooling myself and giving false hope to others.

To the person who donated $20 to my Paypal account, I'm very sorry. I thank you for your donation... if only I had 1000 more people who donated when I needed that money, the project could have made it. But now I'm not able to continue on the project, even if I received that million dollars. I signed a contract and I need at least 6 months to be free to work on the project again... *if* I get a good donation to be able to work full time on the project for at least two years.

At least I'm happy that the Openshot Video Editor, has matured enough and reached version 1.0. Congratulations to you.

Having said this, I thank everyone who contributed to the project. Thank you, and farewell.

Sincerely,
Rick.

Is it dead yet? No. There is hope.

2009-07-10T17:24:00.001-07:00

Hi everyone. Just wanted to remind you that I'm still willing to work on Saya. I've been through a terrible chain of depression and bad luck, but I've finally overcome it. I got a new job opportunity, and this one really looks promising.

I hope that soon my schedule will stabilize so I'll be able to work on Saya after nearly 4 months of inactivity.

If you want to read more about what has happened, please read the related entry on the unofficial blog.

Thanks for staying in touch.
- Rick.

Project stalled for reasons beyond our control

2009-04-30T10:15:00.000-07:00

Bad news. With my bad luck in finding a job, the current flu epidemic and having to deal with an unexpected depression (mostly based on my economic situation), I can't keep working on Saya until I get my life back.

So the project is stalled and the meetings are suspended until further notice (which I hope will be in a couple of months in the best case).

I hope to come back soon with good news.

Sincerely,
Rick.

Saya Developers' meeting #6 (28/03/2009) Summary of Activities

2009-04-06T15:19:00.001-07:00

This is a brief summary about what has been discussed in the fifth Saya-VE developers meeting.

About the team:

* Agustin has not been seen since the last meeting. We're assumming that he just left the team.

* This happened after the meeting. I got an email from another volunteer wanting to join. I let him experiment with the latest snapshot of our current code in the meantime.

* Due to his good work so far, Alex was given write access to the SVN repository.

About the tasks:

* The Qt conversion is around 60% done. The welcome dialog is completed, the new project dialog layout is done (C++ implementation pending). The playback controls still need to be adapted into the video player.

* Tasks for Rick (me): Since I couldn't advance at all this month (workload / health reasons) I still have to convert the main window and the video playback controls.

* Tasks for Lubomir: Write the developers' guide for Windows (it needs to be changed as now we use Qt, not wxWidgets). He had some technical problems writing them, but he's working on it.

* Tasks for Brad: Get to compile Saya on Windows with Qt, and help Lubomir in doing so.

* Tasks for Alex: Study more Qt, play around with the code.

* Tasks for Rigo: Implement in C++ the new project dialog that he had designed; write a market-oriented "mission statement" document.

Other Issues worth discussing:

* Jeff found a blog entry about Video Editing. Basically we agreed with the blog entry in that there are currently not working user-friendly video editors.

About the next meeting:

* The next meeting will take place on Saturday, May 2, 2009, 11AM CDT (-0600).

Saya Developer's meeting #6 (28/03/2009) chat log

2009-04-06T12:20:00.001-07:00

* Now talking on #saya-dev
<rick_777> This meeting is officially open.
<RigoCalleja> * BANG *
<rick_777> heh
<RigoCalleja> first task assigment status?
<rick_777> First of all, i'd like to apologize for my lack of work. This month I couldn't do anything. zip. nada. zero.
<rick_777> (I got too much work, then i got sick, then i went on vacations)
<RigoCalleja> you had the conversion to QT assigment
<rick_777> Well I guess that's still pending from my part, but I'll resume work this week :)
<rick_777> Rigo, what task was assigned to you?
<RigoCalleja> k
<RigoCalleja> new project dialog
<rick_777> status?
<RigoCalleja> status: done
<rick_777> Cool!
<rick_777> Have you uploaded to SVN yet?
<RigoCalleja> yup
<rick_777> ok... who's next?
<mau5> i'm done with the gmerlin document
<rick_777> Alright! Please send it to the mailing list.
<mau5> and that demo application; mixing bewteen qt and gmerlin
<rick_777> hmmm about the application, just mail us the source code (zipped)
<mau5> yes, it needs a review
<rick_777> oh wait, you're using gmerlin...
<rick_777> well send your code anyway.
<mau5> i send it few weeks ago
<rick_777> Good :)
<mau5> it's uploaded on the saya gmail group
<RigoCalleja> SeekerAll.tar.gz ?
<mau5> yes
<rick_777> Ok... (man, I feel disoriented after not doing anything for a while)
<RigoCalleja> don't worry
<RigoCalleja> you'll be back in business
<mau5> i will upload the document now
<RigoCalleja> Ok let's move on to the next team member
<LubomirD> Me: I'm still not done with the developers guide: I still could not compile Saya, so I could'n write a normal guide. I had a lot of mess with it.
<rick_777> Ok, I'll help you with it then
<LubomirD> Thank you
<rick_777> I'm afraid that we're stuck in a bottleneck and that bottleneck is finishing the Qt conversion.
<RigoCalleja> sort of
<brad_gar> I almost have saya compiled on windows, I think I have the wrong version of Qt as I'm getting a moc error or something to that effect
<RigoCalleja> but We're also making enablement progress
<rick_777> I guess that what we can do now is finish the conversion (and the dev. guide) and when we're finished, we'll mail you the new tasks, if any.
<brad_gar> just downloaded the latest from the sdk, not the 4.4.3 version
<mau5> @brad: try qt 4.4.3
<rick_777> Yes, it seems there are no problems with qt 4.5.
<RigoCalleja> Brad: feel free to join Lubomir and Rich if you need to
<brad_gar> k
<rick_777> I spoke with brad and his only problem so far is downloading and installing gettext and the libintl library on windows.
<brad_gar> got that working!
<rick_777> oh?
<rick_777> So you managed to compile Saya, or stumbled on another problem?
<brad_gar> yup
<rick_777> yup compile, or yup stumbled?
<brad_gar> now its telling me that the Qt moc is too different, so I think downloading the 4.4.3 version should fix that
<rick_777> hmmm
<rick_777> i guess you should install 4.4.3
<brad_gar> just ran out of time yesterday
<rick_777> 4.5 is out, but it didn't go mainstream yet.
<rick_777> we'll need some time before it's present in all repos.
<rick_777> linux distro repositories, i mean.
<RigoCalleja> k
<rick_777> so for now we'll stick to 4.4.3
<rick_777> Well, I guess that's all we can do for now
<rick_777> (bummer)
<rick_777> now
<rick_777> I recall there were some issues worth discussing, right rigo?
<rick_777> something about a blog
<RigoCalleja> can you repeat your task assigment approach for these month Rich please?
<rick_777> Ok
<rick_777> our task assignment:
<nekohayo> goddamnit, I was at the restaurant O_o is the meeting over?
<LubomirD> you cando this with the moc problem :) instead: #elif Q_MOC_OUTPUT_REVISION != 59 you have to put #elif Q_MOC_OUTPUT_REVISION != 61
<rick_777> brad: please help lubomir compile on windows. I feel there's some potential synergy in you two
<rick_777> nekohayo: Not yet :)
<RigoCalleja> what's up Jeff
<brad_gar> will do!
<rick_777> lubomir: Go on with finishing the developer's guide.
<nekohayo> hey there folks :)
<LubomirD> yes
<rick_777> hi Jeff
<rick_777> Alex: I hate to say this, but i think that we're stuck and you have no pending jobs for now... you can still try to analyse the source :)
<nekohayo> hey there rick_777, RigoCalleja, and all others, sorry for being late
<RigoCalleja> not to worry
<rick_777> I guess it's the same for Rigo
<mau5> no problem
<RigoCalleja> k
<rick_777> But hey, better have extra devs than having extra job and no devs :)
<RigoCalleja> can you give us feedback on the status of the conversion please?
<rick_777> Ok, the status of the conversion is... the same that it was last month with the exception of the New Project dialog.
<RigoCalleja> elaborate?
<rick_777> Ok...
<RigoCalleja> just as a reminder
<rick_777> let's see...
<rick_777> the debuglog is finished and operational.
<rick_777> the resources/effects panel is in progress, but the window / splitter is working, and it can be docked.
<RigoCalleja> anything else?
<rick_777> the enabling / disabling of menu items is nearly finished ( the labels menu is unfinished)
<rick_777> The Saving and Loading of window layout is finished and operational.
<rick_777> the video playback controls are working (the UI part) but we still need to incorporate the video output.
<rick_777> the timeline is at 0%, just as it was before the conversion :)
<RigoCalleja> OK if I can help you with some of that please let me know
<rick_777> the new project dialog...
<nekohayo> this is all in svn 272 I guess
<RigoCalleja> is it Rich?
<rick_777> i gues, let me see if i can update my SVN copy.
<rick_777> kdesvn
<rick_777> oops wrong window
<RigoCalleja> Ok Jeff you turn, what did you this month?
<nekohayo> uh, I flamed?
<RigoCalleja> we worked on a proposal for a vision document
<RigoCalleja> based on the basic unified process template
<RigoCalleja> and information from the mission document
<nekohayo> well, basically, Rigo worked on it
<rick_777> (Also, the new project dialog seems to be finished at designing, but it's not incorporated yet)
<rick_777> Before we go on to that document...
<RigoCalleja> are you taking it or passing that task to me?
<rick_777> Rigo, mind giving me a hand with the new project dialog? I'd like you to incorporate it into the source code (i.e. compile the UI file into a c++ file, modify the events so that a new project can be created using the UI)
<nekohayo> RigoCalleja: you mean the .doc you sent me?
<RigoCalleja> k
<rick_777> ok, so what's about this doc
<RigoCalleja> yes that one Jeff
<rick_777> please update us
<nekohayo> rigo started writing a more marketing-oriented mission statement
<RigoCalleja> Jeff and I went through the mission document
<rick_777> cool
<RigoCalleja> exactly
<rick_777> but why .doc? why not opendocument?
<nekohayo> instead of a technical rebuttal of other approaches
<nekohayo> rick_777: I would have asked the same question :)
<nekohayo> but I guess it was not on purpose
<RigoCalleja> so we have only started working on it
* brad_gar has quit (Read error: 104 (Connection reset by peer))
<RigoCalleja> when we have something we'll share for comments
<nekohayo> RigoCalleja: I'm looking at the document right now
<rick_777> Ok. So, Rigo and Jeff, you keep working on that document. By the way...
<nekohayo> my take is that 1) you had all the essentials of it filled in nicely already 2) the feature list == the roadmap, no need to do it
<rick_777> you might find Google Docs interesting. You can work on the same document at the same time.
<nekohayo> so I thought it seemed ready
<RigoCalleja> good idea Rich
<nekohayo> yeah, I used google docs a lot. but then, as I said, I believe that document to be pretty much ready anyway
<rick_777> So I guess Rigo has a double task this month: Working on the New Project dialog...
<rick_777> and finishing that document.
<RigoCalleja> k
<RigoCalleja> In adition
<RigoCalleja> Jeff shared a link to a blog
* brad_gar has joined #saya-dev
<RigoCalleja> to a person that's is knowedgable about video editors
<brad_gar> back
<nekohayo> eugenia?
<RigoCalleja> she basically reaches the same conclusion as Rich
<RigoCalleja> exactly
<rick_777> welcome back brad
<RigoCalleja> that current GNU/Linux editors are hard to use
<nekohayo> not so sure that she reaches the same conclusions as rick.
<RigoCalleja> lack features
<rick_777> Rigo passed me the link... let me see if i have it around.... nope, lost it.
<nekohayo> oh, on that point yeah
<RigoCalleja> Jeff do you mind sharing to the list?
<nekohayo> I guess you meant http://eugenia.gnomefiles.org/2008/01/20/video-editor-mockup/
<rick_777> yes, that one
<nekohayo> eugenia is one of the founders of osnews.com and a Vegas user like me
<nekohayo> the mockup that she shows in that blog post is STRONGLY influenced by vegas
<rick_777> hmmm that means that if we get saya to work fine, and make it rock solid as she wants,
<rick_777> we could get a boost on publicity ;-)
<nekohayo> you'll have to beat pitivi and kdenlive to that game :)
<rick_777> for kdenlive i have no worries. It's not rock solid :P
<RigoCalleja> Jeff and I identified those projects as important contenders
<nekohayo> sure, but neither is saya-trunk ;)
<rick_777> What "worries" me is pitivi, with all the extra help they're really adding a lot of features
<rick_777> but competition is good :)
<rick_777> Also, I've been surfing around blogs, and the Openshot video editor (the other guy who started a project around the same time as me),
<rick_777> switched from GStreamer/GNonlin to MLT (same as kdenlive)
<nekohayo> well, that one didn't sound quite serious, but I haven't checked its progress lately
<rick_777> I guess the design choice to make Saya framework-independent was a good one.
<rick_777> Now we can be sure that gnonlin isn't reliable as a video editing framework.
<RigoCalleja> gnonlin?
<rick_777> A gstreamer add-on for video editing
<RigoCalleja> thnkx
<RigoCalleja> ok are there adittional comments?
<rick_777> Ok, I guess that is all for now... any comments?
<rick_777> heh, you beat me
<nekohayo> rick_777: and how can you be sure it isn't reliable?
<rick_777> Jeff: From the OpenShot author's comments about it
<nekohayo> in my case, it is more reliable than kdenlive ;) and I throw lots of bug reports/weird test cases at the devs
<rick_777> let me link you to it.
<nekohayo> sure
<rick_777> http://www.openshotvideo.com/2009/03/mlt-vs-gnonlin-lets-get-it-on.html
<nekohayo> pitivi is currently the only video editor in the world (except imovie) that can handle my camcorder's files
<rick_777> I guess that blog post is becoming a flamebait, which is good for analysing pros/cons from a 3rd person point of view.
<nekohayo> interesting
<nekohayo> the first comment is from the developer of pitivi and gnonlin
* nekohayo reads the blog post
<RigoCalleja> why don't you share your comments on the blog post to the list Jeff?
<nekohayo> *if* I have something relevant to say
<RigoCalleja> k
<rick_777> Ok...
<rick_777> i guess there are no more comments for now
<RigoCalleja> one more
<RigoCalleja> team
<RigoCalleja> guy from india?
<rick_777> it seems his willpower is not enough to come to the meetings :)
<RigoCalleja> and Agustin from Spain?
<rick_777> same about him... haven't heard of him in the month.
<RigoCalleja> k
<RigoCalleja> no more comments here
<rick_777> but right now we're back to the 5 devs + 1 beta tester, and that's not bad
<rick_777> I think our team is complete for now.
<nekohayo> wait a sec
<rick_777> yes?
<nekohayo> ah, it's 23 PM in india. Thought it was later than that
<nekohayo> anyway
<rick_777> yes?
<nekohayo> reading through the blog post, to begin with, mp3 support works... if you uninstall the fluendo mp3 codec package in ubuntu (stupid thing. I bugged the pitivi devs about that, but for "political" reasons, they can't blacklist it). Second, diva never switched from gstreamer+gnonlin to mlt
<nekohayo> diva just *died* when the dev underwent burnout
<nekohayo> the rest is answered by bilboed
<rick_777> I see.
<RigoCalleja> one thing
<rick_777> Oh man, we have so much ahead of us. We still haven't got to the point of really editing videos...
<rick_777> but a long journey always starts with one step!
<nekohayo> ... ;)
<rick_777> Ok. Any more comments, anyone?
<RigoCalleja> one more
<RigoCalleja> Alex access to the repo
<rick_777> mind rephrasing that please?
<RigoCalleja> we were probably going to give him access this time
<rick_777> Oh
<rick_777> Right.
<rick_777> let me scroll back.
<nekohayo> rick_777: and what about this decentralized version control system migration ?
<mau5> do you mean git?
<rick_777> Jeff: Still pending, sorry.
<nekohayo> bazaar is on my mind
* nekohayo hates git for various reasons :)
<rick_777> yes, from Jeff's comments, bazaar is much more friendly than git
<nekohayo> this whole "commit access" thing sounds crazy when you are blocking other devs "because I'm still converting everything to QT myself"
<rick_777> wait, that wasn't the reason for blocking access...
<nekohayo> I thought it was part of the reason
<nekohayo> the other being the "prove your worth before getting access"
<rick_777> yes. And for that I'll give Alex write access.
<RigoCalleja> k
<nekohayo> in a DVCS, natural selection occurs. code happens. and when it's good, it is merged
<rick_777> Well, I still don't think it's the right moment to change the version control system.
<rick_777> sorry.
<nekohayo> your call
<RigoCalleja> I'll add a research task tough
<mau5> http://excess.org/article/2008/07/ogre-git-tutorial/
<mau5> good git overview..
<RigoCalleja> great thanks Alex
<mau5> i just heard about bazar, but dont know anything
* nekohayo has a huge .txt file of notes about the hoops he has to go through to switch branches/update a branch in git :)
<nekohayo> holy crap
<nekohayo> that "git: the basics" slideshow
<nekohayo> 277 slides!
<rick_777> Alex, what was your berlios username?
<mau5> alext
<nekohayo> (for contrast: the "bazaar for SVN users" http://bazaar-vcs.org/BzrForSVNUsers )
<RigoCalleja> Rich: assign a research bazaar task to Alex?
<nekohayo> at least if you need help getting started with bazaar, I can give a hint or two, I've been using it extensively for a year
<nekohayo> (I was using svn before that, and cvs before that)
<mau5> ok, thanks
<rick_777> well, the bazaar research is optional. If you want to do it, Alex, go ahead.
<mau5> anyway, i put your link in my bookmarks
<rick_777> BTW, i just finished changing your permissions to read/write.
<RigoCalleja> k
<rick_777> In a couple of days you'll be able to write to the repository.
<mau5> thank you
<rick_777> I guess this is all for now.
<rick_777> Any last thoughts?
<RigoCalleja> are you going to stay to help Lubomir Rich?
<rick_777> Yes, after we close the meeting.
<RigoCalleja> k
<rick_777> This session is now closed.
<rick_777> *bang* :)
<RigoCalleja> :)
<RigoCalleja> thank you everyone for attending
<RigoCalleja> see you later
<brad_gar> I'm going to stick around also
<LubomirD> see you all
<mau5> have a nice remaining weekend :)

Saya-VE developers' meeting #5 chat log

2009-03-04T11:31:00.000-08:00

<rick_777> This meeting is officially open.
<LubomirD> Ok!
<rick_777> First of all, I'd like to congratulate those who joined.
<rick_777> Our new recruits are Brad Garrick (who is having connection problems but was about to join)
<mau5> thanks, glad to join you, for me it;s my first time
<LubomirD> thank you
<rick_777> , Lubomir Dobrovodsky and Alexandru Tirvea
<RigoCalleja> Rick: I guess it's Tirdea
<rick_777> I'd also like to congratulate Alexandru (can we call you Alex?) for his dedication and enthusiasm, and for helping me fix a bug
<mau5> yes , Tirdea is correct :-)
<rick_777> oops
<rick_777> Tirdea
<rick_777> my mistake
<rick_777> Now, let's get to business
<rick_777> As you can see, we're in the middle (or three quarters, actually) of our conversion from wxWidgets to Qt
<rick_777> so development per-se is stalled until we finish the conversion
<LubomirD> ok
<rick_777> this is the reason why there hasn't been a lot of development activity. Don't worry, things will pace up with time.
<rick_777> So, I'd like to ask who has been having troubles installing and compiling Saya
<LubomirD> I am trying to compile it on Windows XP and it is still not possible for me.
<mau5> i posted in a thread a small how-to about compilling Saya on a windows 2000
<rick_777> Lubomir: Have you been updating the source code on a daily basis?
<rick_777> from the SVN repository
<LubomirD> Yes
<rick_777> Ok. I think Alex managed to compile Saya on WinXP, right?
<mau5> yes
<rick_777> Please share, what did you have to do?
<mau5> first you have to install gettext
<RigoCalleja> Rick: Alex compiled it on Win 2k If I remember correctly
<rick_777> 2k is nearly the same as xp
<rick_777> there's not that much of a difference
<mau5> yes, i compilled on win2k but i think there are no significant differences between various wins
<mau5> yes
<rick_777> so what steps did you have to do? Set up environment variables? Change code?
<rick_777> project settings?
<LubomirD> Ok, I wil try to follow correctly the instructions of Alex, maybe I just misesd something
<rick_777> etc
<mau5> but as a small hint, take care to install gettext directly in the mingw directory
<rick_777> Speaking of compiling...
<LubomirD> Aha, ok, I will have to check this
<rick_777> I think you're the best person to do this task Lubomir
<rick_777> remember the Developers' guide that I wrote?
<LubomirD> yes
<rick_777> That one's designed for wxWidgets.
<rick_777> What do you think about rewriting it for Qt4 ?
<LubomirD> Thats a good task to do
<rick_777> you'll write the windows version, of course
<RigoCalleja> Rick: Btw the project's website still references wxwidgets
<rick_777> this way I can use the extra resources (you) while Alex, Rigo and I concentrate on getting the conversion finished
<LubomirD> Of course, I will do it
<rick_777> perfect
<rick_777> I will e-mail you the .odt
<LubomirD> Great
<rick_777> (You'll need to install OpenOffice.org )
<LubomirD> No problem, I have it
<RigoCalleja> Lubomir: or sun's odt plugin
<rick_777> great! :)
<RigoCalleja> lubomir: did I assign you a task in berlios?
<LubomirD> I'm using OOo 3 :)
<rick_777> perfect! * * * * *
<LubomirD> Rigo: I think no... I think I forgot to send you my profile - it is ld_orifiel
<rick_777> Now, about the tasks to be done
<RigoCalleja> Lubomir: Thanks I'll add you to the project
<rick_777> Rigo will start giving out tasks to people on developer.berlios.de
<LubomirD> Rigo: thank you
<rick_777> The official dev site is http://developer.berlios.de/projects/saya/
<rick_777> just in case you missed it.
<rick_777> no, wait
<rick_777> https://developer.berlios.de/projects/saya/
<rick_777> there. The https is *very* important.
<rick_777> Before we go on with the tasks, I'd like to give you a glimpse of how Saya code works.
<rick_777> on the SVN code, there are various directories:
<rick_777> saya/
<rick_777> saya/core/
<rick_777> ui/
<rick_777> ui/ui
<rick_777> ui/moc
<rick_777> plugins/
<rick_777> resources/
<rick_777> saya/ contains the library for editing the in-memory objects (clips, effects, etc)
<rick_777> saya/core contains the core routines: Multi threading, I/O, file access, etc.
<rick_777> ui/ contains the code for the GUI.
<rick_777> ui/ui contains the .ui.h files that are generated with Qt4-designer
<rick_777> (accessible in the menu Form -> View Code... then copied and pasted)
<rick_777> ui/moc contains the .moc.h files generated with the moc-qt4 commandline utility
<rick_777> these are the ones handling the events
<rick_777> The reason for generating the .ui and .moc files separately is so that we won't need the qt tools (only the libraries) to compile the source code.
<rick_777> this is a bit annoying but it's worth it, as it makes the code compatible with all makefile generators.
<rick_777> the resources/ directory contains the qt resources (also generated beforehand) in .rcc format
<rick_777> Lubomir, you may need to write about that in the Dev's guide, too
<LubomirD> Rick: I understand
<rick_777> resources/ also contains the .qcc files (these are the ones that get compiled into .rcc) and the images (usually .png or .jpg)
<rick_777> That's about the code paths
<rick_777> About the code structure:
<rick_777> what we call the "Core" is a set of classes and functions needed for low-level stuff. As I said, it's in the saya/core/ directory.
<rick_777> On top of the Core is the saya library (which isn't compiled as a library yet) for handling the objects.
<rick_777> The saya library contains some important classes:
<rick_777> VidProject (will have a project's info),
<rick_777> ProjectManager (which opens and saves projects)
<rick_777> PresetManager (takes care of presets)
<rick_777> and PlaybackManager. This is the most recent one, and will take care of video/audio playback objects
<rick_777> basically, we have a 3-tiered system:
<rick_777> CORE / Objects / UI
<rick_777> this is to keep the code portable.
<rick_777> I've also added into the core specialized functions for saya-specific event handling
<rick_777> (which don't depend on Qt or wxwidgets event model)
<rick_777> string handling
<rick_777> etc.
<rick_777> Right now, what we're doing is converting the wxWidgets code in the ui/ directory to use the Qt functions.
<rick_777> What took me the most effort was adapting the event handling stuff, wxWidgets and Qt have completely different event models. But you won't have to worry about it, it's finished.
<rick_777> As soon as we finish the conversion, we have some pending tasks:
<rick_777> * Finishing the playback engine so that it reproduces a hardcoded animation into the screen
<rick_777> * And using 3rd party codec libraries to read .avi files, etc.
<rick_777> But right now, we need only to worry about the UI
<rick_777> This will be a very important step, because we'll get back to the UI later: We'll need to drag and drop clips on the timeline and do all kinds of fun stuff with them.
<rick_777> So we need to eat and breathe Qt
<rick_777> Any questions so far?
<RigoCalleja> "eat & breath" lol
<RigoCalleja> Rick: No questions here
<LubomirD> No questions right now
<mau5> it's ok for me
<rick_777> perfect.
<rick_777> I guess this is all for now. Let's summarize.
<rick_777> Tasks for Lubomir: Get to compile Saya on Windows with Qt, and rewrite the developers' guide for Windows.
<LubomirD> got it
<rick_777> Tasks for Rigo: Convert the New Project dialog to Qt
<rick_777> Tasks for me: Convert the rest of the main window to Qt
<rick_777> Tasks for Brad: Get to compile Saya on Windows with Qt, and start learning Qt and do some practice projects separately.
<rick_777> brb
<RigoCalleja> Rick: Alex is missing
<mau5> i'm here
<mau5> :)
<rick_777> Oh
<mau5> waiting for my tasks
<rick_777> also, everyone please download the Qt Assistant
<RigoCalleja> Alex: task assigment I mean
<rick_777> so you can have an offline-help.
<rick_777> Alex: I'm still wondering what tasks I can give to you...
<RigoCalleja> Rick: remember you assigned the gmerlin task to Alex
<rick_777> Ah yes. I guess you'll have to stick to research.
<RigoCalleja> Rick:it's on BerliOS
<mau5> yes
<mau5> last week i just played with qt/gmerlin
<rick_777> perfect!
<mau5> trying to seek a avi and rendering the frame in a QPixmap
<mau5> it's almost done...
<rick_777> Okay then :)
<mau5> the frame meaning a .bmp in the first stage
<rick_777> keep up the good work. When you finish I'll see if i can give you another task.
<mau5> :P
<rick_777> Also, help Brad and Lubomir with any Saya compilation doubts they have
<mau5> sure
<rick_777> I guess that closes the tasks section.
<rick_777> Any other questions / comments?
<RigoCalleja> what about agustin and the guy from India?
<rick_777> Agustin had told me in a chat 2 weeks ago that he didn't have much time to connect on Saturdays
<rick_777> And there was a guy from India who wanted to join the project
<rick_777> I told him to join the chat
<rick_777> And obviously, he's not in here :)
<RigoCalleja> Rick: ok
<rick_777> Generally I'm wary of new recruits
<rick_777> especially if they don't show up to the meetings
<rick_777> by the way, Alex. Depending on your performance this month,
<rick_777> we'll give you write access to the repository.
<rick_777> :)
<mau5> ok, i'll do my best
<rick_777> Any other questions?
<RigoCalleja> Rick: no questions here
<LubomirD> no...
<rick_777> perfect.
<rick_777> This meeting is now closed.
<rick_777> *bang* :)
<LubomirD> Thank you all for this meeting and have a nice weekend!
<mau5> have a nice weekend you too
<rick_777> you too
<RigoCalleja> Same to everyone

Saya developers meeting #5 (2009-02-28): Summary of Activities

2009-03-04T11:12:00.000-08:00

This is a brief summary about what has been discussed in the fifth Saya-VE developers meeting.

About the team:

* Four new developers joined:
- Alexandru Tirdea from Romania. Alexandru has been very active since the day he joined, and has already helped me to tackle a few bugs. It's most probable that the next month he'll be given write access to the repository.

- Lubomir Dobrovodsky, from Slovakia
- Agustin Rubio from Spain (who couldn't attend the meeting)
- Brad Garrick from the U.S. Brad couldn't connect to the meeting on IRC but was online at the time.

* Rigo has been promoted to project administrator. His management skills are impressive, and he keeps the team in a fast pace.

About the tasks:

* To help the newcomers get to know Saya a bit better, I gave an explanation about how Saya's code is written and organized.

* The Qt conversion is around 50% done. The welcome dialog is completed, the playback controls were done by Rigo and I'll adapt them to remake the video player.

* Tasks for me: I will be working on converting the main window and the video playback controls. If I finish soon, I'll go on fixing the video playback framework.

* Tasks for Rigo: Convert the New Project dialog to Qt

* Tasks for Brad: Get to compile Saya on Windows with Qt, and start learning Qt and do some practice projects separately.

* Tasks for Lubomir: Write the developers' guide for Windows (it needs to be changed as now we use Qt, not wxWidgets)

* Tasks for Alex: Finish the research and report on gmerlin and codec libraries.

* Tasks for Agustin: Learn Qt, I guess (we ran out of tasks :P )

About the next meeting:

* The next meeting will take place on Saturday, 28 March 2009, 11AM CDT (-0600).

Screenshots from the Qt conversion

2009-02-22T08:44:00.000-08:00

Hello everyone! I'm glad to inform you that the Qt conversion has achieved its "critical mass", and we're starting to see the first fruits.

Ladies and gentlemen... Allow me to introduce you to... Saya in Qt!

Welcome dialog

File open dialog

Main Window with (partially) the main menu

Of course, there's still work to be done like enabling/disabling the menus, updating the recent projects menu, and of course, the playback window. But at least we're progressing! :)

Four new developers joined!

2009-02-08T17:15:00.000-08:00

Great news everyone! Since last December, the number of volunteers who applied for membership is four.

The new recruits are:

Lubomir Dobrovodsky, from Slovakia
Alexandru Tirdea, from Romania, I think.
Agustin Rubio from Spain
Brad Garrick from the U.S.

Welcome to the team, guys! Note: You're currently under probation until you earn your worth as a developer. Then you shall be given write-access to the repository. Until then, changes will be submitted as patches.

Saya developers meeting #4 (2009-01-30): Summary of Activities

2009-01-31T10:29:00.000-08:00

This is a brief summary about what has been discussed in the fourth Saya-VE developers meeting.

About the team:
* Javier Galicia and AbsoluteDestiny were kicked out due to inactivity (and not answering e-mails).
* We have two new volunteers: Alexandru Tirdea, who unfortunately couldn't go to the meeting - but has been working on Video display on Linux, and Lubomir Dobrovodsky, a longtime Java programmer who's been incursioning in C++.

About the tasks:

* The most important task so far is the Qt conversion. Without finishing it, we can't go on. On the bright side, the main menu items are already present in the main Qt window (altho they're all enabled by default and the checkbox items behavior hasn't been programmed yet). As I haven't finished determining what changes need to be done to the code, other areas of development are stalled (I really need to hurry up with this).
* Work on the playback framework has been stalled (see above).
* Lubomir is going to train his C++ and Qt skills so that when I need him to add features and
* Rigo is going to research about the new video editor from Apple (iMovie, I think) and is going to send me some links to post on the "research" section of the website (which needs to be polished, of course).
* Jeff has suggested using the bazaar distributed version control system to speed up development. We discussed about it a bit, but unfortunately I have very little free time right now. But I'm considering adopting it.

About the next meeting:

Due to people from Eastern Europe joining, we've changed the meetings to the Saturday following the last Friday of the month (which most of the time will be the last Saturday of the Month), at 11AM CDT.

Saya developer's meeting #4 (2009-01-30) chat log

2009-01-31T10:22:00.000-08:00

* rick_777 has changed the topic to: meeting tonight at 8PM
* nekohayo has joined #saya-dev
* rick_777 gives channel operator status to nekohayo
<rick_777> :)
<rick_777> oops wrong window
* Rigoberto__ has joined #saya-dev
<Rigoberto__> good evening
<Rigoberto__> sorry I'm late
<rick_777> Ok
<rick_777> brb
<Rigoberto__> Hi Jeff
<nekohayo> hello there
<Rigoberto__> what's up?
<rick_777> Ok, let's officially open the meeting
<Rigoberto__> cool
<rick_777> all agree?
<Rigoberto__> q: did you receive communication from the two new devs?
<rick_777> today, nope. But they said they would attend
<rick_777> maybe (again) there was some timezone problem :P
<rick_777> OK, so if there are no objections, the meeting is officially open.
<rick_777> *bang*
<rick_777> Now, it's been 2 months since the last meeting and a lot of things have happened
<rick_777> let me check the blog so I don't forget any.
<rick_777> There have been a lot of changes in the core
<rick_777> we have a new string class,
<rick_777> we have plans to migrate to CMake... (once I get Qt working)
<rick_777> the playback framework is almost working...
<rick_777> more core advances...
<rick_777> http://saya-dev.blogspot.com/2008_12_01_archive.html
* LubomirD has joined #saya-dev
<rick_777> WELCOME!
<LubomirD> Hello to all am I late?
<Rigoberto__> Howdy
<rick_777> yes, but the other developer was late too :P
<rick_777> so we started 10 mins ago
<rick_777> Alright, before we start talking about you, let me give again a summary of events that happened during December and January
<rick_777> http://saya-dev.blogspot.com/2008_12_01_archive.html
<rick_777> * New lightweight string class
<rick_777> * Migration to CMake proposed (still pending)
<rick_777> * Playback framework nearly finished - but stalled for the Qt conversion
<LubomirD> Ok great
<rick_777> * Qt conversion about halfway done :)
<Rigoberto__> halfway?
<rick_777> it's a rough approximation
<Rigoberto__> you did come up with an estimate!
<rick_777> +/- 50% :P
<Rigoberto__> cool
<rick_777> actually it might be around 30 or 40
<rick_777> but that's better than nothing :)
<LubomirD> yes of course :)
<Rigoberto__> I believe percentages doesn't work for software
<rick_777> i believe that, too, but the public needs an estimated figure ;-)
<Rigoberto__> but this is dev meeting ;p
<rick_777> at least the welcome dialog and the main menu have been converted
<Rigoberto__> what's left?
<rick_777> everything else
<rick_777> re-do the playback controls
<rick_777> implement the menu events
<rick_777> implement the menu items disabling on-request
<rick_777> and everything else that I hadn't done yet while in wx
<Rigoberto__> k
<rick_777> *AHEM* going back to the events
<rick_777> two people offered to join,
<rick_777> Lubomir,
<rick_777> and ...
<Rigoberto__> (papers noise)
<rick_777> Alexandru Tirdea, who I assume couldn't attend the meeting
* LubomirD_ has joined #saya-dev
<rick_777> whoa
<rick_777> what happened
* rick_777 has kicked LubomirD from #saya-dev (rick_777)
<rick_777> hello?
<rick_777> Did you get disconnected?
<LubomirD_> yes i am here
<rick_777> ok
<LubomirD_> No
<LubomirD_> I dont know wha thappened
<rick_777> Just be careful
<LubomirD_> yes
<rick_777> you don't want to get cloned and banned by the irc server on accident
<rick_777> try to keep only one window open
<LubomirD_> ok
<rick_777> Also, since it's already 9PM, the time for the people who were about to be kicked has expired.
<rick_777> Say goodbye to Javier Galicia and AbsoluteDestiny
<rick_777> total contributions to the project: Zero
<LubomirD_> so we start
<rick_777> Out with the old, in with the new.
<rick_777> Lubomir, what time is it there?
<LubomirD_> 4.00 AM
<Rigoberto__> Slovakia?
<LubomirD_> Yes :)
<rick_777> wow
<rick_777> you really put a lot of effort in there. That shows commitment
<Rigoberto__> we should definitely reschedule the meetings for morning america afernoon europe
<LubomirD_> Thats the reason I am late... I am sorry I was sleeping too much
<rick_777> maybe we'll move the next meetings to 9PM, is that ok?
<Rigoberto__> what about 10AM on saturday?
<rick_777> that'll give you an additional hour to sleep
<rick_777> 10AM?
<Rigoberto__> 10AM Central
<Rigoberto__> GMT -6
<rick_777> How about 11?
<rick_777> at 10 I'm usually eating breakfast :P
<LubomirD_> And to me it will be?
<rick_777> 6PM
<rick_777> you're 7 hours ahead of us
<Rigoberto__> GMT + 1
<LubomirD_> Aha, It would be ok
<Rigoberto__> is that ok with you Jeff?
>nekohayo< CTCP PING
* Ping reply from nekohayo: ? second(s)
<rick_777> Ok while Jeff responds, tell us more about yourself, Lubomir
<nekohayo> you need to mention my nickname, otherwise xchat doesn't notify me of messages
<rick_777> Oh
<rick_777> ok
* nekohayo reads
<rick_777> so, are you Ok with 11AM saturdays?
<nekohayo> what timezone?
<rick_777> yours
<rick_777> no wait
<rick_777> mine
<rick_777> 11AM CDT
<Rigoberto__> correct
<nekohayo> yeah, no prob I guess, I get up at 6-7
<rick_777> perfect.
<rick_777> New meetings will take place 11AM on the saturdays after the last friday of the month
<LubomirD_> Great
<rick_777> (yes that sounds complicated but please bear with me)
<nekohayo> I'd rely on you to update the google calendar for that :)
<rick_777> ow, my weakness
<nekohayo> so that it shows up on my calendar ;)
<rick_777> Ok. I'll try
<rick_777> remind me to update the calendar if I forget
<Rigoberto__> or an email to the list?
<rick_777> ^^;
<rick_777> yeah that works, too :)
<LubomirD_> :)
<rick_777> Lubomir, are you on the list already?
<nekohayo> you do know that you can set recurring events, right?
<LubomirD_> Yes I am
<LubomirD_> I am on the list
<rick_777> I deleted Javier Galicia now that I was there
<rick_777> hey, Alexander also joined the list
<rick_777> :)
<rick_777> maybe next meeting we'll see him
<rick_777> So, Lubomir
<Rigoberto__> why don't you set up the recurring event for the meetings now?
<rick_777> eh?
<Rigoberto__> I'm looking at the calendar now
<rick_777> Oh
<rick_777> I'll set up one
<rick_777> thanks for the info
<LubomirD_> So I am 25 years old
<LubomirD_> I am a professional Java programmer at Accenture
<rick_777> yes, tell us more about yourself
<LubomirD_> I've been working there for 2,5 years right nnow
<Rigoberto__> I used to work for Andersen Consulting (Accenture's former name)
<LubomirD_> Yes? That was pretty long time ago, not?
<Rigoberto__> Yeah! 1998-1999
<rick_777> ok
<LubomirD_> ... and I have also some little experience with C++
<rick_777> great, tell us more about it
<LubomirD_> I am programming some little home projects to learn more about C++
<rick_777> cool
<LubomirD_> and I made a little game for school project
<rick_777> Okay. Now, let's do this. Try to make some GUI projects using Qt.
<rick_777> and Code::Blocks IDE.
<rick_777> most of the work we'll do at Saya (after dealing with the codec / encoding stuff) will be the UI
<LubomirD_> Ok, I am learning Qt from the book about Qt 4 so I have no problem with it
<rick_777> so we need people to work on the timeline, buttons, controls, and all that
<rick_777> great! :)
<rick_777> Well, for now that's all you need to do because I still haven't finished the Qt conversion
<rick_777> and until I get things clear, I'm afraid I can't give directions for now
<rick_777> if we were in the military, the order would be "regroup!"
<rick_777> :)
<LubomirD_> :)
<Rigoberto__> lol
<rick_777> Hopefully I can have the conversion finished by the next meeting.
<LubomirD_> Do you have some ideas about how it should look?
<rick_777> Have you seen the screenshots on the website?
<rick_777> Nearly Identical, but with Qt :)
<LubomirD_> Yes
<LubomirD_> Ok, I will start with it
<rick_777> eh?
<nekohayo> rick_777: another advantage of using a decentralized VCS
<nekohayo> is that you could do all your QT switch stuff in a special branch, while others work in parallel on the core or whatever
<rick_777> Lubomir: I just hope you didn't misinterpret me. I meant: Work on personal "hello world" projects for now
<rick_777> until I get the main project fully working on Qt. Then you'll join and fix bugs / add features
<LubomirD_> And do you want the GUI to be made in Qt designer or handcoded?
<Rigoberto__> Jeff's raised and interesting point
<rick_777> You can try both... I'm designing the main window using the Qt designer.
<LubomirD_> Ok, thanks
<rick_777> Ok, so I guess the Qt conversion topic gets settled for now.
<rick_777> As Lubomir's joining.
<rick_777> You're now officially a member of the team. Welcome! :D
<rick_777> Now, onto Jeff's suggestion.
<LubomirD_> Thank You!
<rick_777> Using a decentralized version control system.
<rick_777> I like the idea, but I don't want to try out too much new stuff at the same time.
<Rigoberto__> Lubomir: Don't forget to send Rick you profile
<rick_777> I'm having a hard enough time with Qt already
<LubomirD_> ok I will
<Rigoberto__> Lubomir: is Lubomir your name or nick?
<rick_777> After the conversion's finished, we can discuss the usage of a DVCS.
<LubomirD_> name
<rick_777> Ok
<Rigoberto__> k
<rick_777> e-mail me your profile so I can add you to the webpage
<rick_777> Also, I'll need you
<rick_777> to get a sourceforge account
<rick_777> and a berlios account
<rick_777> the sourceforge account is for public relations
<rick_777> the berlios will be for submitting patches and commits, etc.
<LubomirD_> Ok, I understand, I will handle it
<rick_777> Ok.
<Rigoberto__> Rick: but I guess Jeff's point has to do progress management
<rick_777> Let's see... what's next?
<rick_777> Oh yeah. Lubomir, were you the one I asked about the project's mascot?
<LubomirD_> Yes I already asked my friends, I am waiting for their reply
<nekohayo> rick_777: so you're saying we should wait for a long work in progress to be finished before actually using a tool that allows you to manage just that?
<nekohayo> (see the irony?)
<LubomirD_> They are good experienced manga drawers
<rick_777> nekohayo: Yes, I can see the irony...
<rick_777> I'll try to be fast...
<rick_777> Ok, tell you what. I'll begin studying DVCS tools, but I don't promise anything quick.
<rick_777> Also, the job's been keeping me offline and tired
<Rigoberto__> I've done branches in clearcase and tfs
<Rigoberto__> no subversion tough
<rick_777> hmmmmmmmm
<LubomirD_> I understand that, I have also much work
<nekohayo> subversion is madness for branches and such, it is not a decentralized VCS
<nekohayo> it's in a completely different league
<rick_777> Ok.
<rick_777> So, in summary:
<rick_777> * Lubomir will work on learning Qt
<rick_777> * I'll work on finish adapting the code to Qt
<rick_777> AND learn a DVCS.
<rick_777> * Rigo will help me with the video playback controls (this time in Qt)
<rick_777> while Jeff.... keeps giving suggestions and feedback ^^;
<rick_777> which is no small feat, of course.
<rick_777> I guess that concludes our meeting. Anything else?
<Rigoberto__> one comment
<rick_777> Please share.
<Rigoberto__> or suggestion
<Rigoberto__> Mac release a new version of their video editor
<Rigoberto__> released
<rick_777> Oh
<Rigoberto__> since UI is top priority for Saya
<nekohayo> imovie?
<rick_777> we should copy it
<rick_777> right?
<Rigoberto__> I saw some pictures of it. It looks very user friendly
<rick_777> excellent!
<rick_777> Ok, Rigo, this is your new task: Collect ALL the information you can get on iMovie
<Rigoberto__> I don't remember the name
<rick_777> or whatever it's called
<Rigoberto__> k
<rick_777> video links, screenshots, tutorials, papers, etc.
<Rigoberto__> :)
<rick_777> and we'll post it on the "research" section.
<Rigoberto__> cool
<rick_777> Anything else, guys?
<Rigoberto__> did you decide what to do with the first donation?
<rick_777> oh - no, I haven't decided yet.
<rick_777> I guess it's still there, sitting as a "symbolic" donation
<rick_777> :P
<LubomirD_> :)
<Rigoberto__> so what about Alexandru?
<rick_777> Do you suggest me to donate it to the FSF?
<rick_777> Alexandru hasn't answered yet. But I have the feeling we'll hear about him... soon.
<Rigoberto__> since we need developers so badly
<rick_777> yes, we do
<Rigoberto__> I suggest we use it to hire a few programmer hours
<rick_777> i doubt $10 dollars will be of any use
<Rigoberto__> so what do you know about the donator?
<rick_777> he makes Anime Music Videos. Made one for AMV Hell 3 (or 4) i think.
<Rigoberto__> Interesting
<rick_777> Yeah. Anything else?
<rick_777> questions, doubts, suggestions
<LubomirD_> one comment...
<nekohayo> hiring programmers with that donation: *facepalm.jpg*
<rick_777> Lubomir?
<LubomirD_> did you see the Qt developer?
<Rigoberto__> I've heard in India a programmer makes 1000 bugs a year
<Rigoberto__> through some classes specs at elance
<Rigoberto__> just tought could work
<nekohayo> you'd have more luck buying a python book for working on pitivi or a cup of coffee to work on kdenlive, if you depend on that
<rick_777> Lubomir: Which Qt developer?
<LubomirD_> Sorry -Qt Creator - you can code in it and it has integrated Qt designer
<rick_777> Hmmmmm
<LubomirD_> It is in beta relase, but it will befinished and open source soon
<rick_777> Well, I don't want to rely on a specific software
<LubomirD_> Ok
<rick_777> Also, I'm not very fond of Qt's approach (preprocessing files before compiling them).
<rick_777> I like to have 100% C/C++ so I can modify it.
<LubomirD_> I understand
<rick_777> but use what makes you feel most comfortable (note: You'll end up having to use CodeBlocks, since it's our official tool)
<LubomirD_> Yes, I am programming most time in Code Blocks :)
<rick_777> but well, that's what programming is: Learning :)
<rick_777> Ok. I guess that's the last question for today.
<LubomirD_> yes :)
<rick_777> And guess what, it's an hour since the meeting was started.
<rick_777> So this meeting is officially closed.
<rick_777> *bang*
<LubomirD_> Good bye!
<Rigoberto__> bye bye

We need a mascot!

2009-01-08T19:02:00.000-08:00

While I'm busy creating Saya's new skin, I think it's time to create a mascot.

Unfortunately, I'm a terrible drawer. So I invite anyone with sufficient drawing skills and a good Otaku background to help us.

As a benevolent dictator (grin), I will define what mascot we'll have.

First of all, it needs to be a girl.
Second, it needs to be an anime girl (since Saya is a japanese name).
Third - she needs to be chibi - we'll follow Pixia's example.

Here are some of the features I'd like the mascot to have:

Name: The mascot's will be "Saya" (the mascot would be the software, following the tradition of the OS-Tans ;-)

Hair: She needs to have short hair - not too short, or we could be plagiarizing an existing anime Saya ;-). A bit longer than Kuchiki Rukia's should suffice. Maybe even longer, but not below the elbows. It needs not to be curly.

Head size: The head needs to have a reasonable size (NO powerpuff girls please).

Here are some examples more or less of what I want (caramelldansen):
http://www.youtube.com/watch?v=UX6e7sO1ss0
http://www.youtube.com/watch?v=jdUT0gWqKnU

The bodies need to be a little smaller. Something like this (pinky's), but keep the caramelldansen face shapes.

Edit (11:14PM): I think I found what I want. School Rumble's alternate ending 1 shows some perfectly-proportioned chibi girls ^_^. Of special attention is Tsukamoto Yakumo at 1:00. The head isn't overly huge, and the body is still well-defined.

Note that I chose the chibi-size so that the mascot can fit in a square space. But a little taller (not taller than the Caramelldansen figures) is perfectly acceptable, and even desired. Try to choose a middle ground if you can.

Eyes: Blue.

Nose: As all bishoujo characters - thin and pretty.

Dress: She could be wearing a kendo outfit (to honor her name), or a movie director outfit. Since Saya is virtual, you could give her a tron-like outfit that would turn into other outfits ;-) A kimono wouldn't be bad, either - but don't make it pink, it doesn't fit the character.

Breast size: Not too large, but not too small, either.

Constitution: Not too athletic, but not too thin, either.

Mouth: Not "X-3" styled mouths. Normal mouths, please.

Attitude: More like a cute smiling girl. Innocent, but intelligent. Not a joker, and definitely NOT a tsundere! (But she's allowed to get upset -.-# once in a while). But she needs to look cute at all times.

Here's an example smile that suits Saya perfectly: Wikipe-Tan (just the smile, not the body)

The rest is up to your imagination (just don't copy existing anime characters, please!).

Also, we need the character designer to be available for future redesigns and all that, so it requires commitment (or maybe we could choose someone else later, but oh well).

Any help will be appreciated. The winner designer will obviously appear in the software's credits!
^_^

It's Official: We're moving to Qt4!

2009-01-05T10:39:00.000-08:00

SAYA-VE OFFICIAL ANNOUNCEMENT
=============================

We're disposing wxWidgets in favor of Qt4.

(End of announcement)

Unofficial comment by Rick.
===========================

I finally made up my mind. After an e-mail conversation with one of the VLC developers, I was told that they submitted quite a few bug reports to wxWidgets, and they were all dismissed. I was also told that wxWidgets was very difficult to work with, and recommended to work with GTK, QT, or anything _else_ (wow, is wxWidgets that bad?).

And my experience confirms it.

Now, I tried the QT4 dialog designer, and once you get the hang of it (you need to use a right-click menu to put all the controls in a layout, there's no standard button for that), it's a bliss. But is it compatible with GPLv3? Version 4.3.4 and up are. Hurray! :)

Sigh, so here goes YET ANOTHER month of changing existing code for arbitrary reasons. I'm lucky I had already adapted a lot of code from wxWidgets ;-).

I'll close this announcement with a famous quote:

"Chance favors the prepared mind".
Louis Pasteur

First donation received, yay! :)

2008-12-25T20:11:00.000-08:00

I'd like to thank Zarxrax from the Doom9 forums for donating our first $20 bucks. This is very significant because it means SOMEONE BELIEVES IN US!

Now, I'd really like to see how I'm going to use that money for the project - and how to activate my Paypal account in the first place, I had left it for later but turns out my debit card expires soon. So I'll have to get a new card # before I start using paypal's facilities.

Anyway - Thank you zarxrax, we really appreciate your generous donation. Merry Christmas, and happy new year!

Merry Christmas!

2008-12-23T20:56:00.001-08:00

Hello everyone! I'm glad you're still here finding out how Saya's been doing. She's been fine, but our little virtual heroine got bored: I kept working on her inner machinery and forgot to give her a nice skin. Right now she's glaring at me, demanding a new makeover ^^;;;

Seriously, I've been revamping the inner workings of Saya:

* A completely new string class.
* A completely new event engine.
* A base cross-platform application class which will make it much easier to port Saya to Qt or whatever toolkit you desire.
* One-to-one wrappers for wxWidget's dialog boxes... well, almost :)
* A restructured source code tree.
* Tons of bug fixes.

The not-so-good news is that, as I had mentioned, I haven't been able to make a video player for Saya yet, but I'm very close! :) Thanks to all these months efforts, I hope to have a video player working in the next month... provided that I actually have free time to work on it. :)

Merry Christmas/Holidays, and a happy new year!

Saya developer's meeting #3 (2008-11-28) chat log

2008-12-07T06:52:00.000-08:00

<Rigoberto> Good evening..
<nekohayo> hello~!
<rick_777> evening
<rick_777> Ok
<rick_777> this meeting is officially open
<Rigoberto> nice that we chat together tonight...
<rick_777> Tonight we will discuss the progress so far and what's
expected for the next month
<Rigoberto> perfect
<rick_777> First, i have to announce that due to my new job, the
expected development time on Saya might become restricted to weekends
<rick_777> and occasionally on weekdays, depending on how heavy the workload is
<rick_777> Second, as you have seen in the mailing list, an IP lawyer
has volunteered to help us in anything legal.
<Rigoberto> ok
<Rigoberto> that's great
<nekohayo> oh, haven't seen that, but I haven't checked mail today
<nekohayo> I wonder why though
<rick_777> Also, Rigo and I have been working on the playback controls.
<Rigoberto> in case it turns out we violate a strange patent no one knows about
<rick_777> yup.
<rick_777> Anyway - I'm still undecided whether to do the fun and
entertaining GUI stuff, or to keep debugging the boring core stuff
<Rigoberto> yup Rich has been very helpful with that thanks again Rich
<rick_777> it might depend on my mood, but I'd really like to have
those nice round buttons to give the fans some eye-candy
<rick_777> that usually keeps them interested
<Rigoberto> what about both?
<rick_777> Good idea :)
<Rigoberto> :)
<rick_777> Anyway, I don't know how much time i'll be able to work.
The playback controls SHOULD become functional by january 2009.
<rick_777> which is unfortunate, as I see the deadline extending more
and more :(
<rick_777> Perhaps this would be a good time to encourage more recruiting ;-)
<nekohayo> rick_777: you mean actually controlling playback, not just
the visual widgets, I hope
<rick_777> nekohayo: Yes. Actually controlling playback
<rick_777> So we go to the Research and Development section
<rick_777> There's a library called libcairo, that is great for
drawing vector graphics. It might become useful in the timeline
<rick_777> and to modify effects
<nekohayo> cairo actually is part of gtk now, afaik.
<Rigoberto> afaik?
<nekohayo> as far as I know
<nekohayo> cairo is pretty much used a lot throughout the gnome desktop
<rick_777> But to keep my promise about the project, we'll need to
embed the cairo library in saya
<rick_777> to avoid dependency hell
<nekohayo> it's what draws pretty vectors, graphs, widgets, whatever
<rick_777> Rigo, how do you feel regarding your wxWidgets skills?
<nekohayo> dependency hell: hmm. is that really such a bad thing?
you're imposing yourself a ton of additional/unnecessary workload, no?
<rick_777> nekohayo: Dependency hell is what made it impossible for me
to install the kdenlive video editor on my machine. It was
frustrating.
<Rigoberto> Rich: improving... what's my next task?
<rick_777> I don't want to step on the same stone.
<nekohayo> you just have to properly document what are the dependencies<
<nekohayo> so that users can get it compiled easily. every last one of them.
<rick_777> nekohayo: The problem isn't knowing what the dependencies
are, but having to download them if your distro doesn't provide them.
<rick_777> having the source code in the same package is a big
productivity boost for users
<nekohayo> well, if you have some really obscure ones, yes you can embed them
<rick_777> ok
<nekohayo> but cairo is mainstream.
<rick_777> Rigo, here's your next homework:
<rick_777> we still need a jog control
<nekohayo> yeah I see your point
<nekohayo> but it's additional workload for you, possibly. anyway.
<Rigoberto> do we?
<rick_777> to avoid getting the "oh no, this is too complicated!
*brain block*" syndrome,
<rick_777> we'll split your task in various subtasks:
<rick_777> 1) Draw the widget using the wxwidgets functions. Just the
little circle with a tiny circle inside it.
<rick_777> 2) Make it more appealing, like perhaps adding a shadow and
background color
<rick_777> 3) Parameterize the drawing depending on a private variable
(like "angle")
<rick_777> 4) Capturing the mousedown event (the name may be
different) to switch on a "dragging mode"
<rick_777> and popping a messagebox saying "dragging enabled"
<rick_777> 4.1) Perhaps with that you could change some color in the
jog control, like making the little tiny circle glow red
<rick_777> like a LED light, that'd be cool
<rick_777> 4.2) When the mouse button is released, make the tiny
circle stop glowing
<nekohayo> is a jog control really that important?
<rick_777> yes, it is.
<rick_777> it's essential for professional video editing
<nekohayo> from my experience, I never needed one/even knew it
existed. it didn't in vegas.
<rick_777> and there are some hardware widgets that implement a jog
<nekohayo> the thing is
<Rigoberto> Rich: I tought we already discussed this point in the list
<rick_777> you connect them to usb, and the video editor (like Canopus Edius)
<rick_777> reacts
<rick_777> um, perhaps i didn't make myself clear.
<Rigoberto> Rich: and if I remember well we agreed not to include it
<nekohayo> isn't the jog control a bit premature?
<rick_777> i apologize for the confusion.
<nekohayo> when there is no rendering/playback/splitting/tracks
<rick_777> We agreed not to include it in the first "release" of the
controls - which we already have in SVN.
<rick_777> nekohayo: I need the jog control to test the playback engine
<nekohayo> ah
<nekohayo> oh, that explains
<rick_777> right now i'll be able to test it using limited features
<Rigoberto> Rich: have you seen avidemux?
<rick_777> like play, fast forward, etc. But jog control is much more precise
<rick_777> Once, I think. let me check.
<rick_777> ah, i see it. It's pretty basic IMHO
<rick_777> everyone, please look at this.
<rick_777> http://images.google.com/images?um=1&hl=en&q=premiere+pro+jog&btnG=Search+Images
<nekohayo> why yes, it's the pro editing keyboard
<rick_777> see the jog control in there?
<nekohayo> here's a reality check, however.
<rick_777> oh?
<nekohayo> most linux users or home editors don't have this
<rick_777> but our plan is not to make a home editor
<rick_777> but to make a professional editor
<nekohayo> all things start up non professional though, unless you
develop behind closed doors for a few years :)
<rick_777> granted, small steps, but the jog is a step we can make,
and besides, making a jog control will become a great training for
Rigo. It's much easier than making the timeline controls
<nekohayo> alright
<rick_777> no pressure there :)
<rick_777> so, may I continue on your homework?
<Rigoberto> Rich: an important milestone is functional controls right?
<rick_777> Exactly!
<rick_777> and according to the development plans,
<rick_777> we need a functional player for version 0.1
<Rigoberto> Rich: Insted of the jog control can I help in implemeting
the control functions instead?
<rick_777> http://sayavideoeditor.sourceforge.net/roadmap.shtml
<rick_777> the wha?
<rick_777> please be specific, what do you mean with "the control functions"
<Rigoberto> making the controls work
<rick_777> OH!
<rick_777> Well...
<rick_777> the problem is that we don't know how functional the
playback engine is
<rick_777> so i need to do it step by step: Implementing one control,
debugging...
<rick_777> and i'm still not sure what part goes where
<rick_777> so i'd rather have you doing something in a more controlled
(pardon the pun) environment
<rick_777> But if you want, you could work on the skeleton for the
control functions
<Rigoberto> I would feel like If contribution was more valuable if I
can help you making the controls work
<Rigoberto> my contribution I mean
<rick_777> actually, i think the jog is much more valuable
<rick_777> perhaps it turns out that the button control functions are
just one-liners
<rick_777> Ok, tell you what. This month we'll work together on that
<rick_777> if i beat you to it and end up doing it myself (because it
could be very easy), no hard feelings.
<Rigoberto> ok
<rick_777> But the jog control is something i really need, and i don't
have the background to do it
<rick_777> but there are tutorials on making your own widgets
<rick_777> so if you do that, your level would really increase
<rick_777> and your abilities would complement mine, and viceversa
<rick_777> besides, the real reason why i'm asking you to do it... is
<rick_777> i need someone to work on the timeline controls
<Rigoberto> what's the diference between the slider we already have
and the jogÂ¡
<rick_777> you know, moving clips around...
<rick_777> the slider should have a "spring effect" that when you drop it,
<rick_777> it goes back to the center and playback is paused.
<rick_777> Let's imagine that you implement a jog control using a
slider (which you won't).
<rick_777> if you drop the control,
<rick_777> the thumb bar goes back to the middle, but playback doesn't
change. Well, the moment you move it, playback is paused and frames
advance as long as you move the control
<rick_777> how should i put it...
<rick_777> jog control is like a car's wheel. You move it right, the
car moves right.
<rick_777> the shutter control (the slider we have) is like the
accelerator pedal
<rick_777> the more you push it, the faster it goes
<rick_777> so that's basically the difference between the jog and the shutter
<Rigoberto> If I understand correctly
<Rigoberto> avidemux does that with a single slider...
<Rigoberto> is there a program that implements your idea to see it clearly
<rick_777> yes, adobe premiere ^_^
<rick_777> let me find a youtube video
<Rigoberto> thanks
<nekohayo> I always thought the jog was a thing of the past that was
made to compensate for VCR/analog devices' lack of precision
<nekohayo> and irrelevant in the world of frames and keyframes
<nekohayo> I guess I'll have to see that video and see how it is
relevant nowadays
<Rigoberto> I like the way avidemux implements it
<Rigoberto> I think its intuitive
<rick_777> okay um....
<rick_777> the problem is, i haven't seen avidemux
<rick_777> but i'll try to install it so i can see how it works
<nekohayo> apt-get it
<nekohayo> :P
<rick_777> not in the repo :P
<nekohayo> wtf, it is
<nekohayo> at least in debian/ubuntu?
<nekohayo> ;)
<rick_777> not in mepis.
<rick_777> ugh.
<rick_777> ok, mind explaining how avidemux works?
<Rigoberto> why don't you install over your winblows installation
<rick_777> OK
<rick_777> booting it up...
<rick_777> downloading...
<rick_777> ah - here's the official adobe premiere explanation for the
jog/shuttle controls
<rick_777> http://livedocs.adobe.com/en_US/PremierePro/3.0/WS810776E4-8A15-4ff5-88B9-E6B712E0BB49.html
<rick_777> and btw, i can see a situation where a professional editor
needs the jog control
<rick_777> the jog control not only works for input video playback, it
will also work to preview the output video
<rick_777> so imagine you're doing a lip-sync editing
<rick_777> and you need precise control over which frame goes where
<rick_777> (in premiere, you would move the jog control and you could
hear the corresponding audio - even if it's tenths of a second
<rick_777> Ok
<rick_777> i'm running avidemux now
<rick_777> i'm loading a .vob file from a dvd
* nekohayo slaps forehead at the overcomplexity of premiere's interface :)
<rick_777> ugh! I need to copy it to the HD
<rick_777> brb
<rick_777> Ok
<rick_777> loaded
<rick_777> so what's the part you want me to do?
<Rigoberto> use the jog disk
<rick_777> what jog disk?
<Rigoberto> beside the video slider
<Rigoberto> over the selection word
<rick_777> well that's not a jog
<rick_777> that's the shuttle
<rick_777> but yes, I see how it works
<rick_777> however it only works when trying to seek a determinate
instant in time
<rick_777> btw, i'd love the shuttle control in Saya to look like that
<rick_777> ;-)
<Rigoberto> yeah it looks nice
<rick_777> do you think you could copy it? ;-)
<Rigoberto> got to talk to the lawyer first
<Rigoberto> :p
<rick_777> lol
<rick_777> anwyay
<rick_777> i still i see no valid reason why NOT to implement the jog control
<rick_777> please enlighten me
<Rigoberto> can you please explain what the jog does
<rick_777> ok
<nekohayo> except development time, nope
<rick_777> imagine...
<rick_777> that the avidemux slider is a toothed like
<rick_777> line
<rick_777> like with gears
<rick_777> but flat
<rick_777> and imagine the jog control is a gear that goes just below it
<rick_777> and connects to it
<rick_777> so if you move the jog clockwise, the timeline slider goes forward
<rick_777> if you move it counterclockwise, the timeline slider (NOT
the shuttle! btw, but the main slider) goes backward
<rick_777> but in a very tiny scale
<rick_777> like one frame per 15 degrees change in the jog
<rick_777> can you see it?
<Rigoberto> so it has large resolutioin
<rick_777> yes
<rick_777> i've needed to use the jog in the past
<Rigoberto> I think I got it but I would like to try it. Do you know
whether there is a trial?
<rick_777> ?
<rick_777> OH
<rick_777> please watch this
<rick_777> http://www.youtube.com/watch?v=VvvxJuY1EGY
<rick_777> it's an Edius Pro promotional
<rick_777> go to 1:34
<rick_777> and you'll see what i want to do
<rick_777> hmmmmmmmm perhaps i'm mistaking the jog with the shuttle
<rick_777> i need to document myself better
<rick_777> either way, see how the mouse is moving clockwise and the
video advances?
<rick_777> pardon me, it's 1:33
<rick_777> actually i think it'd be useful to watch the complete promo
<rick_777> go ahead, i can wait :)
<rick_777> btw, the promo was of course done 100% with Edius
<rick_777> this is where we want to go
<Rigoberto> wow nice piece of software
<rick_777> how does avidemux fare now? ;-)
<rick_777> anyway
<rick_777> did you see how the mouse moved clockwise and
counterclockwise and the video responded?
<Rigoberto> yup
<rick_777> well
<Rigoberto> I still why to try premiere tough
<rick_777> later we might be able to implement such gestures
<rick_777> but i have this idea
<rick_777> have you ever done this in MS Paint?
* nekohayo takes a look
<rick_777> you click on a point, and start moving the mouse clockwise
<rick_777> when in "select" mode
<rick_777> no, wait
<rick_777> better select the "line" tool
<rick_777> click on a point, and then start moving the mouse
<rick_777> clockwise
<rick_777> are you doing it?
<Rigoberto> yup
<rick_777> so, the line follows the mouse pointer
<rick_777> and the axis is constant
<rick_777> now if you draw an imaginary horizontal line....
<rick_777> the two lines would form an angle
<rick_777> the variation of that angle
<rick_777> corresponds to the playback speed when using the jog
(shuttle?) control
<rick_777> the little circle inside the knob
<rick_777> would follow the mouse
<rick_777> the little circle would be the equivalent of the spinning
line you just moved in mspaint
<rick_777> and as it spins clock/counterclockwise, the video advances
forward and backward
<rick_777> as i said, it's a control not so easy to make, but it's necessary
<rick_777> at least for professional users
<Rigoberto> isn't the jog control going to like premiere's?
<Rigoberto> going to look I mean
<rick_777> nope. Premiere's design is counterintuitive
<rick_777> you need to unclick, move the mouse to the left, click,
move it to the right, etc
<rick_777> it's a mess
<rick_777> if you make it circular, you could theoretically advance a
whole blockbuster movie just by moving the mouse in circles
<Rigoberto> I thought you said you wanted ours to look like it
<rick_777> the shuttle control, yes
<rick_777> but i think avidemux's is prettier :)
<Rigoberto> avidemux shuttle is very similar to premiere's jog
<rick_777> yes, but premiere has a shuttle, too!
<Rigoberto> yup just above the jog
<rick_777> it's the tiny slider just above the jog
<rick_777> as you can see, the style varies, but the functionality is
more or less the same
<rick_777> so here are my new requirements:
<rick_777> * Make the slider look like avidemux's shuttle control
<rick_777> or jog, or whatever it's called.
<rick_777> * Make the jog control circular, like a knob with a red
"LED" indicating the direction it's pointing to
<rick_777> * Make the buttons behave just like avidemux (i'll take care of that)
<rick_777> So I guess that sums up what we'll work on this month
<rick_777> k?
<Rigoberto> what about the steps you were saying...
<rick_777> that's all about the jog control
<rick_777> let's review them
<rick_777> 1) Draw the widget using the wxwidgets functions. Just the
little circle with a tiny circle inside it.
<rick_777> 2) Make it more appealing, like perhaps adding a shadow and
background color
<rick_777> 3) Parameterize the drawing depending on a private variable
(like "angle")
<rick_777> ) Capturing the mousedown event (the name may be different)
to switch on a "dragging mode"
<rick_777> and popping a messagebox saying "dragging enabled"
<rick_777> 4.1) Perhaps with that you could change some color in the
jog control, like making the little tiny circle glow red
<rick_777> like a LED light, that'd be cool
<rick_777> 4.2) When the mouse button is released, make the tiny
circle stop glowing, and the jog is released
<rick_777> 4.3) if you can, when the jog button is pressed, make the
mouse pointer invisible
<rick_777> 4.4) when the mouse button is released, also move the mouse
to exactly where the tiny red light was
<rick_777> oh, i guess i forgot step 4.1.5)
<rick_777> move the redlight along with the mouse
<rick_777> just get the coordinates of the mouse pointer and calculate the angle
<rick_777> 4.5) The hard part will be implementing a "step"
measurement to calculate how much the mouse was moving in a certain
time, and trigger an event
<rick_777> we can leave 4.5) for last.
<Rigoberto> ok
<rick_777> I'm sure you can do that with a little wxwidgets research
and practice
<rick_777> i KNOW you can do it.
<rick_777> grasshopper :P
<Rigoberto> :)
<Rigoberto> lol
<rick_777> well , that's all for today.
<rick_777> any other questions?
<Rigoberto> are you going to send the chat log?
<rick_777> yes, but my computer might crash and the log could get lost
<rick_777> better take precautions
<rick_777> any other questions?
<Rigoberto> noup
<rick_777> Ok then :)
<rick_777> This meeting (and log) is officially closed.
<Rigoberto> good evening folks

Saya developers meeting #3 (2008-11-28): Summary of Activities

2008-12-07T06:50:00.000-08:00

This is a brief summary about what has been discussed in the second
Saya-VE developers meeting.

About the team:
* No changes, but I was e-mailed by a pro-open-source IP lawyer in
case we need any assistance.

About the tasks:

* We discussed the need of having a jog control, and what was the
difference between a jog (advancing / going back frame by frame) and a
shuttle (fast forwarding/rewinding at different speeds).
* Jeff gave us an explanation of how controls work in AVIDemux.
* We discussed a bit about how the button 3D effects should behave
* Rigo has been assigned the task of designing a jog control for the
playback controls.
Here's a snippet of the task in question from the chat log:

<rick_777> to avoid getting the "oh no, this is too complicated!
*brain block*" syndrome,
<rick_777> we'll split your task in various subtasks:
<rick_777> 1) Draw the widget using the wxwidgets functions. Just the
little circle with a tiny circle inside it.
<rick_777> 2) Make it more appealing, like perhaps adding a shadow and
background color
<rick_777> 3) Parameterize the drawing depending on a private variable
(like "angle")
<rick_777> 4) Capturing the mousedown event (the name may be
different) to switch on a "dragging mode"
<rick_777> and popping a messagebox saying "dragging enabled"
<rick_777> 4.1) Perhaps with that you could change some color in the
jog control, like making the little tiny circle glow red
<rick_777> like a LED light, that'd be cool
<rick_777> 4.2) When the mouse button is released, make the tiny
circle stop glowing

About the next meeting:

Next meeting is scheduled, unless notified by the members, on Friday
26/Dec/2008. If anyone has any problem with that, we can schedule the
meeting to be held in January next year, or earlier this month.

Third screenshot: Playback controls!

2008-11-23T18:01:00.000-08:00

With the help of Rigo, I've been able to design the playback controls for Saya.Note that the jog widget (a widget that allows you to skip frames by moving the mouse in circles) is missing, we haven't designed it yet.

But basically this is how it'll look.

Settled with a new job... good/bad news.

2008-11-06T18:19:00.000-08:00

The good news is that I got a new job, and that hopefully will have a fine pay.

The bad news, is that my plans to work on Saya fulltime (with your donations) will no longer be realizable. Also, my workload for the next weeks will be somewhat heavy, so the development may slow down. Sorry.

Finally! Out of the bottleneck!

2008-11-03T20:02:00.001-08:00

The hardest part in the design and implementation of a Video Editor is the streaming module. Since 3 months ago I've been breaking my head trying to implement it, but I've stumbled upon various obstacles, namely Audio / Video synchronization, audio buffers, handling of the differences between streaming (encoding) and playback, and dealing with latency issues.

I spent nearly two months rewriting the code to use lock-free data structures (that will take care of latency issues), using 4 separate threads instead of one for playback, and finishing the design of the Audio/Video Input/Output devices.

And I'm glad to announce that the most difficult part has been already coded! This month I'll be rewriting the demo to use the new playback engine, and altho the audio part hasn't been implemented yet, most of the design has been already settled (class AVController is 33% done - but trust me, that 33% was pretty hard!).

Now I've told Rigo to hurry with his implementation of the playback controls so we can start testing and debugging the playback.

I'll be updating the project status in the next few days to reflect the changes in the repository. All rejoice!

Saya-VE developers' meeting, Oct 24 / 08

2008-10-24T19:00:00.000-07:00

Highlights:

* There are some people interested in joining, but couldn't (or forgot to) join the chat.
* I couldn't work on the project since I've been very busy at work - same for Rigo
* All pending work will be revised on the next meeting

The next meeting will be held on Friday, November 28 2008 at 8PM CDT.

Saya development may stall for a couple of weeks...

2008-10-09T22:11:00.000-07:00

I need to make an announcement. I'm going to install a new Linux distro on my box (I just can't stand PCLinuxOS anymore, there's so many things I need to run and they're not available on the repositories - plus, my install got borked somehow and I can't fix it. Primarily because the kernel I installed (2.6.24) isn't available on the PCLinuxOS free repository. Sigh), so polishing the install and leaving it usable might take me a couple of weeks of my free time. More about it in the saya-dev blog.

Also, I'm going to switch to a new job (where I get better pay) in 2 weeks - so these 2 weeks my boss will have me very busy - and very tired.

So this leaves the development of Saya frozen *gulp* for a couple of weeks (let's hope it's not more than that). I'm sorry. If only there were more volunteers to help me out...

Project now accepts donations!

2008-10-03T20:37:00.000-07:00

I finally set up whatever I needed to accept Sourceforge donations. If you want to contribute to this project with your cash, now you can! :D

Donate here:

Saya-VE 2nd dev meeting (26/Sep/2008) Summary

2008-09-27T21:39:00.000-07:00

This is a brief summary about what has been discussed in the second
Saya-VE developers meeting.

About the Team:

* Nopalin wrote me an e-mail explaining some tragic circumstances that made it impossible for him to continue on the project.
* b3rx hasn't reported back after several warnings, so he's been fired automatically. I've removed him from the website page because he never contributed with any code.
* From now on, new members will have to contribute only via patches. On the meeting after a month of activity, we'll decide whether to add them officially to the team or not.
* One person has contacted me via the blog, but I haven't received any e-mail. Let's see what happens.
* So this means the only active developers are me (Rick), Rigobertoc and Javier. And since Javier hasn't reported yet, in the worst case it's only Rigobertoc and me. Recruitment is encouraged.

About the tasks:

* The timeline assigned to Javier Galicia hasn't been completed yet. For some mysterious reason he was unable to attend the meeting, too.
* The threads module has been completed, and Rigo has worked on the Unit test for that. The multithread unit test is a critical task to continue working on the core.
* The data structures for the timeline have been completely rewritten to allow (de)serialization. But deserialization hasn't been worked on.
* The playback visual controls are stalled due to the work on the threads unit test. They've been given a lower priority.

About the website, and Public Relations:

* We have a new blog: http://saya-dev.blogspot.com/ This blog is mainly for unofficial developer documentation and to share stuff we've learned during development - like programming patterns, new algorithms, etc.
* Our project has become an official member for the Open Source Video Editing Foundation. However, no activity or other formalization has been done. Personally (and this is a conjecture), I don't think we'll see any changes in the near future. Let's hope I'm wrong.
* All team members are to e-mail me a public profile so I can post it on the website.
* Sourceforge has changed its web access method. More info can be found at http://sourceforge.net/community/forum/topic.php?id=3518&page&replies=1

About future plans:

* Once the core has been finished, work will focus on gstreamer integration and the playback controls. Once we get the playback, shuttle/jog and scrubbing controls working, the project will be published on freshmeat.net and the first binary will be released on Sourceforge. From that, planning stage will be closed and we will enter "pre-alpha". Things will be smoother from then.

About the next meeting:

Though it hasn't been formalized (nor discussed during the meeting), it is expected for all meetings to take place on the last friday of the month. However, the last friday of October is 31, and it's probable that the various team members will be invited to a party due to the american tradition of Halloween. For that reason, the next meeting will be held on Friday, October 24.

C++ Programmer Wanted

2008-09-20T18:56:00.000-07:00

As usual, we're accepting C++ developers who want to cooperate with the Saya Video Editor project.

The requirements are simple: Being committed and accepting Open Source as a philosophy, having internet at home, have at least 4 hours to develop per week, and of course, a good knowledge and practice of C++. Multithread programming knowledge is a big plus.

Thanks.

Website to be down on Sept. 15th and/or 16th.

2008-09-12T18:03:00.000-07:00

I just received an announcement from Sourceforge informing me about an upcoming migration of the data centers on September 15th and 16h. Expect some website failures during that period.

Thank you for your understanding.

New "Progress Status" page uploaded.

2008-09-09T22:32:00.001-07:00

Here it is. The page that will tell you how far we've been progressing on Saya.

http://sayavideoeditor.sourceforge.net/progress.shtml

It's categorized in sections, and each section is divided in items.
Enjoy.

"Open Source Video Editing Foundation" created!

2008-09-07T12:31:00.000-07:00

A guy from a group dedicated to video editing asked me to join him and get to talk with the authors of other video editing software.

I was reluctant at first - why bother people with other video editors much more advanced than Saya? But He insisted, forwarding his mails to the other people, who joined the conversation. Through a series of e-mails with a bunch of people in the CC: headers, we (I don't even remember who were the other people, this happened too fast) have talked about licensing issues, the (now rejected) idea of forming a spec, having a "core library" common to new video editors (I hope Saya's gets chosen ;-) ), alternative OS's like Haiku (an open source BeOS), Freebsd, stuff about politics, about having talks with Stallman's FSF, and whatnot.

After around 15 e-mail replies, the Google group has been founded. So this thing is getting momentum. We've all agreed that minority platforms (with Linux being the greatest) need a working Open Source Video Editor, and we've informally agreed to share source and tech reports.

Here's the URL.

http://groups.google.com/group/open-source-video-editing-foundation/

There is a website under construction, whose domain is yet to be announced.

Now, I really don't know how this started. It was pretty spontaneous. But there are various Open Source developers in the group, including but not limited to Traverso, Atheme, etc. (maybe it's time to invite the Lumiera guys).

But I guarantee you, this thing is 100% organic grassroot. I was expecting Saya to get attention from f/oss developers, but not THIS soon! In any case, this gives me more incentives to keep working on Saya.

This is getting interesting.... VERY interesting B-)

Unofficial dev blog created!

2008-09-03T20:46:00.001-07:00

As I keep learning new programming techniques and algorihtms, I decided I couldn't just keep them to myself. The world needs to know.

But that doesn't belong to the project, so I decided I would create a new blog:

"Saya Video Editor unofficial dev blog"

It's available at http://saya-dev.blogspot.com/

This way I can post somewhere else the technical stuff I do about Saya (or about any other thing for that matter), and keep this blog for Press, Media Attention and Public Relations, among other synonyms.

Threads module almost completed!

2008-09-02T22:42:00.001-07:00

It was like a rollercoaster ride. At first I thought it would be much easier, like "Ok just do your stuff on the wrappers and built a bit more wrappers around pthreads and windows functions. How hard can it be?"

Oh, boy. As I was examining the wxWidgets code that I modelled the classes after (turns out I ended up copying a lot of it - don't worry, all copyright notices are left intact), I realized that Windows XP doesn't implement condition variables (but Vista does - who'd tell?).

Huh?

Ok, to get you in perspective: There are three basic kinds of thread organization objects: Mutexes, Semaphores, and Conditions.

----------- begin boring explanation -----------
A mutex is an object that can be locked by ONLY one thread. The locking of a mutex is called an "atomic operation", it means that you won't be interrupted by another thread while you're doing your stuff. And as long as the mutex is locked, you're safe.

(There is an equivalent of mutexes for threads of only one process, they're called critical sections. Instead of locking / unlocking, you enter and leave them. But they're practically the same.)

A semaphore is like a racing semaphore: One process is the car that "waits" for the semaphore to turn green, another process is the guy in charge of the semaphore. The interesting thing is that ANY process can set the semaphore to green, and this is where things get interesting.

A "condition" is kinda the opposite of a semaphore: Instead of many guys signaling one car, it's one guy signaling ONE or MANY cars. You can signal all (it's called a broadcast), or only one. But a condition requires a mutex for organization, it's kinda complicated. But it lets you send signals to a thread when you want to tell it to do something (if it's not busy already).
----------- end boring explanation -----------
Anyway, here's the trick: Conditions aren't implemented in windows, so you have to implement them using Semaphores and Mutexes (which are implemented).
But in Posix, you don't have semaphores, so you have to implement them using conditions and mutexes.

So here I was, copying code and organizing it. Then I realized that the most difficult part was the mess of creating a thread. It's not just a single call, you needto set up parameters, implement error handling functions ,etc. etc.

And I realized that the posix implementation of threads in wxWidgets was much cleaner than the windows one. So I reorganized it and spared some windows-specific "optimizations" (they're actually more like shortcuts, for example, in Windows you can start a thread in dormant state, but in posix you need to use a semaphore to make it sleep). So by doing that the code looked much cleaner.

I still need to implement/copy/adapt the code for killing a thread, and the code to delete all threads on program shutdown. It's easier now that I've implemented/copied/adapted nearly everything.

When I do my first thread experiment, it'll be quite fun. I spent many nights this week trying to finish this.

The bad news, is that as things look, it's probable we won't have a workable video editor by the end of this year (I began in May, and it's September already? Aw crap). It might take another 6 months or more. But at least I know that I'm much more advanced than I was when I started the project.

But let me tell you. When I get the core finished, things will start to get REALLY interesting. I'll keep you updated.

Saya-VE 1st dev meeting (29/Aug/2008) Summary

2008-08-29T22:30:00.000-07:00

Saya-VE 1st developer meeting (29/Aug/2008) Summary of activities.

CHANGES IN THE TEAM:

* Developers who were silently kicked out (suprise! This wasn't
mentioned in the meeting) due to lack of activity and reporting :
Nopalin, Wireshark. Note to Nopalin: You earned points by developing
part of the UI, you have a lot of chances of being accepted again.
Please message me.

* Developers who left: C.J. Barker.

* Developers who joined: Rigoberto C., Javier Galicia

OFFICIAL STATEMENTS:

* Official communications channel for the devs are this group (
http://groups.google.com/group/saya-dev/ )
and gmail chat (aka GTalk, Jabber). For this, all members are required
to get a GMail account and enable their chat in their gmail page.

* The project HQ is located at developer.berlios.de, project's name:
"saya". Here we'll deal with bugs, features, tasks, and the SVN
repository is located there.

* Sourceforge will be used ONLY for the website ( http://sayavideoeditor.sourceforge.net/
) and for releasing binaries / docs.

(oops, forgot to say in the meeting: Devs must get accounts both at
Berlios and Sourceforge)

* Meetings like this one will take place every last Friday of the
month, at 8PM CDT (that's -0600 with daylight savings). The calendar
can be seen at
http://www.google.com/calendar/embed?src=sbij7s3h23o0bhrrt4kmeppisk%4...

* Members will be given write-access to the calendar as they prove
their worth.

* New members must prove their worth by submitting one or two patches
before being given SVN access.

* If a dev won't be available for some time (i.e. vacations), he MUST
post it on this group (there's a specific thread for it).

* A "status with progress bars" page will be added to the website.

* Links with research info will be given to me so I can post them on
the website, under the "research" page.

TASKS GIVEN:

* Jeff is the Vegas expert. Ask him anything about UI design. He'll
also design the progress report with colored bars, which I'll post on
the website as soon as it's given to me.

* Bertrand will work on the CODEC module (GStreamer)

* I (rick) will work on the CORE and RENDERER module. The effects /
rendering part is still pending. If anyone wants to give me a hand
with the thread classes implementation, he's welcome.

* Javier Galicia will work on the Timeline. If anyone knows wxWidgets,
give him a hand.

* Rigoberto C. Will work on the playback controls for the preview
window.

NEXT MEETING WILL TAKE PLACE ON:

Date: September 26, same hour (8PM CDT, that is -0600 GDT).

Server: irc.freenode.net (make sure you register your nickname by /msg
NickServ register ).

Channel: #saya-dev

See the calendar for details.

Note: Remember, this meeting will be devs-ONLY. Foreigners will be kicked out and thrown to the dogs :P

First Devs Meeting a huge success!

2008-08-29T19:55:00.001-07:00

Finally I got to get all the team members online. Unfortunately, some devs did not attend and didn't even report themselves. They'll be removed from the project ipso-facto (sorry, gave enough warnings and this isn't a treehouse club).

Another bad news: CJ Barker had to leave the project, his schedule became very tight all of a sudden, and this will be a long-term thing. We'll miss you.

About the meeting:

We talked about ourselves (brief intro), project expectations, official communication channels and how to organize ourselves. I also set up tasks to do. Expect a "Progress bar" to appear in the webpage soon. The meeting log will appear on our private google group.

I'll keep you updated.

Vacations, and a member is back! Kinda

2008-08-16T06:39:00.001-07:00

Hello everyone! Posting from the beautiful lake landscape of Guadalajara. The air's clean in here! :P

I got an unexpected message from one of the more "quiet" members of the team. Due to circumstances above his control, he completely could not login for almost 2 months!

(I'm telling you, this project is cursed! Hard drives crashing, people getting fired and/or having car accidents, is this some kind of conspiracy?)

But everything's going smooth. That other dev is back, and I just found a new programmer from Mexico (thanks OHLOH.NET) very eager to join the team!

So, we might be late on the schedule, but this project is not turning back!

I'll keep in touch.

Taking a one-week vacation this friday.

2008-08-12T06:42:00.000-07:00

This Friday I'll go visit an old internet friend. I'll also intall Linux on his PC ;-)
So I'll be out for a week, and go back this August 25.

*sigh* 4 months and the project has been very slow in progressing :(

Anyway - If you don't hear from me the next month it means a bus hit me or a plane crashed on me or something. Please pray for my safe return and everything :)

When I return, we'll arrange a devs-only meeting on irc. Stay tuned.

Playback framework, high resolution timers.

2008-08-12T06:11:00.000-07:00

I've advanced in the playback framework - the core of our editor. I've designed the AVController class, and I'm in the playback part - the part where you move data from the input to the output and keep the video and audio in sync.

For that I had to program a high-resolution (millisecond precision) function. Basing myself on the SDL's API, I build the syGetTicks() function - it gives you the number of milliseconds that have passed since the program was started. Unfortunately the stupid Windows API didn't have a Unix time-compatible function, so I had to break my head trying to make it work.

The Windows GetSystemTimeAsFiletime returns a 64-bit integer (well, 2 32-bit integers actually) that gives you the number of 100-nanosecond units (Whiskey Tango Foxtrot?!) since 1600. Wha? How am I supposed to convert that?

Well, easy. You just divide it by 10,000,000. And how to do that with 32 bit math?

Easy. Let's use some algebra.

(A * 2^32 + B ) / C = (B/C) + (A*2^32 / C )

The low part of the division is taken care of. And the second, is just as simple:

(A * 2^32) / 10^7 = A * (2^32/10^7) = A * 429.4967296

What do you think? We only have to multiply the high part by a floating point number and we'll get our result. However... we don't want to use floating point math in a high-resolution timing routine. So Instead, we'll do this:

A * 429.4967296 = (A*429) + (A*0.496) + (A*0.0007296)

Luckily, these numbers have fractional equivalents.

A * 429.4967296 = (A*429) + ((A*62)/125) + ((A*57)/78125).

Ta-da! So the final result is:

result = (low / 10000000) + ((hi*57)/78125) + ((hi*62)/125) + (hi* 429);

And we have the WINNT 32-bit equivalent for obtaining the number of seconds since... something.

If at startup we obtain an initial counter, for subsequent calls we only need to substract that number and we'll obtain the number of seconds that have ellapsed since we turned on our PC.

To obtain the milliseconds for the ticks, it was easier. Windows has a GetTickCount() function, but we can't use it since it based itself on the number of milliseconds since midnight. So we just obtain the modulo 1000 and stay with the milliseconds part.

Here are the final functions. The sy prefix is for "saya". Note that the Windows part hasn't been tested yet :P
If you want the final version, please check the Saya-VE source code (SVN) at
http://developer.berlios.de/projects/saya/


/**************************************************************
 * Cross-platform High resolution timer functions.
 * Copyright: Ricardo Garcia
 * Website:   http://sayavideoeditor.sourceforge.net/
 * License:   WxWindows License
 **************************************************************/
unsigned long syGetTime();

unsigned long sySecondsAtInit = syGetTime();

unsigned long syGetTime() {
    unsigned long result;
    #ifdef __WIN32__
        FILETIME ft;
        GetSystemTimeAsFiletime(&ft);
        unsigned long low = ft.dwLowDateTime;
        /* We spare the highest 16 bits;
           we don't want to overflow the calculation. */
        unsigned long hi  = ft.dwHighDateTime & 0x0ffff;
        result = (low / 10000000) + 
                 ((hi*57)/78125) + 
                 ((hi*62)/125) + 
                 (hi* 429);
    #else
        struct timeval mytime;
        gettimeofday(&mytime, NULL);
        result = (unsigned long)(mytime.tv_sec);
    #endif
    return result;
}

unsigned long syGetTicks() {
    unsigned long result;
    #ifdef __WIN32__
        result = (syGetTime() - sySecondsAtInit) + 
                 (GetTickCount() % 1000);
    #else
        struct timeval mytime;
        gettimeofday(&mytime, NULL);
        result = (unsigned long)(mytime.tv_sec - sySecondsAtInit)*1000;
        result += (((unsigned long)(mytime.tv_usec)) / 1000);
    #endif
    return result;
}

How to implement the renderers? Draft 1.

2008-08-07T21:30:00.000-07:00

Actually this is more like a brainstorm, but bear with me :)

So far, we have been able to make a workable implementation of VideoOutputDevice. It has the following members:


class VideoOutputDevice : public syAborter {
   public:
       VideoOutputDevice(); // Constructor
       bool Init(); // Initialices the output device
       bool IsOk(); // Is the device OK?
       bool IsPlaying(); // Is the device currently being transmitted data?
       void ShutDown(); // Can only be called from the main thread!
       VideoColorFormat GetColorFormat();
       unsigned int GetWidth();
       unsigned int GetHeight();
       bool ChangeSize(unsigned int newwidth,unsigned int newheight);
       // Can only be called from the main thread!

       void LoadVideoData(syBitmap* bitmap);
       virtual bool MustAbort();
       virtual ~VideoOutputDevice(); // Destructor
   protected:
   //    ...
   private:
   //    ...
};

The renderer must invoke VideoOutputDevice::Init on playback start and VideoOutputDevice::Shutdown
on playback end; he same for AudioOutputDevice::Init and AudioOutputDevice::ShutDown.
Additionally, it must call VideoOutputDevice::LoadVideoData regularly (in case of playback) or for every frame
(in case of encoding). Therefore, it requires a way to know the input's framerate. Also it needs to know the
input's audio frequency.

It requires to be multithreaded so that the framerate doesn't depend on the main thread's GUI being blocked
or something.

Let's assume that it's VidProject which tells the renderer what the framerate is.

So we have:

void Renderer::Init(VideoInputDevice* videoin,AudioInputDevice* audioin,
                   VideoOutputDevice* videoout,AudioOutputDevice* audioout);

With this we mean we're gonna need new classes for input: VideoInputDevice and AudioInputDevice.

bool Renderer::SetVideoFramerate(float framerate);

And now, onto the playback functions:

void Renderer::Play(float speed = 1.0,bool muted = false);
void Renderer::Pause();
void Renderer::Stop();
void Renderer::Seek(unsigned long time); // Time in milliseconds to seek to

All that's fine, but what happens when we want to display a still frame? We don't know what video output device we
have - a player or an encoder-, so there must be some way to send a still frame to the video device.

void Renderer::PlayFrame();
// (Note that this should be either a protected function or only be enabled when
the video is paused; otherwise we could desync video and audio)

Now that I think of it, sending still frames is what the Video Playing does. Every N milliseconds, we send a frame to the
output buffer. So there must be separate seeks for video and audio.

void Renderer::SeekVideo(unsigned long time);
void Renderer::SeekAudio(unsigned long time);

And if we're seeking, there must be a way to tell if we're past the clip's duration.

bool Renderer::IsVideoEof();
bool Renderer::IsAudioEof();

And it seems we'll need separate video and audio functions for everything (edit: NOT!)


   void Renderer::PlayVideo(float speed = 1.0);
   void Renderer::PlayAudio(float speed = 1.0);
   void Renderer::PauseVideo();
   void Renderer::PauseAudio();
   void Renderer::StopVideo();
   void Renderer::StopAudio();

But I wonder if having separate stop functions would be good at all because of sync issues. I mean, if we don't
want the audio or video to be shown we just don't decode it. It's matter of seeking, decoding, and sending.
So PlayVideo and Play Audio will just disable video and / or audio, and will only need pause, stop.


   void Renderer::PauseVideo(); SCRAPPED
   void Renderer::PauseAudio(); SCRAPPED
   void Renderer::StopVideo(); SCRAPPED
   void Renderer::StopAudio(); SCRAPPED

I think that with this info we'll be able to design a good rendering / playback framework.
Stay tuned.

syBitmap finished! Now what?

2008-08-06T22:15:00.000-07:00

The dev in charge of the Video playback controls is going to be away this week. So maybe it's time to start designing the Renderer API.

Which functions will it have? How will it tell the codecs to read a file? How to handle video and audio sync? How to handle the threads?

Too many questions, any help appreciated. Thanks.

Saya-VE without SDL, experiment 1

2008-08-06T06:00:00.000-07:00

Finally, my efforts are beginning to show results. I realized that I had committed several mistakes (read-as: bugs) while implementing wxVideoPanel. While fixing them, I also improved the code a little.

Additional bitmap
The most important bug was trying to save time by not creating another buffer. This caused a crash when resizing the panel under certain conditions. By using another buffer for wxVideoPanel, and updating it from wxVideoOutputDevice::Renderdata(), I could finally be sure that the wxVideoOutputDevice's bitmap was not accessed at the wrong time. As a bonus, this meant that while the video is paused, I still keep a copy of the buffer (oops... now that I think of it, when resizing, the bitmap info is actually lost. I'll fix that soon).

syBitmapCopier
I finished implementing the syBitmapCopier class. Most functions are inline, so no stack space will be used when invoking them (well, some variables were required, but those are unavoidable).

syAborter
I also did some clean up. I moved all the thread functions to syBitmap. I replaced the VideoOutputDevice* pointer from syVODBitmap and replaced it with an syAborter* pointer. syAborter is an abstract class that has only one method: bool MustAbort(), which indicates if an expensive operation must be aborted immediately. Then, I made VideoOutputDevice and AudioOutputDevice subclasses of syAborter.

What this means: syBitmap has all the required functions to be thread safe, and integration with ANY VideoOutputDevice class will be a piece of cake.

Classes cleanup
Now that all the syVODBitmap functions were moved to syBitmap, syVODBitmap was no longer necessary, so I deleted it.

And now, ladies and gentlemen... the demo!

The last bug I had made was calling an expensive wxWidgets function inside a for(x)... for(y) loop. No wonder the display was so slow. But now the wxVideoPanel demo is fully functional. And here it is!

The Demo() function (actually, method) of wxVideoPanel, regularly creates a nice colored image or arbitrary dimensions (the ripples change every 5ms approximately) which is later scaled to fit in the panel's dimensions. This way, no matter if your video is 4:3 or 16:9, it won't be distorted.

After being created, the image is sent to wxVideoOutputDevice via the LoadVideoData() method. This method copies the data to its own bitmap, and then, in its RenderData() method, it calls wxVideoPanel::LoadData().

wxVideoPanel::LoadData() locks its own bitmap and pastes the data. wxVideoPanel's bitmap is locked because there are two other functions that access it (each one locks the bitmap as well) : OnResize, and OnPaint.

wxVideoPanel::OnIdle() checks if new data has been loaded, and calls OnPaint() if necessary. OnPaint() uses a wxBufferedDC to repaint the screen.

This way, we have our nicely colored image which changes in realtime without flickering at all. Ta-da!

From SDL to MyOwnVideoImplementation (TM)

2008-08-04T11:52:00.000-07:00

After trying out the SDL video demo, I realized that for a video editor I won't be needing to use sprites, 3D textures or anything like that. It would be esier to write my own Bitmap buffer in memory. So I did, and I ended up creating the wxVideoPanel and wxVideoOutputDevice classes.

Unfortunately, the screen refreshing routines were awful. No, worse. They were hideous. I had to calculate everything manually, handle the pixel color spaces, etc. There had to be a better way. And hence, I came up with syBitmap: A cross-platform implementation of an in-memory bitmap. It has a virtual MustAbort() function which you can adapt for multi-threading purposes.
Currently I've been able to replicate the SDL example, but I was too busy and tired so I couldn't upload the screenshot.

As an added bonus, I created the derived class syVODBitmap (VOD stands for Video Output Device), which also has Lock() and Unlock() functions (also for multi-threading).

The best part is that I could add a PasteFrom function in syBitmap, so that the copying also scales and centers the source bitmap so it will fit the destination. Unfortunately, the implementation isn't as fast as I wanted because it uses floating point math. But I plan to replace it with fixed point math so copying won't become an overhead.

Still, the implementation is both ugly and slow. So I ended up creating another class (which I have yet to commit to SVN): syBitmapCopier. The idea behind it is this: Instead of having to calculate a pointer by multiplying y*width and then adding x, and then obtaining the color format of the pixels, we just init the class with the source and destination bitmaps, and these members are calculated only once.

I have designed functions to copy pixels and increment only the source pointer, only the destination pointer, or both. I've also designed functions to copy entire rows and advance either / both of the pointers by one full row. This way we'll have no worries about having to recalculate parameters for each pixel or passing them through the stack. Who knows, maybe I can inline all of these functions to get a super-efficient bitmap copier.

As soon as I finish the syBitmapCopier implementation, I'll make a multi-threaded demo to see how many frames per second I can get. And then I'll start making the Video playback UI, which is already overdue.

Saya-VE with SDL, experiment 1

2008-07-27T21:50:00.001-07:00

I pasted and adapted some code from the wx-sdl project (see link in previous entry) into Saya. I created a new class called SDLPanel (original, heh?), and used it instead of a common wxPanel.

So far, here's how the painting works:

1) Check if the panel has an active SDL_Surface object

// can't draw if the screen doesn't exist yet
if (!m_Screen) {
return;
}

2) Lock the SDL_Surface. This thing is thread-safe!

// lock the surface if necessary
if (SDL_MUSTLOCK(m_Screen)) {
if (SDL_LockSurface(m_Screen) > 0) {
    return;
}
}

3) Create an in-memory bitmap (a wxImage) based on a SDL_Surface's memory. Once you got the image, you create a wxBitmap based on the wxImage. I really hope this isn't double-memory copying and that the wxImage uses the actual memory.

// create a bitmap from our pixel data
wxBitmap bmp(wxImage(m_Screen->w, m_Screen->;h,
           static_cast{unsigned char *}(m_Screen->pixels), true));

(NOTE: I use braces instead of less than and greater than because the code
is altered by blogger's html tidying routines)

4) Now that we created the bitmap, we can safely unlock the SDL_Surface.

   // unlock the screen
if (SDL_MUSTLOCK(m_Screen)) {
   SDL_UnlockSurface(m_Screen);
}

5) The painting is done with standard techniques:

   // paint the screen
wxBufferedPaintDC dc(this, bmp);

For our purposes, the SDL_Surface can be a software bitmap without 3D acceleration, residing in the computer's RAM. In other words, it's a plain and simple memory buffer.

And I had to load a full-fledged multimedia library for a simple in-memory bitmap!?!? C'mon!! But hey, it works :D

Here's the screenshot (note: the little color lines actually vary in real-time, it's cool).

Sweet, isn't it? Too bad I'll have to change the code back to keep working on this.

But from this we can incorporate the VideoOutputDevice class so we can actually display clips and images. This will be a major breakthrough in our editor.

First experiences with SDL

2008-07-23T20:45:00.000-07:00

It's time for Saya to get a video viewer, but we havn't been able to do anything yet. Enter wx-sdl.

wx-sdl is a tutorial/sample of using SDL with wxWidgets. It's a single file, and it has everything you need to draw your own video on a screen surface. The best thing is that it's LGPL licensed, so it won't be a problem including it in Saya! :D (two thumbs up!)

There's a class called SDLPanel, but it's customized for the sample there, so we need to adapt it to make it generic. But the integration with wxWidgets is amazingly simple. I hope I will have it included in Saya by the next week.

In related news, I had thought that including the SDL source code would be piece of cake. I guess I was wrong - it's a huge library, so I guess it will go along with wxWidgets in that I need to link to it instead of embedding it.

Fortunately, all linux distros already include it or have RPMs for it, so installation won't be a problem. And you don't need to compile it in Windows either, it already comes with a handy-dandy DLL :)

That means I'll need to post another edition for the developers' guide... sigh.

New developer joined!

2008-07-23T15:00:00.001-07:00

Everyone, give a warm welcome to Robert Molnar a.k.a. wireshark. He's an experienced wxWidgets programmer (i think the first assignment i'll give him is to start designing the timeline :) ), and has helped a lot of other programmers at least in the wxForum. He's certainly got what it takes to develop a full-fledged Video Editor such as Saya.

Welcome aboard!

Congratulations! It's a boy!

2008-07-21T23:10:00.001-07:00

It's time to celebrate. Our effort has given birth to our first offspring. What the - offspring? Actually, I'm talking about Nopalin's first code commit ^_^ Well, I had to help a little, but the new project dialog is progressing. Congratulations!

Oh - by coincidence, it turned out to be my birthday. So it's a double celebration then :)
In other news, I finally figured out how to implement the video display and keep the current framework design. I'll try to do the first tests this week. Wish me luck!

Expensive decision; Improved New Project Dialog

2008-07-16T19:36:00.000-07:00

Two good news: I asked for permission at my job to work one hour less (without pay, of course) than I normally do - starting today - , and my boss accepted. This decision costed me a lot of money that I won't earn anymore, but it's certainly worth it - and the result is that today I could finally work a lot of time in Saya.

As proof, and that's the second good news, here's the improved New Project Dialog, based on the GNOME Human Interface Guidelines (not all were followed, but it's an improvement) :

Before:

After:

As you can see, the new dialog is thinner and less cluttered. Also, I removed the redundant "Aspect Ratio" combo box. Pixel Aspect is more than enough for the video settings. If later we decide to scale the project to a certain screen format, I'll add a button to calculate the pixel aspect ratio.

(Note: The cyan background for the text controls is a personal desktop setting, just pretend there was white in there).

Developers' guide for Linux uploaded!

2008-07-15T21:40:00.000-07:00

Oops. Make that "GNU/Linux". Anyway, thanks to CJ Barker for the draft. The files are available on Sourceforge.

Job + personal problems + stress = ???

2008-07-15T13:07:00.000-07:00

Sigh. It's been more than a month since the project was founded, and it feels like I haven't been able to acomplish anything.

These last 3 weeks, I've had too much work at the job, plus I've had personal problems at home. These have left me exhausted and without time or energy to work on the project when I get home.

Without realizing that, I opened the project and saw that very little code has been written. So I asked myself: what the heck have I / we been doing this month? I felt so frustrated and impotent. It's even worse when I can't get a quick e-mail reply from one of the team members. What will happen if I we keep having the same problems / interruptions and we can't get anything done in the next 3 months?

But then I realized that I've written the developers' guide (a task not trivial at all), an explanation of the project design, and the other developers have been organizing themselves.

Yes, it's true, not much code has been written, but it won't be like this forever. CJ Barker has mailed me telling me that he'll have time this weekend to work on the resources panel. Nopalin is putting a lot of effort in learning wxWidgets, and more research has been done.

Tonight I'll start rewriting / publishing the Linux developers' guide (thanks to CJ for writing the first draft).

Anyway I've also noticed a lack of organization. I'm thinking that perhaps we should have monthly meetings on the irc channel - that's why it was created in the first place.

So, please bear with us a little more. We're not perfect, but we're not slackers either. We're very few members and we're doing our best to make this work.

Car accident; Human Interface Guidelines

2008-07-14T09:41:00.000-07:00

The bad news: One of our team members had a car accident and he had to be taken to the hospital :( Fortunately, he's fine now, but he'll need a bit of rest. Let's wish him a fast recovery.

The good news: After a brief discussion (but not argument) with some of the team members, I've decided to follow the Gnome Human Interface Guidelines. This will make our dialogs VERY user friendly and not cluttered at all :)

New dev, engine warming up :)

2008-07-10T00:01:00.000-07:00

Two good news: One, we got a new dev, Rigo, which is an old friend from school.
Two, everyone's back from their away status. Nopalin has been studying hard and is learning fast. I hope that the New Project dialog will be completed soon.

Also, the "Welcome" dialog has been fixed from some bugs and some bitmaps have been added to the big buttons.

It seems that the real development has been started! :)

Stay tuned.

Framework design is up!

2008-07-05T21:43:00.000-07:00

The Saya-VE framework design has been uploaded to the website (it's licensed as GNU FDL) . Also, the developers' guide section now points to the downloadable dev guide.

Whew! Developers' Guide finished.

2008-06-30T23:01:00.000-07:00

After two long weeks of overnight work, I finally finished the Developers' Guide for Windows. It's available on the Sourceforge page in the downloads section.

Let's hope the Linux devs don't require a developer guide :P

Having second thoughts about gstreamer...

2008-06-23T21:05:00.000-07:00

Recently I've been writing on a mailing list about the ffmpeg project, and on why we need an alternative. A little bit of browsing led me to take a second look at Gstreamer. Therefore, my previous post entitled "On Diva, gstreamer and tiers gone wrong" seems to be inaccurate.

In theory, GStreamer is everything a video editor has dreamed of... but I couldn't get hold of the developer guide (it's on development. How ironic). However, I have this hunch, telling me that I won't be able to access frames and audio samples directly, and instead I'll have to rely on plugins such as gnonlin.

Let's hope not. I mailed one of the Pitivi authors for guidance. Let's see what we find out. Cross your fingers.

How to make a portable Codeblocks project

2008-06-21T19:10:00.001-07:00

Perhaps this will help other developers who want to write cross-platform applications with Code::Blocks. After breaking my head for various hours, I finally found out how to do it. Code::Blocks 8.02 includes a script engine which can make certain compiler options apply only to Windows environments.

Example: In your project settings:
Under "Compiler settings", "other options":

[[if (PLATFORM == PLATFORM_MSW) print(_T("-mthreads -D__GNUWIN32__ -D__WXMSW__"));;]]
`wx-config --cflags`

(Note: The double ;; at the end is a workaround a scripting bug)
As you can see, the one-line script is pretty much like C. the _T must have been incorporated for wxWidgets compatibility. In any case, Notice the compilation string: -mthreads, -D__GNUWIN32__ and -D__WXMSW__. The -D is a compiler define. I tried to add scripting to the #defines, but that didn't work, so I had to add them on the compiler command line.

The wx-config part is for Linux. I've found that experimentally, having this option in the project doesn't affect compilation under Windows.

The same can be done with the linker. Under Linker settings, other linker options:


[[if (PLATFORM == PLATFORM_MSW) print(_T("-mthreads -lwxmsw28u -lintl.dll"));;]]
`wx-config --libs`

Here I tell the linker to link two windows-only libraries: libwxmsw28u.a, and libintl.dll.a (libintl is used for internationalization). For posix environments (OS X or GNU/Linux), the backticked expressions are more than enough, but you could do the same with "if (PLATFORM != PLATFORM_MSW).

Under search directories, I add both the Windows and posix directories.

Compiler search dirs:


$(#wx.include)
$(#wx)/contrib/include
$(#wx)/lib/gcc_dll/mswu

Linker search dirs:


$(#wx)/lib/gcc_dll

Resource Compiler search dirs:


$(#wx.include)
$(#wx)/lib/gcc_dll/mswu

With this simple settings, you won't require having two different projects, one for GNU/Linux or Mac OS, and another for Windows.

This will help making cross-platform projects quite easy.

Windows = Pandora's box!

2008-06-20T23:50:00.001-07:00

Today was a hectic day. Not only I had to run Windows to get my tax declaration working (the app doesn't run on GNU/Linux), but I had to use Windows to set up Code::Blocks as well.

Once upon a time... the second most active developer, Nopalin, had problems with his harddrive and ended up installing Windows. The pandora box had just been opened on me. I had now to download MINGW, compile wxWidgets, download an additional libintl from gnuwin32 (it doesn't come by default with mingw), install subversion, and guess what.

As I had expected, I had compiling problems with the project, which was configured for a posix environment. I had to modify the global settings for Code::Blocks under Windows (something you must NOT do, that's what the project settings are for!) until I found out how to make the project build properties cross-platform (this is a capability not implemented in Code::Blocks yet, maybe they have scripting capabilities now, but I don't know of them).

And then wxDateTime method FormatISODate() outputs garbage on Windows. When that was fixed, I noticed some other problems: The buttons in the welcome dialog were invisible, and the new project dialog has the wrong size! :(

How did all this happen? Well, I'll be able to find out as soon as I make the project cross-platform. In the worst cases, I'll have to use the same tactic the C::B devs did: Use parallel project files. Ugh. Let's hope I don't have to resort to that. Sigh...

Why "Lone Ranger" programming will never work.

2008-06-20T08:55:00.000-07:00

Recently I got an e-mail from someone interested in video editors, pointing me to a novel video editor in the works.

The problem: The thing's written in [obscure programming language which is neither Python nor C++]. Oh, you didn't know there was a programming language called [obscure], right? See, THAT's the problem.

I'll quote some text from the other programmer (I'll rephrase all paragraphs to protect the innocent from Google searches):

Basically I'm sick tired of having a non-working video editor and a lot of novel ideas that other editors lack. And I've rewritten it so many times that I've got to get this off my head.
All those four years I haven't been programming because of school. But this year might allow me to start working on [editor] again.

Later, I read:

Lately I’ve realized that programming takes too much time from my life.... I almost made it work... I’m not a programmer. Programming in [obscure programming language] is my hobby, not my profession. I don’t get any money from it. It's a problem when programming takes about 80% of my time and I don't have time left for normal activities ... my projects will be put on hiatus. Feel free to ask me for rights to commit to the subversion of [editor]. You can take over the project for now. I hope I’ll get back to programming [editor] with a little more peace of mind after next year [written on December 2007].

And this, ladies and gentlemen, is why the Lone Ranger approach to Open Source programming WILL NEVER WORK. Do you have the slightest idea why so many Sourceforge projects are abandoned? It's like the Open Source Project cemetery. Well here's the reason: Those projects had NO programming teams.

I absolutely refuse to work on a hobby project if I have to do it myself, with tools I have to write myself because there are non-existing tools for an esoteric programming language (let alone a binding to [ famous multimedia library ] ).

Perhaps you'll understand now why I chose to use C++ and wxWidgets. There are at least 10 C++ programmers for every [obscure programming language] programmer. And there are at least 10 Windows users for every Linux user. If I'm going to have a programming team and a live project, I better use things where I can recruit most volunteers.

After all, a Non-Linear Video Editor is not something you can make in your garage.

New mailing list + one developer less = still good!

2008-06-19T14:21:00.000-07:00

Today I received a letter from the MIT guy (the one who never answered my mails) asking me to remove him from the project. However, I have the suspicion that either his request to get in or his request to get out was forged (this means someone got access to his account), because they were in very different tones. Too bad - because we can't allow someone with such a bad security get in the project. Reliability: 50% -> zero.

In other news, I opened a private mailing list for the developers so we can organize ourselves better. I'm also working on the developers guide so anyone can install the software required to compile and run Saya.

Then we'll start working, and hopefully in a couple (ok, maybe 4) weeks we will release version 0.1, code name: Aikuchi. That will mark the end of the planning phase and we will officially become "pre-alpha". Keep in touch! :)

Class diagram for AVClip

2008-06-18T20:40:00.001-07:00

So how are we managing the effects?

An AVClip has a vector of effects.
An Effect consists of a map (string, FXParamTimelines). The string denotes the parameter's name.
An FXParamTimeline is a map of (integer, string parameter), where the integer represents a point in time.

(Notice that there are no bezier curves in this diagram. But there will be, don't worry about that).

Time is measured in milliseconds, but I'm going to replace the integer with a 64-bit integer so I can represent nanoseconds (this is necessary to be able to move audio clips around with one-sample precision in time).

One thing that I forgot to mention is that none of the data structures I present here, have pointers (pointers are EVIL!). This is so we can duplicate the instances of effects and clips easily. Since the indirection is handled through array (or vector / map) indexes, we won't have segmentation faults due to a badly dereferenced pointer. This also makes serializing and deserializing the data a piece of cake.

When copying a series of clips to the clipboard, I will replace the clip id's with new ones. Simpler than a Jedi mind trick. "These aren't the id#s you're looking for." *Waves hand* No pointer mangling, no headaches.

So this is the reason why I'm trying to focus on the User Interface first. Because it's the task which takes most of the time. And since I already got rid of the wxWidgets-specific classes in this framework, we can choose whatever UI library we want. But I'm sticking with wxWidgets for the user interface.

Class diagram for VidProject

2008-06-18T18:59:00.000-07:00

Who'd guess there was a tool to convert C++ code into UML diagrams? It's called Umbrello.
Here's a simplified UML Class diagram for Vidproject and associated classes:

The Video Project has a list of the currently used Resources (video and audio clips - i.e. files ). Additionally, it contains an AVTimeline which contains various sequences. Each sequence contains various audio and video tracks. And each track contains... surprise, a clip. The clip has an index indicating which resource it operates on. And of course, a list of effects and a transition.

Notice that a video clipboard is nothing but a sequence. Convenient, isn't it?

As you can see from this diagram, the memory consumption for these classes is minimal, since they're nothing but sparse data structures.

Now, I don't really know how Cinelerra or other video editors work. But one thing's certain: It's much easier to model the classes after the structure of the data we're going to modify. And this data is a timeline.

I already have implemented saving undo/redos for these classes, and you can impose a memory limit on how many undos/redos you can store in memory. So there goes the high memory requirement. Poof! :)

I'll upload this diagram to the webpage when I can.

Bugs fixed, we're back in the business!

2008-06-17T23:28:00.000-07:00

The annoying configuration bugs that had plagued me for the last couple of days were finally solved (note to self: remember to wrap the functions va_start and va_end around vsnprintf the next time - how embarrassing ^^; Oh well... I guess these things happen when you're programming while undersleeping at 4AM in the morning). Another hint, is that whenever you're dealing with char* strings, DO NOT store them in the stack! If anything goes wrong, you won't be able to debug because the stack will be messed up. Use varname = new vartype[num].

AAaaaaaaanyway...

I added a nifty debug log to our wxApp object, so we can finally know what's happening behind the scenes. This is excellent for hard-to-debug cases. And now, back to business, there are tons of things to do:

Fix the updating of recent project menus. I currently use a flag, it's better to use a counter to see whenever it's been updated.
Implement the audio/video presets in the new project menu
Implement project creation and saving with XML.
Keep working on the framework to do some video streaming (Jonathan's beaten me to that already, I must keep up in the race!)
Update the website, write the class diagrams, etc.

And now, to get a good deserved rest. G'night!

A new dev comes, an old dev leaves... possibly.

2008-06-17T00:10:00.000-07:00

Everybody welcome CJ-Bark, our newest team member.
Also, one of the developers might... "have a long vacation" since I haven't got a single e-mail from him since he joined.

Keep in touch.

Conversion finished! Now onto bug fixing.

2008-06-16T23:39:00.001-07:00

The good: The backend conversion from wxWidgets to generic functions has been completed! :)

The bad: It's buggy. Now the Open dialog doesn't show the recently opened projects. :-/

The ugly: I'll have to debug! :(

Saying goodbye to wxWidgets (partially)

2008-06-15T01:42:00.000-07:00

Turns out there were a lot more wxWidgets functions used in the backend than I expected.

After a few hours of rewriting code, I managed to almost replace all. However, I'm left with a few stubs (I only committed a zipfile with the changes, I don't want to break the build in SVN). Here's a list of the new functions and changes:

static std::string ioCommon::GetPathname(std::string fullpath); // UNFINISHED
static std::string ioCommon::GetFilename(std::string fullpath); // UNFINISHED
static bool ioCommon::FileExists(std::string filename);
static bool ioCommon::FileExists(const char* filename);
class BufferedFile; // UNFINISHED
class TempFile; // UNFINISHED
const std::string syString::Format(const char* format, ... );
const std::string syString::FormatBig(unsigned long bufsize, const char* format, ... );
enum sayaEventType;
enum sayaYesNoCancel;
class sayaEvtHandler; // This will be used for handling the events coming from the backend.
class sayaConfig; // A wxConfig wrapper, it's an abstract class.
class sayaConfigProvider; // abstract class. UNFINISHED; needs an implementation (wrapping) done in wxWidgets.
const wxString std2wx(const std::string& str);
const wxString std2wx(const char* str);
ALL wxString references in ProjectManager were replaced by std::string
Since wxWidgets uses the _() macro, all literal strings will have to be surrounded by gettext().

For now it seems that we have to implement the stubs I created. But after that, the code architecture will be much more robust and cleaner, because the ProjectManager and related classes now only depend on the STL and some basic libraries like stdio. This means that if someone wants to make a frontend for the project in QT, it will be much easier for him to do it now.

Now I have to go to sleep. I'm dead.

Saying goodbye to wxString

2008-06-14T16:29:00.000-07:00

I just had realized something. If I want to make Saya UI-Toolkit independent (except the UI frontend), it means I'll have to add another bunch of wrappers. But it's worth it.

So I'll start replacing the wxString references everywhere except in Main.h and Main.cpp for std::string . This will also help me get rid of the _T() and macros. For internationalization, I guess I'll redefine the _() macro to some internal function, used only by the backend.

It also means I'll make an intermediate class to pass the messages (like presenting dialogs). I think I'm going to like this.

SVN problems and headaches

2008-06-13T22:06:00.000-07:00

We're having technical problems using the SVN server at berlios. It seems I'll have to change the access method from svn+ssh to https. But I'm afraid I can't do it right now, I have this horrible headache. I'll keep you updated.

Update: Fixed. To solve the SVN access Issue, I only had to replace the svn+ssh login method by https. I had to do some directory copying, but it was easy.

Critical Sections and Mutexes

2008-06-12T19:10:00.000-07:00

Ah, the joy of multithreading. I really miss the wxMutex and wxMutexLocker classes of wxWidgets, which unfortunately, I can't use for the wrappers (because they're wrappers and therefore they need to be as lightweight as possible. Linking to the wxWidgets library isn't exactly what I want).

The first decision I took was to use the SFML Mutexes class. Unfortunately, I stumbled upon the problem: If I include this for the wrapper, what will happen when one of the plugins actually uses the library? Would I get some duplicate definition? Should I copy the code and rename it?

Forget it. Enter google. I found two great resources for using Mutexes: computing.llnl.gov (which included a copy of the pthreads manpage) and wikipedia. Lucky me, the wikipedia tutorial included a cross-platform version of implementing critical sections! And it's GFDL, alright!

Now let's see if I can find a good example of a cross-platform thread-safe sleep() function.

Update: Done. Now I can go back to work on thread-safety for the audio/video wrappers.

OpenVIP: The ace under my sleeve

2008-06-11T22:23:00.000-07:00

There's been more than one person who doubts that I can do a video editor alone. The complexities of writing a good Video Editor backend are too great for a "newbie" to try on his own.

And they're right. But I'm not writing a backend. I already have one. See?
http://openvip.sourceforge.net/

From the webpage:

OpenVIP is a free video-processing tool for Linux and Windows. It consists of two parts:

OpenVIP core, which can be used for processing multimedia files from command line, or as a C++ library linked to other applications.
OpenVIP editor, which provides a user-friendly GUI to the core and is based on the timeline concept - you place multimedia files on the timeline, apply filters, transitions, ...

These are the main features of OpenVIP:

Supports AVI, DV, MPEG, MOV, MP3, WMA, and WMV formats (via the FFmpeg libraries) as well as sequences of bitmap files (via the ImageMagick library)
A lot of nice plugins including colour transformations, geometric distortions, basic sound processing and transitions between two clips
A simple interface for developing your own plugins in C++

OpenVIP was designed by a college group as their graduation project. Unfortunately, they couldn't continue their project. That's where I come in. Or should I say we, since there's already a developing team for Saya.

All we're doing is designing a professional user interface around the OpenVIP Video Editor framework. Because the framework is done in C++, designing the frontend is much simpler than starting a video editor from scratch.

The only problem is that OpenVIP is released as GPLv2, while Saya is GPLv3. I've asked the main developer to release the project as GPLv3 so I can add the framework right away. Perhaps his mail got lost, I guess I'll ask again. (Edit: I just got a mail from Antonin Slavik, the OpenVIP project leader. OpenVIP is now GPLv3 or later with linking permission! Road's clear!)

Still... we can't commit the same mistake other developers have by tying themselves to one framework and later realizing it doesn't do what they need. This is why we're making a whole "interface layer" in Saya, so the video processing and playback frameworks can be inserted as plugins. Some things will need to be implemented on our own (or outright stolen from mature frameworks), like threads, mutexes. There's a 90% chance that I'll borrow SFML's system module to deal with this part.

The rest will be a lot easier to handle.

Status report. June 10, 2008

2008-06-10T22:50:00.000-07:00

What has been done:

* Organizing the team, getting team members. Some members haven't been able to be contacted live - but we got an Adobe Premiere video editing expert / advisor (edit: And tentatively another advisor, who happens to be a Sony Vegas expert and User Interface Nazi ;-) ) , a beta tester, 3 developers and 1 possible developer more (if I manage to get him online). Additionally, an old friend from school who's a college graduate is offering to join the project - but not before he passes a wxWidgets exam I assigned him :)

* Researching on various fields. Nopalin has been able to do his first wxWidgets programs, and is ready to work on the UI. b3rx is in the process of documenting the OpenVIP classes and some classes that have already been designed. I've been researching the use of SFML and have corrected various misunderstandings in the wrapper classes.

* The pluggable multimedia framework has been started. Abstract class AudioOutputDevice has been completed. Abstract class VideoOutputDevice has been started (as a stub). Actual implementations using classes derived from these, remain to be written.

What remains to be done:

- Completing the New Project Dialog and creating new projects.
- Creating an A/V streaming class for rendering video and audio on-the-fly.
- Creating a plain vanilla video player using the said classes.

If everything goes well, this will be done within the next 4 weeks.

To SDL or to SFML? That is the question

2008-06-10T09:16:00.001-07:00

I recently found a multimedia library called SFML (Simple and Fast multimedia library). According to the webpage, " Instead of being one big API, SFML rather contains a lot of small packages, that can be chosen and combined according to the intended usage. You can use only the base package to get input and windowing, as well as the full graphics package with sprites and post-effects." Additionally, it's written in C++ and seems to be very flexible.

That sounds just like what we're looking for. However, there is a problem, and it's that the project is (relatively) too young compared to SDL. How stable and reliable it is?

I'm sure that choosing a multimedia library is a problem many multimedia programmers face. They have to base their entire code on choosing one or another library. This is why I decided to design abstract classes as wrappers, so we don't have to face that decision. I hope that with SMFL we can have a working multimedia player soon.

We got a team! And a website!

2008-06-09T06:56:00.000-07:00

This week has been hectic and I haven't been able to sleep very well - but it was worth it. Saya-VE has a website, a Sourceforge page, 3 more developers and a beta tester.

We'll keep you posted.

on DIVA, GStreamer and Tiers gone wrong

2008-06-05T16:26:00.000-07:00

I just found this awesome post from Michael Dominic explaining his problems with the GStreamer framework.

"GStreamer solves a lot of problems on the GNOME desktop but it doesn’t solve the problem of video editing.

Gst is a playback framework, and for video editing you need editing framework. The later is not, as it’s commonly believed, just a superset of the former. The MLT framework is an interesting example of the “video editing” architecture."

A later comment from a reader explains further:

"I would also join the voices in suggesting that you reconsider your decision with GStreamer. In the last six months GStreamer has become more and more suitable for applications such as Diva, and Gnonlin is a particularly useful component here."

And here I was thinking that I could use GStreamer as a basis for Saya. I think I can explain the concepts with a small diagram:

PiTiVi or some other editor
Gnonlin
Gstreamer
Video Hardware

This is, gnonlin is a PLUGIN which goes with GStreamer (if it's not, someone correct me please!). The problem is that this plugin is a video-editing component built upon a low-level playback framework. This is:

Editor UI
Editing stuff
Playback
OS / Hardware

and that's a no-no. It's got the logic ALL WRONG!

Instead, what I want is something like this (the higher, the more user interaction) :

GUI
^
| (commands, events)
v
High-level Editor framework (track / timeline /
effect stuff handling)
^
| (playback info, commands, events)
v
Renderer (effects / mixing)
| |
| v
| Low level
| Playback Framework
| (i.e. SDL)
| |
| v
v Video Hardware
Decoder
|
|
v
Files

In other words, The decoder/files make the MODEL. The Playback/VideoHardware are the PRESENTATION (the GUI is another separate layer of presentation, so they're tied - in a way), and the Editor framework is the CONTROLLER.

Ladies and gentlemen, this is nothing but Model-View-Controller 101.

Any questions?

---------
Update (June 23, 2008) : It seems I was mistaken in my assumptions regarding GStreamer and PiTiVi. However, the MVC pattern is still a rule I'm going to follow. Stay tuned.

There can be only one... (not)

2008-06-04T13:38:00.000-07:00

At least I'm not alone. Another guy had more or less the same idea that I had, and around the same time. Clearly this is an indicator that video editing in Linux *DOES* have a problem. His project blog is at http://myvideoeditor.blogspot.com/

Alas, it seems he chose another path (he's going to use GStreamer and Python). Why, oh, why??? I really don't know if he'll succeed, but I asked him to join forces. Sigh, if only we had managed to get in touch earlier. Jonathan claims that C++ is a monster hard to debug. Well, not if you use the latest GDB and Code::Blocks. Programming C++ with Code::Blocks is a breeze ;-)

Luke er Jonathan... JOIN ME, and we shall rule the galaxy together! Well, more or less :P

"New Project" dialog

2008-05-31T19:23:00.000-07:00

After researching for a couple of days and designing for a whole day, I finally got a decent and pretty "new project" dialog. So far it's been one of the most complicated things I've done for the project yet, because I needed to get info about all the known editors, and standard video formats (thank you, wikipedia!)

Also, Premiere shows more settings, while Edius Pro's dialog is more compact and "friendly", but in my opinion it was oversimplified. So I had to choose a compromise.

One of the things that annoyed me about Premiere was that you had to scroll and read the settings as you kept choosing, and if you didn't like one, you were presented with an overcomplicated screen of settings.

I managed to include all the important settings in one page, and they'll change as I switch between presets. If i choose "custom", the settings will become read-write (they should be read-only and greyed out), so I can just type everything right away.

I also managed to make them pretty and not bloated. This took me a while, but putting the video settings at the left and the audio settings at the right, just did the trick.

I would also like to thank the wxFormBuilder developers for making such a great tool.

Second screenshot!

2008-05-22T23:38:00.000-07:00

This time I've added some panels with wxAUI. The little light blue area is supposed to be a file tree for the resources directories.

The bottom part is going to be the timeline, and is fixed to the main window.

The good part is that the panels can be undocked and turned into separate windows.

A friend gave me an idea based on the first screenshot: The timeline should be on the top. And it makes sense, this way I can add the toolbar directly to the window, and there will be no problems with them being too far from the timeline.

Soon you'll be able to see actual resources loaded in the resource window. Then I'll start working on the timeline.

Resolution independence conundrum

2008-05-21T13:11:00.001-07:00

Hi everyone. I was thinking about a feature in Edius Pro that I want to implement in my editor: Resolution independency... but I stumbled on a problem.

Let's say we have a sequence whose frames are made of 4 zoomed-out clips: A, B, C and D, as in a multicam display.
AB
CD

To process this, normally one would apply a "reduction" transformation to A, B, C and D, followed by a translation transformation. Then that would be rendered in the resulting clip, which we'll call E.

Now imagine E has similar sequences called F, G and H.

EF
GH

The result will be called I, which would have this structure:

I { E { ABCD } F { JKLM} G {NOPQ} H {RSTU} }

Now what happens when we zoom inside I? The result depends on the processing order of the transformations. If we put this in layers (tracks), we'll have something similar to this:

I
E    F    G    H
ABCD JKLM NOPQ RSTU

If transformations (filters) are applied bottom-up, we would gain speed in processing, but resolution is lost, since the resulting images have a constant resolution. Zooming in would result in mosaic artifacts.

Instead, if transformations are applied top-down, processing complexity would be greater, but resolution would be preserved to the last pixel. This would allow us to zoom from I to E, to A and beyond.

The conundrum is...

Is there an algorithm for doing this? :(

Doxygen: Better safe than sorry

2008-05-19T23:08:00.000-07:00

I noticed that some of the TinyXML code I took from the Code::Blocks project has doxygen-formatted documentation. Frankly, I didn't know how that worked, until I read these pages:

http://www.stack.nl/~dimitri/doxygen/docblocks.html
http://www.stack.nl/~dimitri/doxygen/commands.html

I better start soon. If I leave it for later, I'll end up with a mess of code and no documentation.

Frame independency, more API changes

2008-05-19T18:37:00.000-07:00

I was rewatching the Edius Pro ads, and I marvelled at the concept of fps and resolution-independent processing. I remember the first time that I tried to import a clip in Premiere. It complained about the fps of the video being different than the current project's.

I had forgotten about this until I rewatched this promo. Wait a sec, fps-independent? Resolution independent? Cool!

Then I thought about the difficulty of such implementation. For now we can see timelines having HH:MM:SS:FF:MMM (hours, minutes, seconds, frames, and milliseconds - or was that milliframes? I don't think so.).

Currently in the timeline structures I have the tracks sorting the clips by frame. It's an integer number. But then I thought - hey, a millisecond is also an integer. So what's the limit for our videos? Let's see...

Assumming we have a limit of 2^31, we have 2147483648 milliseconds available for a production. If we divide it by 1000, we got 2147483.648 seconds. Let's round it to 2147483 seconds. If we divide it by 3600, we got ourselves an amount of 596.52 hours, which would be equivalent to 24 straight days. More than enough, I think :).

And due to the fact that we're using std::maps and not mere vectors, we don't have to worry about memory requirements: They're exactly the same.

Another thing I realized was that storing clips in a pool for later usage, is simply a waste of time and resources. Each time we copy/paste, we're gonna generate new clips. Cutting doesn't solve the problem because we could undo and yet retain the clip in the clipboard, so we'd need to process that. So, that would leave us with only more complexity and absolutely no storage gain.

If we get rid of the clips-in-storage-pool, we can store the clips (clip as in data-structure, not the movie, duh) directly in the timeline. Since it's an STL map, we don't have to worry about pointers either!

So these are the next changes to be done in the infrastructure.

QsKKing's Vegas 7 tutorial, mencoder, transitions...

2008-05-18T23:34:00.000-07:00

My bittorrent download of QsKKing's tutorial for Sony Vegas 7.0 just finished downloading. The bad news is that it was encoded with one of the latest Micr.... (UGH! I can't mention that word! It burns!) codecs, which I had to get from the internet. I couldn't watch it with VLC player (I could with mplayer, but I hate that software, it's quite unfriendly). So I tried recoding it with FFMPEG, to no avail. I then tried with mencoder, which worked.

A good tip for using mencoder is installing the rpm for KMediaGrab, which is a graphical frontend for mencoder. The KMediaGrab version I got is 0.3, and it works as charm.

Anyway, since this is a Video Editing blog, I just wanted to recommend kmediagrab to you guys, in case you need to convert from one format to another.

Now, onto QsKKing's tutorial. Let me tell you man, this rocks. Thanks for encoding it in high resolution so I could read the menus and options clearly so I can replicate them. One thing I specially liked is the overlapping clips and automatic transitions, which I didn't know in Premiere (well, with one or two months of barely using it, what can I say? Perhaps the option was hidden in there somewhere, and I really wouldn't remember anything if it wasn't for the Edicion de Video book).

Now I realize that my approach to making transitions was wrong. Transitions should happen automatically ALL the time, and all I would need to do is get the transition parameters for the clip, when ENDING. Why only the ending transition? Because transitions require by default TWO clips. Only one clip is needed for the information. And with the overlapping = transition, I don't need to define transition links for a clip. The transition parameters will just have to be embedded in the clip. Don't want a transition? Remove the overlap. Voila! :)

Again, thank you, QsKKing. I really owe you one. Just a little favor. Next time use something more universal like AVI/XVID ;-)

Edius Pro rocks!

2008-05-18T20:49:00.000-07:00

Now *THIS* is something that I was talking about. I just downloaded a few tutorials and ads for Canopus' Edius Pro from youtube, and they have these cool features:

* The toolbox above the timeline has these little icons that when you hover over them, you get a tooltip with the Brief description (as in the Menu) AND the accelerator shortcut key!
* The resources window lets you scan a directory and they recreate a directory tree with all the resources of each directory in another pane - with icons, of course.
* According to the ad, you can jog by just moving the mouse in a circular motion. I ignore if this is by just clicking in the window or use a knob-like jog dial.

But this is the kind of features that I kept asking for in overhyped editors like Jahshaka. What effort did these guys need to make a friggin' tooltip appear in front of a tool? Or a small context menu that explained to me what each button did? These things are CHILD'S PLAY to do, at least in wxWidgets. And why do programmers leave these things FOR THE END, if they're the EASIEST things to do?

So this is why I started my project. Instead of starting with the backend image processing stuff, I'll start with the front end and add all these basic features that make Video Editing "just work". If later some guy makes a super-duper Video Editor technology, he'll just have to use Saya's frontend, and no problem. Of course, provided that I have managed to write an extensible interface for making your own effect dialogs - which I intend to do. But I disgress.

Now that I've seen how Edius works, I'm going to use Edius' resources Window as model, instead of Premiere's (and possibly I'll start searching for more Edius screencasts ;-) ). If only open source programmers learned not to reinvent the wheel...

Ah, user-friendliness.

Clipboard problems, part deux

2008-05-18T07:02:00.000-07:00

I think I got it figured out. First of all, let's simplify audio/video clipboard pasting. Since tracks can only be either video or audio, each track needs to have a video-type flag telling which kind of track it is. This way it won't accept clips of different kinds. Ordering of tracks will be handled by the UI, so it doesn't matter if audio and video tracks are mixed, audio track will always appear at the bottom and video tracks at the top. However, for pasting purposes, having only the track's type is sufficient.

Declaring one clipboard type for single clips is annoying. Instead, let's add a function that detects whether a sequence has only a single clip. Or even better, just add a friggin' flag. This is OOP, we can derive a clipboard from a sequence.

With that, we can turn the clipboard into a full-fledged sequence and our copy/paste problems will be gone.

When pasting multiple tracks, we just have to use an identifier for the track's z-position, and act accordingly. If the topmost track is pasted below, we can either deny the paste or (at the user's choice in the options dialog), create new tracks to do the paste.

Having the z-position stored in the clipboard tracks allows for moving clips at will without any difficulties, even if sequence tracks have been added or deleted.

Now the problem is nested tracks. How to handle them? Well, we have to analyse the global effect of having tracks nested. Let's say we have tracks A,B,C and D.

A
B
C
D

Now let's add some container tracks E and F, which will contain A and B, and C and D respectively. Let's call A and B "leaf" tracks, and E and F "branch" tracks.

E - A
 - B
F - C
   D

In the end, it doesn't matter how nested they are, they keep the same order. If D is rendered and C on top of it, combined, they form a single track but the effect is exactly the same. Meaning that when the tree is expanded to its full extent, there will be no problem. We just have to take care of pasting into the "leaf" tracks and everything will be as usual.

This means container tracks can't have clips. They're only made for visualization and handling purposes. So that would leave us with having to use a "trackbase" class to define branch and leaf tracks. Tracks would then need a function to calculate their Z position based on their parent tracks' position. This can be expressed with the following functions:

unsigned int zpos() {
 return get_parent_zpos() + local_zpos;
}

unsigned int get_parent_zpos() {
 unsigned int result;
 if(!m_ParentTrack) {
    result = 0;
 } else {
    result = m_ParentTrack->zpos();
 }
 return result;
}

Finally, to paste and move tracks, we only have to make sure that all tracks are fully expanded - otherwise, pasting (or moving) clips/selections will be forbidden.

The paste operation then becomes simple, it's just iterating over the tracks and pasting the contents. Note that audio tracks will also be copied/cut/pasted if they're linked to the video tracks. To do so, we need to add a "track" member to the clip, to know which track they belong to. For that we also need a "position" member, to tell us the local position in the track. If the track's position slot doesn't equal to the clips', the clips' position is invalidated and the track is rescanned to find the clip. If the clip isn't found, it's then searched in all the tracks, and updated accordingly. If still the cip isn't found, it means we have an orphan clip and it will be deleted.

Our timeline structure is getting more defined :)

Sony Vegas: You're next.

2008-05-17T22:00:00.000-07:00

I'd like to thank QSK King for uploading his Sony Vegas 7 tutorial to youtube and various torrent trackers.

I'm downloading that tutorial right now, and I'll see if I really can obtain some juicy information which I can transform into code.

QSK King: You're da King! ;-)

Canopus Edius

2008-05-17T20:29:00.001-07:00

I just found a relatively new Nonlinear Editor for Windows. It's called Canopus Edius Pro.

The screenshots look awesome. I think I'm going to take some interface options from them. Hmmm what's this? They got a Render Menu in the menubar. It's worth taking a look...

Apparently there is no such thing as "nested tracks" in Edius... perhaps the idea of nesting tracks isn't really as good as I thought, it only complicates things more. The only advantage that I see in nesting tracks is making more space available for visualizing clips, and applying effects to various tracks at the same time. But if we have sequences that can be nested as clips, there's no need for nesting tracks. I can just select a bunch of clips, right click them and "combine into a single sequence". This would create a new sequence, add it to the resources and create a clip from it.
(Update: Yes, there is a need for nested tracks. Do operation on various tracks at the same time, mute or hide all the tracks at the same time. But in the end, they're nothing more than a list of tracks clumped together. What's the difficulty? It'll be just for grouping.)

Going back to Edius... what's this? They got bezier curves for editing effects? O.o
Wow. When the Lumiera guys mentioned they wanted to add bezier curves for effects editing, they weren't kidding, there IS such a feature. And that color correction screen is really wonderful (I'd link or copy it but I don't want to get in copyright problems, the link is there for you to link).

Clipboard problems

2008-05-17T19:00:00.000-07:00

A problem I stumbled upon is... how to handle copying and pasting? Copying a single clip is no problem. Copying a piece of a track isn't problem either, I only have to store the track beginning offset and copy the clips' data.

However, how to handle nested tracks? Should I group tracks by video and audio?

I remember when I used Premiere a while ago, I could add audio and video tracks. What I don't remember is... would I add only audio tracks or video tracks? But it seems You could add audio-only tracks, i.e. for adding background music to a video. Therefore, tracks shouldn't be grouped by video and audio.

How to handle then copying and pasting?

Here's an idea. Do a copy of the current timeline in case of multitrack clipboard, and paste into exactly the same tracks (no up/down possible). I'm thinking that this would have the same effect than dragging and dropping a selection. However, how to move multitrack clips up/down? I think I'd need to add a command for shifting up / down clips.

When I figure out how to solve this, I'll be able to implement cut/copy/paste effectively.

First screenshot!

2008-05-17T15:07:00.000-07:00

This is the first screenshot of Saya. So far it only consists of the menus, but the File Menu is 95% implemented (items like Capture / Batch Capture aren't updated yet because they depend on variables that I still haven't added to the application.

As you can see, the menu structure is nearly identical to Adobe Premiere, altho I've modified some things a little. The shortcut keys (the underlined letters) aren't identical since the book I purchased ("Edición de Video" by RedUsers - it's a latin-american book) doesn't include screenshots THAT detailed. But they do have a chapter on the menus, woo hoo! This is why I could copy the Premiere menus so easily. Some of the nested menus weren't in the same chapter, but I could easily compile them from the context menus on the various chapters.

Currently I've implemented opening files (altho opening a file doesn't do anything but loading a string in memory), saving, reopening, clearing the recent projects. Importing videos and/or images isn't implemented yet.

The good news is that I got the project and timeline memory structure (even the undo history) completely designed now (which I'll explain in a later post). The fun part will be designing the timeline widgets, whee!

After I finish the code for enabling/disabling items on all menus, I'll start with the File Importing module. Then you'll get to see some dialogs done :)

Saya is now licensed under the GPLv3!

2008-05-16T21:58:00.000-07:00

I updated all the development files to state they're licensed under the GPL version 3 or later. Additionally, I uploaded a copy of the GPLv3 in a file called LICENSE.txt
All hail the FSF!

Codename funtime :)

2008-05-15T18:58:00.000-07:00

Projects love codenames, right? Funny Furry, Breezy Badger, Joyful Jiraffe, and whatnot. So I say, let's have codenames for Saya, too! :) Since saya means "scabbard" in japanese, let's use some sword names!

From wikipedia's List of famous fictional swords, I picked a few names of famous ficticious swords, and added a few real ones.

I'll reserve the superpowerful magical swords for major releases, like ClaiohmSolais, Ascalon, Balmung or Excalibur. The earliest milestones will have wimpy names, like "baselard", "arrow", or "cutlass" :P

Anyway, here's the current compilation.

Arondight / Anduril / Anguirel / Ascalon

Baselard / Barrowblade / Buster / Balmung

Cutlass / Claymore / Callandor / Caladbolg / Curtana / ClaiomhSolais

Dussac / Defender / Dragonslicer / Durandal

Excalibur / Executioner / Einlanzer / Energy

Falchion / Fragarach / Flamedancer / Fenrir

Gladius / Guthwine / Glamdring / Gram

Hauteclere / Herugrim / Heartsbane / Hrunting

Ida / Itak / Irving / Iceflame / Izayoi

Jian / Joyeuse / Jisoutou / Justice

Katana / Kris / Khanda / Kunitsuna / Kusanagi

Longclaw / Lilarcor / LionsTooth / Lhang

Messer / Masamune / Murasame

Narsil / Natsume / Nodachi / Naegling / Nothung

Oathkeeper / Odyssey / Osafune / Orcrist

Pathfinder / Pantera / Plesioth / Prakk

QuelSerrar / Qinggang

Rapier / Ragnarok / Ryusei /

Sikanda / Shamshir / Sting / SenbonSakura / Stormbringer

Tizona / Tetsusaiga / Tachi / Tulwar

UltimaSchneider

VioletFear / Valmanway / Vorpal

Wakizashi / Wallace / Wyrmslayer

Xiphos

Yatagan / Yasutsuna

Zweihander / Zabimaru / Zarroc / Zanbato / Zangetsu (I love this one! ;-) )

How to implement undo/redo functionality

2008-05-14T23:56:00.000-07:00

After searching the web, I finally managed to implement an undo/redo class for Saya. I never imagined that with simple use-cases, I'd be able to straighten my thoughts and get rid of all the complications in thinking up a good algorithm.

So here goes.


Use case: Undo History
======================

1. Beginning
============

curstate ----> 0. EOF


2. Do "something"
=================
BEFORE:

   curstate ----> 0. EOF

AFTER:
                  0. RECENTLY SAVED STATE, transition: "something"
   curstate ----> 1. EOF

ACTIONS:
   If current state is EOF, save state in current slot with the transition to be done;
   increment state pointer.


3. Do "somethingElse"
=====================

BEFORE:

                  0. SAVED STATE, transition: "something"
   curstate ----> 1. EOF

AFTER:

                  0. SAVED STATE, transition: "something"
                  1. RECENTLY SAVED STATE, transition: "somethingelse"
   curstate ----> 2. EOF

ACTIONS:
   If current state is EOF, save state in current slot with the transition to be done;
   increment state pointer.


3. Undo
=======

BEFORE:

                  0. SAVED STATE, transition: "something"
                  1. SAVED STATE, transition: "somethingelse"
   curstate ----> 2. EOF

AFTER:

                  0. SAVED STATE, transition: "something"
   curstate ----> 1. SAVED STATE, transition: "somethingelse"
                  2. RECENTLY SAVED STATE, transition: ""

ACTIONS:
   If current state is EOF, Save state in current slot with an empty transition name;
   decrement state pointer and restore state.


4. Redo
=======

BEFORE:

                  0. SAVED STATE, transition: "something"
   curstate ----> 1. SAVED STATE, transition: "somethingelse"
                  2. SAVED STATE, transition: ""

AFTER:
                  0. SAVED STATE, transition: "something"
                  1. SAVED STATE, transition: "somethingelse"
   curstate ----> 2. SAVED STATE, transition: ""

ACTIONS:
   If next state not EOF, Increment state pointer and restore state.

5. Undo
=======

BEFORE:

                  0. SAVED STATE, transition: "something"
                  1. SAVED STATE, transition: "somethingelse"
   curstate ----> 2. SAVED STATE, transition: ""

AFTER:
                  0. SAVED STATE, transition: "something"
   curstate ----> 1. SAVED STATE, transition: "somethingelse"
                  2. SAVED STATE, transition: ""

ACTIONS:
   If current state not EOF, just decrement state pointer and restore state.

6. Do aNewThing
===============

BEFORE:

                  0. SAVED STATE, transition: "something"
   curstate ----> 1. SAVED STATE, transition: "somethingelse"
                  2. SAVED STATE, transition: ""

INTERMEDIATE STEP:

                  0. SAVED STATE, transition: "something"
   curstate ----> 1. SAVED STATE, transition: "somethingelse"
                  2. EOF

AFTER:

                  0. SAVED STATE, transition: "something"
                  1. SAVED STATE, transition: "anewthing" (transition was renamed)
   curstate ----> 2. EOF

ACTIONS:

   If next state not EOF, delete all states until next state is EOF.
   Rename current slot's transition; increment the pointer.

--------- Alternative case: -----------

BEFORE:
                  0. SAVED STATE, transition: "something"
                  1. SAVED STATE, transition: "somethingelse"
   curstate ----> 2. SAVED STATE, transition: ""

AFTER:

                  0. SAVED STATE, transition: "something"
                  1. SAVED STATE, transition: "somethingelse"
                  2. SAVED STATE, transition: "aNewthing"
   curstate ----> 3. EOF

ACTIONS:
   If next state is EOF, rename current slot's transition; increment the pointer.

Pseudocode:
============

Function Do() {
   1. while(!IsNextEof()) delete the topmost state.
   2. if(IsEof()) Save state in current slot with the transition to be done;
   else
      just rename current slot's transition.
   3. ++curpos;
}

function Undo() {
   1. if(IsEof()) Save state in current slot with an empty transition name;
   2. if(curpos) { curpos--; restore state; }
}

function Redo() {
   1. if(!IsNextEof()) { curpos++; restore state; }
}

function IsNextEof() {
   return (curpos+1 >= undostack.size(); )
   // Note that we use a double-ended queue instead of just a stack to be able to delete
   // old states in case memory usage exceeds a given limit.
}

function IsEof() {
   return (curpos >= undostack.size());
}

It's screencast time!

2008-05-13T23:39:00.000-07:00

Seek, and ye will find, says an old proverb. Well, I've found it.

Creative Cow has an entire collection of Adobe Premiere Pro Screencasts. Very well explained, with close-ups, so that makes perfect use cases explained by professionals. Until now I didn't know a tool such as multi-camera editing even existed.

I would like to download Adobe's official tutorials, too to study them and implement the features in Saya, but that would feel dirty, like buying Texas from Santa Anna with his own gold, or something. So I'll keep Creative Cow's screencasts for the use cases.

On the UI and the infrastructure

2008-05-13T20:46:00.000-07:00

One question I've been asked more than once, is why I decided to start the design with the UI.

According to good programming practices, first you need to work on a good design, and then start the implementation.

Well, for now, the project will just focus on being an editor front-end. This means that the video processing stuff will be held back for later.

Since my short-term goal is to have a workable user interface replicating the menus and dialogs of commercial video applications, I can assume that the design for these applications was well-done, and the only thing I need to do for now is to implement the dialogs and menus. When I stumble upon a wall (i.e. a dialog requiring information that I don't have yet), then I'll develop the infrastructure as needed, with the condition that I'll make it extensible to avoid getting stuck with a specific data structure.

So, if you were worried because I don't have (yet) a working UML design, rest assured I'm also working on a good design for the infrastructure.

So far, we have a class I'll call ProjectManager, which will handle project saving / loading, exporting, asking the user questions, etc.

ProjectManager will have a member m_project which will be of the class VidProject. VidProject is a container, and will have one or more of the following:

* Project Properties (title, framerate, preferred export format, codecs used, etc.)
* A double-ended queue (std::deque) of undo/redo states
* An std::vector of Sequences (timelines), which will have a vector of tracks each.
* A vector of Clips, and a vector of Clip indexes (to reuse deleted clip slots)
* A vector of Resources, which are the actual video clips (to be more precise, the info on how to retrieve such clips, i.e. filename, starting / ending frame, etc.)

Each clip will have (at least) the following information:

* id# for the origin (the resource used).
* Starting origin frame (in case of video, in case of audio we'll have samples - note that origin frames could also have starting / ending frames for the actual file used)
* Ending origin frame
* Loop count ( negative for infinite loops; 0 for no loops)
* enum: video before the first frame will be black? transparent? a copy of the first frame?)
* enum: same for the last frame
* Changeable duration in timeline frames (for speed up /slowdown of scenes)
* A vector of effects (the effect id will be an id# in case of built-in effects, or a string, in case of external plugins. To keep things simple, the effect parameters will be stored on an std::map.
* If it's an audio clip, the id# for the corresponding clip of video, in case they're sinchronized.
* the id# for the starting transition (use 0 for none)
* the id# for the ending transition (use 0 for none)
* In case of audio tracks, the channel # (0 for first channel, 1 for second, etc - this will be defined later as the implementation gets done). In case of stereo and multiple tracks, this will be a vector where the destination tracks will point to the source tracks. For remixing tracks, mixing to mono, etc, there will be also stackable audio effects.

Tracks will be stored in a tree structure (children will be stored in a vector of track id#'s) where the root of the tree will be the final rendering. Again, we won't use pointers but indexes. To prevent recursion, each track will also have a level indicator.

Each track will contain a map from frame# => clip id#. We can use the maps to construct a per-sequence set (a set is a map of booleans) of transition frames. With these transition frames we can construct in real-time a list of states which tell us which frame contains which clip. With this info we can now render clips in the timeline.

Note that I won't plan to use pointers AT ALL. By using standard cointainers and local indexes, I can serialize the sequences into easily-storable strings for undo / redo states, and it'll be also easier to serialize the whole project into an XML string.

Why I decided to create the Saya Video Editor

2008-05-13T18:30:00.000-07:00

Good morning! This is the first post in my Saya Video Editor Blog.

So, what is Saya? Saya is a project that aims to become a professional cross-platform Non Linear Video Editor. By cross-platform I mean that it'll work in Windows, Linux and even MacOS.

Perhaps you're here wondering "Why reinvent the wheel?" "Aren't you doing more software fragmentation?" and "Do you really think you can do this on your own?"

Well, I'll answer these questions one by one.

Q: Why reinvent the wheel?

A: I'm *NOT* reinventing the wheel. It's the *OTHER* guys who are reinventing the wheel. And yet, nobody has done it in a successful, cross-platform way.

Allow me to explain further. Here are some features that the other Linux video editors are missing:

1. Cross-platform compatibility (and by that I mean Windows!)

As you can see, the Linux video editors are made for Linux, and Linux ONLY. While it's good to support a Free (as in Freedom) Operating System, it's not that good to leave the Windows people in the darkness. What would happen if OpenOffice.org was Linux only? What would happen if Firefox only ran on FreeBSD.

Installing a lot of extra software in Windows to be able to run the binary you downloaded is *NOT* acceptable.

Do you really think the average Windows user will agree to install and mess around with a virtual machine (and Linux inside it, which already includes a lot of headaches), or cygwin JUST to run (or try to run) a Video Editor?

None of the Video Editors I tested (all of the free ones except zs4, which I was unable to find) were able to run in Microsoft Windows (TM).

How I'll succeed: With the wxWidgets library.
This is why I chose to use the wxWidgets library, which makes portability SIMPLE. And I'm following a successful editor (Audacity) which was done in C++ and wxWidgets.

2. Ease of installation in Windows (and that means absolutely NO python, and much less wxPython!)

The last time I tried to run a wxPython application I downloaded the wrong version (how is an end-user supposed to know?) and the program crashed. Wanna know how I felt?

Another complaint I have is that a lot of video editors depend on an interpreted language. Hello, I want a NATIVE application. If you want to use Python, please use a Python COMPILER. Thank you. I don't want to download an app and realizing it doesn't run after I decided to run it from the command line to see the Python error messages. Ugh.

How I'll succeed: By writing the program 100% in C++.
No interpreted language nightmares, no Python, no Ruby, No .NET / MONO, just plain and simple C++. With the use of STL, it's nearly a child's play to easily-write good programs. And with wxWidgets, make that double. Windows users can easily download an already-compiled binary (.exe - or even an installer), and the program will run. Was that so hard?

An advantage of writing the program in C++ and make it install / compile easily in Windows will be a greater project exposure. I can choose to limit myself to the still-small Linux community, or I can embrace (without extending and extinguishing ;-) ) a much wider audience: Windows users. As a matter of fact, I was a Windows user myself, and I was frustrated at the lack of Free (and uncrippled) Video Editors for Windows. I would have joined a project if there was one - and trust me, I've been waiting for one for more than five years. I trust that there are other Windows users like me, that are expecting such a project to be born so they can join and participate in the writing.

3. Ease of installation in Linux

I like short projects, or projects that come with their own libraries, even if redundant. While it's OK not to bundle very large libraries like wxWidgets, it's *NOT* OK to ask for a dependency of an obscure video-processing library that also has dependencies on obscure math libraries that also have dependencies ad infinitum. What am I supposed to do if my distro isn't Ubuntu with their millionaire repository? I'm not asking for sharks with frickin' laser beams on their heads, I'm just asking to bundle the rare libraries so I don't need to download more stuff before doing the ./configure - make - make install ritual.

I really don't know what's the deal with some Linux packages, but I had this experience with Kdenlive, where the release they used was buggy and I couldn't export the AMV I was making. It had timing problems. Sheesh. So, I tried to compile it on my own and I was smacked on the face with another dependency hell.

How I'll succeed: I'll bundle the used libraries.
XML libraries, multimedia libraries, they'll be included in the source tree. And it's perfectly legal since they're OPEN SOURCE. Ease of installation also means increased exposure to Linux audience - those people who know how to program but run in a wide variety of Linux distributions.

4. Intuitive User Interface

Let me say this straight: It is my personal opinion (no offense intended) that some editors like Cinelerra, simply have a hideous UI. In other words, it sucks. (personal opinion), and the decision of some developers to make a new program from scratch instead of just forking, confirms this (unfortunately, they'll make it for Linux ONLY. Why oh, why do they leave Windows users in limbo?). Cinelerra used a custom-made User Interface, which means that whenever I try to open or import a file, I'll experience a lot of bugs - an annoying one is that I can't easily change folders because it keeps appending that darn slash at the end, and I can't remove it!

Then it's another maze to get to import a file. First, you can't import Divx files that you downloaded from the internet. Oh no, you first have to use some obscure tool to convert it to DV or M-JPEG format before you import it. More downloading of stuff. (And don't even get me started on crashes and hangs, but that's another matter).

Another video editor I had tried was Jahshaka. Let me tell you that if something is counter-intuitive, Jahshaka is. They provide little or no help, no documentation, no tooltips, no right-click context menus, no nothing. You had to memorize some cryptic key shortcuts and whatnot. I wiped it a couple of hours after installing the thing.

Come on guys, is that really hard to make an easy-to-use menu?

How I'll succeed: I'll copy what works.

I'll adopt existing user interfaces (i.e. menus, dialogs, widgets) from commercial projects like Adobe Premiere or Final Cut Pro. And don't worry about Trade Secrets - I'm not reverse engineering anything. This is why I'm creating the interface based only on existing documentation (i.e. books) and publicly available information (wikis, screenshots found on the web, tutorial videos, etc).

Q: Aren't you doing more software fragmentation?

A: No. I'm filling an unused niche (for the reasons explained above).

Q: Do you really think you can do this on your own?

A: No. This is why I'm making the webpage, posting the project on berlios (I'd choose sourceforge, but I've had good experiences with Berlios, specifically in the Code::Blocks IDE project (in which I participated, BTW :) )

Q: OK, you convinced me. How can I help you?

Since I'm doing this from scratch, I need users of commercial video editors to share their experiences and ask for features. It doesn't matter if you don't have the software right now, you can use MS-paint, right? Or you can record some screencasts (or flash animations, whatever) of your favorite video editors (even from memory, even if the drawings suck) , i.e. "this is how you do 3-point editing" (that one would help a lot, btw), or "I like how this tool makes an icon for you" and all that. I'm not an expert in making videos, I didn't take a $1,200 dlls. course on -nameyoursoftwarehere-, so this is why i need help.

If you're a Cinelerra or Kino or whatever - user, you can also record your screen casts or take snapshots and say "I want this feature!". I'll add it as soon as I can.

If you're a C++ programmer with wxWidgets experience, YOU'RE MORE THAN WELCOME to join the project.

So, please help me with Suggestions, feedback, and to paraphrase Neo:

"Screenshots. Lots of screenshots."