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,
--
Francesco Romani // Ikitt
[ Out of memory. ~ We wish to hold the whole sky, ~ But we never will. ]
