Hi, long time no status report. Time to remedy :)
* 1.0.x ------- With 1.1.x released, it's entered in even deeper sleep. I plan to release 1.0.8 during summer collecting only the most annoying fixes, then this branch can finally rest in peace. * 1.1.x ------- Just fixes. A steady amount, but so far is better than expected. The only big change scheduled is the backport of the GraphicsMagick change, that will happen in (former) HEAD aka (now) default branch. See below for details. * 1.2.x/HEAD/default -------------------- Two big things are progressing in parallel. 1) port from ImageMagick to GraphicsMagick. It's needed because my main box has already switched to GraphicsMagick, so I need the new code ASAP for obvious testing confort. No big deal, except for the fact that I'm taking this chance to clean up the involved modules. Affects mostly modules, with a relatively big addition to libtcext. The backport to 1.1.x is pretty straightforward. 2) Full switch to NMS for export layer. Some hidden design flaws emerged as expected, so I've bitten the bullet and started a deeper cleanup. One little change at time, I'm ended up cleaning a lot of cruft; It's a quite big step, but I can't find an unneeded change. I'd like to highlight, among the others: * better (aka: real) extradata handling. Now module methods are extradata aware. Formerly, there was just a big ugly hack. Of course this is far from being perfect, but it's a good starting point. * new methods: open, close, split demultiplex in read_video/read_audio, split multiplex in write_video/write_audio. In a nutshell, don't pack too much functionalities in a single method. In a (far?) future I'd like to split TCModuleClass in a (simple) hierarchy, in order to reduce the number of methods of a given class (and in order to promote modularity). Maybe. * split encoder into real encoder, multiplexor, runtime control (stop/pause/counters) and frontend code (export). Again: reduce the mess, improve modularity. * rework multiplexor in order to support trasparently one or two multiplexor instance (think to y4m/wav pair, or pvn/wav or whatever). The last one will become the only user-visible change. I plan to change again the commandline interface, moving from -y vid_enc[,aud_enc[,main_mplex[,aux_mplex]]] -o main_out -m aux_out -N vid_fmt,aud_fmt to -y vid_enc[,aud_enc] -o main_mplex://main_out -m aux_mplex://aux_out -N vid_fmt,aud_fmt or maybe even -y video://vid_enc,audio://aud_enc [the rest unchanged] the key advantage is that the order is now variable because the prefix specify the media type (video or audio), no longer the position. So, any of the following will be legal: -y video://vid_enc,audio://aud_enc -y audio://aud_enc,video://vid_enc -y video://vid_enc -y audio://aud_enc Again, I know changing the UI is annoying, but yet again I find the advantages far more outstanding than the disadvantages. All the above impacts roughly equally the core and the modules. Comments welcome. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
