[Matroska-devel] TCME low level file/file format input/output APIs

Moritz Bunkus moritz at bunkus.org
Thu Feb 5 15:58:18 CET 2004


Heya,

like I said I'll be really busy from tomorrow on, so this is probably my
last big work for the coming five weeks.

I've wanted to start working on some low level APIs that are independent
of the decisions we still have to make on the upper levels including the
scripting language. The APIs I talk about are: file I/O abstraction API
and demuxer/muxer API (I call that "file format input/output API"). My
work can be found at
https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/

Before you start shouting "Noooo! Don't code, think first!" let me
assure you that I do NOT want to code a complete API and think about it
later. I HAVE thought about it a bit. It's just that I can think better
when I'm coding, I especially tend to forget to include things that are
neccessary.

Here I go.

1) File reading/writing abstraction API
https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/fileio.h

Basic stuff. Open files, read from them, write to them, seek in them. As
a bonus they can handle text files in a special way (read the .h file,
plesae): files with BOMs are supported and lines converted to UTF-8
automatically. Both DOS style and Unix style new lines will be handled
correctly.

2) Demuxer/muxer API, called file format API
https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/fileformat.h

This is based heavily on ffmpeg's libavformat. I've left out some stuff
and added other stuff, but my experience with demuxer APIs is very
limited. I'd like the input of the guys who're familiar with the other
demuxer/muxer APIs around (VDubMod's, gstreamer, milk). Unfortunately
Ronald will go to New York on Sunday, so we probably have to dig into
gstreamer ourselves. (Good luck and a lot of fun in NY, Ronald.)

My aim was to keep it simple. No fancy XML stuff (so far). Pure C
function calls.

One note about the "file/track extensions". I chose against including a
LOT of fields in the track and file structures as they're quite
numerous: title, language, chapters, attachments, tags, default track,
disabled, whatever. The "advantage" of doing it this way is that a
demuxer/muxer pair can easily add their own extensions that others don't
know about - this wouldn't be possible if we chose to have everything as
members.

3) Test app, common.h, whatever
I've implemented a SRT subtitle reader and a small test
application. Nothing fancy, I just wanted to get the basics straight.

Now it's your turn to say something :)

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds



More information about the Matroska-devel mailing list