Re: Storing header backups, and other important stuff

 >Another issue is changing settings (video formats, etc) inside a file. 
 >In my opinion this shouldn't be supported (makes many things a lot 
more >complex and makes recovering data from broken files more 
difficult). >Instead, pieces of a stream with different settings should 
be saved to >separate files. That system would work in 
streams/broadcasts too: when >settings are changed, the first stream is 
terminated similar to the way >files are terminated and then the new 
file starts just like MCF-files >normally do, but with different settings.

I think this behaviour should be trigerred by a bit in the track entry. 
And supporting tracks with variable content should not be mandatory. (as 
it is unlikely to appear soon, so no way to test)

 >Yet another issue is Linear Write (ie. it is impossible to seek back 
to >the beginning of file to insert some values such as total file length).

I think we need to make sure the format can be linearly written. I 
consider it a key feature of MCF. So it makes having the file "stats" at 
the end (at least).

 >My ETA for things listed here is next weekend, so it is better to 
hurry >up a bit if you want to comment any of these things.

Are you working full time on MCF now ?

 >What comes to Transor (codec) API and other things, we need help from 
 >some people. That API is the biggest obstacle at the moment: we can't 
 >have any usable software until that API is working. Especially codec- 
 >and player developers could help there.

I agree. That's mostly why I stopped development (for the moment).

 >Most of you don't have a clue of what Transor is, so I'll try to 
 >explain it here.
 > ...
 >Transors are libraries, .dll, .so or whatever, so it is easy to 
install >new ones (no need to recompile anything). They are identified 
by Format >Name (16 octets) and other fields in MCF headers.

To sum up, a transor is like a Winamp plugin (for decoding/encoding) 
using simple C calls.

Of course we're losing a bit of efficiency because we use a layer for 
wrapping interfaces. But it might makes portable players easier to 
write. And plugins for a specified platform usable by many MCF+transor 
compliant applications.