Re: NMS and export layer, the state of the union (complete)

Francesco Romani wrote:
> Hi everyone,
>
> While 1.1.0 is progressing slowly but steadly, I've also restarted working
> on HEAD, thanks to some extra time kindly provided by Magic & Miracles dept. ;)
>
> The plan, which hopefully will lead to 1.2.0 in reasonnable time, is
> roughly the following:
>
> 1. complete the port to existing export modules to NMS
> 2. disable export layer by default, then remove it if noone complains
> (too loudly) for some time (something like a few months, 6-8 weeks).
> 3. add some new modules (full-featured xiph first stack due to
> real-life requests. mkv and mp4 are planned as well):
>     - theora/vorbis/schroedinger/speex/flac encoders.
>     - ogg multiplexor.
> 4. power up import_ffmpeg (this will boost transcode's import capabilities
> _without_ mplayer :))
>     - use libavformat as demuxer
>     - add support for audio
> 5. Start to plan next Module System revision
>     - configure() operation is messy.
>     - we would like to have open()/close() operations.
>     - having explicit flush() for encoders (decoders) would be sweet too.
> 6. Start to plan next core changes (my pet peeve: drop the memcpy count, reusing
> double buffer in our *frame_list_t)
> 7. Continue to port more filters to NMS, and outline the requisites
> for new filter layer.
>
>
> Well, point 2 is pretty straightforward, points 1 & 4 is ongoing, for
> points 5,6,7 I'm already collecting some thoughts, point 3
> is scheduled after 1 is completed.
>
> So, I'd like to summarize the status of NMS porting of export modules.
> Let's see what we have in 1.1.0:
>
>
> old module          new module          done?   Notes
> --------------------------------------------------------------------------
> export_ac3.c        N/A                 yes     replaced by encode_lavc
> export_divx5.c      missing             yes     anyone volunteering?
> export_dv.c         encode_dv +         almost  no audio yet
>                     multiplex_avi
> export_dvraw.c      encode_dv +         almost  no audio yet
>                     multiplex_raw
> export_ffmpeg.c     encode_lavc         almost  no audio yet
> export_im.c         encode_im           yes
> export_jpg.c        N/A                 yes     replaced by encode_im
> export_lame.c       encode_lame         yes
> export_lzo.c        encode_lzo          yes
> export_mov.c        missing             NO      see below
> export_mp2.c        N/A                 yes     replaced by?
> export_mp2enc.c     missing             NO      see below
> export_mpeg2enc.c   missing             NO      see below
> export_null.c       encode_null         yes
> export_ogg.c        forthcoming         NO      planned full-featured stack.
> export_pcm.c        N/A                 partly  will be merged in multiplex_raw
> export_ppm.c        N/A                 yes     replaced by encode_im
> export_pvm.c        N/A                 NO      requires deep architectural review
> export_pvn.c        multiplex_pvn       partly  work in progress, easy to port
> export_raw.c        multiplex_raw       yes
> export_tcaud.c      N/A                 yes     useless with NMS.
> export_toolame.c    N/A                 yes     replaced by?
> export_wav.c        multiplex_wav       yes
> export_xvid4.c      encode_xvid         yes
> export_yuv4mpeg.c   multiplex_y4m       yes
>
>
> Some modules deserve a few more details.
> * export_mov
> I don't want to drop libquicktime support unless forced, but I'm doubtful about the placement
> a NMS-module. Should we drop the encoding part and let libquicktime handle the
> muxing only? At *first* glance libquicktime's API doesn't look so friendly for our
> purposes. Further investigation is needed (and volunteers welcome ;) )
> * export_mp2enc
> I would like *really* much to preserve support for this encoder, but integrating it in NMS
> isn't trivial (well, the existing module isn't exactly brilliant anyway :( ).
> In a few words, the problem is that using a private pipe like we do now raises some eyebrows:
> - using pipes for r/w will be slow. Transcode is already slow enough for my own taste ;)
> - using a write-only pipe, aka letting mp2enc writing the output file, will violate both
> the design and the purpose of an encoder module. I'll do an exception, but I don't like so.
> Feel free to ask more if interested.
> * export_mpeg2enc
> Same as above, with the notable addition that is theorically feasible (but this sounds nasty
> looking at the API) to code a native module.
> Feel free to ask more if interested.
>
> Chapter PVM.
> I'll be laconic: current code works by pure luck. Period.
> I'm *HIGHLY* interested to preserve explicit and well-integrated clustering support in transcode,
> but I simply cannot afford it right now because
> - I've no time to learn nor to experiment.
> - I've different development priorities.
> - Current code is NOT a good starting point.
> Conclusion: patches *VERY* welcome, otherwise the only solution is to get stuck to 1.0.x for a quite
> long time.
>
> NMS revision.
> Ok, I've done some design mistakes with first revision of NMS. They say "it happens". It happened.
> So, _after_ NMS released and _after_ a few new modules ported (especially some import modules) 
> I'd like to get back to design table and propose a new NMS version.
> I would and will work as hard as I can to change _the minimum_ amount of code especially in modules.
> Next NMS revision will be something like 1.5, not 2.0
>
> Documentation.
> I'll be laconic again. We lack on this. And we lack time to improve this. :(
>
> New stuff (FAR FAR future, something like futurama...).
> Since our infrastructure is slowly getting in place, I'm starting to plan to add new features, most
> notably filters. I'm interested in scenechage detection algorhytms, deringing, denoising and deblocking
> filters. A scriptable testframe generator will be sweet. Improving socket interface (new commands)
> and maybe adding a scripting interface would be a very interesting move.
>
> Final words.
> Thanks for reading this. Sorry for the typos that I'll surely spot just AFTER clicking 'send'. :)
> Any comment is of course warmly welcome.
>
> Best regards,
>
>   
Thanks a lot for the update! 

The long-term vision is important, especially for free software, which 
tends to scratch the developer's short-term itch. On the other hand, I'm 
a bit concerned that you may be stretching yourself too far -- it's a 
major job to move 1.0.x to 1.1.0 successfully, and clearly a lot to be 
done on that front still. If the different parts of the project move at 
different speeds, we could end up with a bunch of versions, each of 
which accomplishes a particular task well, but no single unified relase.

Version fragmentation is a risk to guard against when you embark on 
major code refactoring -- the best strategy may be to leave enough of 
the old structure in place that the modules you don't have time or 
interest or expertise to work on, still survive in the refactored 
version. Or you'll be like a general who's way ahead of his army!

Cheers,
David