Thanks for the update! Francesco Romani wrote: > Hi everyone! > > Since, as we hoped, interest for 1.1.0 is slowly increasing, I like to post a > quick summary of what's going here on developer crew. As subject said, this > kind of report is guaranteed fully aperiodic, unpredictable and irregular ;) > > Summary: > ======== > > 1. Recent changes on CVS > 2. Future plans > 3. Bugs, patches and issues recap > 4. 1.1.x release status > 5. 1.0.x release status > > *** > > 1. Recent changes on CVS > ------------------------ > > On those days I'm working to improve the internal framebuffer handling > (again). I focus on how frambuffer are passed between decoder, encoder > and filter stages. There is quite a lot of room for improvements. > > #ifdef GORY_DETAILS > The main problem, IMO, is that syncronization conditions between different > threads (see for example decoding threads VS encoding threads) are often > quite obscure and suboptimal. There are often some sleep()s used for > syncronization, and this is a no-no following almost all threading literature > (and also following my own taste :P). > Moreover, synchronization variables are made public and shared through src/, > and that makes difficult to modularize further the codebase, and is also > misleading sometimes. We need some order, to make things cleaner, nicer and > maybe even faster. > #endif /* GORY_DETAILS */ > > Why we need so? > Most important first: we need some sanitization and cleanup in order to have > the needed infrastructure to implement a long-waited solution for directory > mode issues (see next point). > In the broad sense, we will face this task later (and in an harder way), so > it make sense to start to approach it gently. > > My effort is quite ready to be merged in CVS (actual patch is ~670 line with > context), there is just a known regression that I must address before. > (^C causes lock). > Just so I understand: is your patch laying the ground for better synchronization code, or is it a cleanup of the actual synchronization code? > 2. Future plans > --------------- > > The last big thing missing before to go alpha with 1.1.0 is to solve the > otrageous directory mode bug. The solution I've chosed is to implement > *input* rotation as well as *output rotation*. In a nutshell, this means > that future transcode will do something like > > open_encoder() > for input in input_sources: > open_decoder(input) > encode(decode(input)) > close_decoder(input) > close_encoder() > > instead the current, ugly > > new_input = blindly_concatenate(input_sources) > open_encoder() > open_decoder() > encode(decode(new_input)) > close_decoder() > close_encoder() > > Advantages? Things will just work as expected. Finally. > No more things like: > transcode -i input1 -o output2 > ... > transcode -i inputN -o outputN > magic_merge -i output1,...,outputN -o real_output > > transcode will finally do the right thing by himself. > > 3. Bugs, patches and issues recap > --------------------------------- > > Allan Snider has kindly sent some really interesting patches on -devel on > last days. My plan is to merge *all* of them during 1.1.0 alpha cycle. > Could you give details? > 4. 1.1.x release status > ----------------------- > > In approx. priority order, the schedule is: > * finish core syncronization cleanup > * implement input rotation > * roll out alpha (make new branch on CVS) > * improve and tweak import_x11 > * merge patches > * fix bugs > * roll out beta > * fix bugs > It's great to see you're focusing on the guts of transcode; I'm convinced that's the right choice. My wishlist beyond that is an x264 export module.
And (ir)regular developmental status reports would be much appreciated. Cheers, David > 5. 1.0.x release status > ----------------------- > > In approx. priority order, the schedule is: > * merge export_wav fix (that will be probably done at time you'll read this) > * roll out hopefully last rc for 1.0.3 > * announce avalability of last rc > * release 1.0.3 after ~2-3 weeks of last rc, if noone complains. > > Questions? Thoughts? > > > Best regards, > >
