[Mplayer-dev-eng] TMF file format, "replacement" for AVI

[Arpi]

Hi,

> Hi,
> at the ProjectMayo forums somebody advertised his
> file format "TMF", which he want to see as a replacement
> of AVI, if only enough people start to support it.
> It's of course an open standard, information is at
> 
> http://solidhardware.com/sn/?tmf
> 
Checked. Bad.

It can be better than AVI, but it's very similar to QT, doesn't do
more or less. Then why to introduce a new format?

The main problem with it: it uses variable sized blocks just like
AVI or QT. So if a block header is destroyed, you can't resync stream,
without doing some brute-force unstable search for next valid header.
I prefer fixed blocksize formats, _or_ formats with long (16-32bit)
_unique_ sync-word. Just like mpeg streams. They can be used even if
damaged or broken. Header should be duplicated, one header is not header.

And a little note about its subtitle format: it has a byte for codepage:
 0 = latin-1
 1 = unicode
why don't he uses 0=unicode 1-9 = latin 1-9 then? it has much more sense.

So, it has good ideas, has flags for everything and allows extensions
like 'ext2fs in a track' and so... but QT also does these.
QT even allows including the playback plugin code into the file :)
(self-playing anim formats? divx-viruses? :))

> Maybe mplayer (known for adapting very fast to everything
> new) could be one of the first to support in the new demuxer?
If it will be wide used, i'll add support for it. But I see no
sense supporting it now, and even no sample files for testing.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu

_______________________________________________
Mplayer-dev-eng mailing list
Mplayer-dev-eng at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng