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

[Cyrius]

Hi

--- Moritz Bunkus <moritz at bunkus.org> wrote:
> 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.)

I noticed that you use timecodes (ns precision) in your API.
When working on my previous dream :p I was unsure whether fixed
timescales (here 1ns precision) or a rational system was better.

For exemple in VDub Avery Lee now uses a rational value to express the
rate of data, thus keeping perfect precision till the end.
For Constant FrameRate streams it would be the framerate/samplerate,
and for variable framerates it would be a 1ns timescale too. For CBR
audio it could even be the byterate.
Of course with such a system you need to multiply the 'index' given to
you by the 'rate' to get time information ... but many formats chose to
use this as basis (numerator/denominator to express a rate; it's used
in AVI, OGM and Nut, dunno about the other formats).

Maybe other people could express their feelings about both systems ...

> 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.

I also think that's the way to go.
I had a similar idea.

> 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 :)

Moo.


__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html