Sun Jan 1 14:18:33 CET 2006

bump

Happy new year ;)

I've got a .ts sample to work on, but I'm looking for a few more, and I've finally established the new design for mpeglib 0.3.x (aka ng branch). As announced before, the new trunk will have two layers: a bitstream-to-PES-packets layer, and a stream layer on top of the former, that will take care of packing packets into frames, probe streams, gather metadata, and so on. I plan to start a new repository on http://cvs.exit1.org when I got something useful to show, ant this means at least a packet(-izer) layer capable to read data. Sadly, at time of writing almost all my hacking time is dedicated to the new export layer of transcode, so don't hold your breath for new mpeglib. And since I've still some other business to do (http://www.ing.unipi.it), hacking time will not grew up fast.

Posted by Francesco Romani | Permalink | Categories: plans

Tue Nov 22 20:15:46 CET 2005

development continues

mpeglib development continues, even at slow rate ;) I'm currently summarizing all known pros and cons of actual code, and I'm rethinking the internals, the purpose, the running environment of mpeglib, it's preconditions (what kind of file mpeglib should expect?) and so on. In just one word, "everything". ;)

I'm not say that future mpeglib will be rewritten from scratch. I'm quite satisfied of some substantial parts of code (say: probing support, data structures, support code); I'm simply trying to make clearer what mpeglib should really do in greater detail. I've some ideas defined, but some details are still missing; later I'll write a full spec, and then coding crazyness can restart. :)

The main, fundamental, purpose (as for 0.3.0) of mpeglib is to offer to upper code a stream of separated packets containing all encoded data, ready for feeding decoder. mpeglib should also decode all interesting header informations, give a way to achieve optimal A/V sync (using, of course, informations found in streams), and offer a limited probe support for understanded formats. In short, mpeglib aims to be a generic mpeg system stream demuxer.

This is clear and will not change (will be just improved :) ).

Some sparse ideas so far (in approximate order of increasing crazyness :) :

  • planned feature set for upcoming 0.3.0 (0.1.x and 0.2.x are rispectively test and preview code): full read support for PS, TS, ES and VOB stream. no write support except for ES (it's trivial, given data will be writted verbatim :) ). probing support for all stream format which can be packed in above formats. (MPEG1/2 video, MPEG/AC3/LPCM audio).
  • It should be a good idea to introduce a packet cache to reduce malloc() pressure; mpeglib should provide a way to use a static client-provided buffer for new packet, but I have'nt still found a good & clean idea to do so.
  • actual code depend *really too much* from single generic (but not generic enough!) pes reading code. So, TS streams will not be handled gracefully
  • I/O model is still a bit messy, it need to be made clear. I'm almost convinced to go with a pipe-like concept. In short, except for probing (which always need to seek stream, we simply can't do in a different way), mpeglib should assume that source stream isn't seek()able. But source stream should be avalaible identical multiple times; so, raw unneeded data will not be keeped mandatory. Now. This can change before to get back on the code. So, mpeglib will not use seek(), but it's possible that only a single stream for instance will be avalaible. THis issue really deserve a more careful study.

Posted by Francesco Romani | Permalink | Categories: plans

Wed Nov 16 07:39:19 CET 2005

welcome, transcoders!

Hello everyone and welcome on mpeglib page!

This page will hold all information related to MPEGlib development, organized like a blog, thanks to the nice nanoblogger (http://nanoblogger.sf.net).

Why? Because nanoblogger is fast and easy to use, and produce reasonnable (X)HTML, letting me to focus on the code, documentation and other production issues ;)

What is MPEGlib? MPEGlib aims to be a complete MPEG muxing/demuxing library, designed to integrate well with transcode while remaining an independent project. In short, MPEGlib aims to be for MPEGs what avilib is for AVIs. Grab the transcode sources to get the avilib code.

Who am I? I am the MPEGlib author of course ;) A few notes on me: http://www.transcoding.org/cgi-bin/transcode?Fromani

At the time of writing, MPEGlib hasn't yet it's public CVS repository. I will upload here on this page(s) snapshots of the code when a milestone is reached, and of course when a new release pops out.

Nanoblogger is lean and fast, but doesn't support comments. So, for any communication (including complains about my english ;) ) feel free to contact me using email (fromaniatgmaildotcom).

Stay tuned for more MPEGlib news! :)

Posted by Francesco Romani | Permalink | Categories: other