Re: [UCI-Devel] MPC dev team now to use OGG and MCF officially as transport containers

"Steve Lhomme" <[email protected]> schrieb im Newsbeitrag
news:[email protected]...
> En réponse à ChristianHJW <[email protected]>:
> > - fix MCF specs, at least for simple audio streams
> You can't fix just one part of the format like this. Of course you don't
need to
> know how the file attachment will work. But the broadcast/non-broadcast
modes
> merging is still not done. So files produced now won't likely to be
playable
> later. Of course having the data stream be finished is the top priority,
to
> start working on the code :)

Sure ! after the specs are closed and put down in DocBook format we have to
get our hands on libmcf again, right ?

> > - create a mpc2mcf.exe for SV8 ( somehow based on MPEG still, for sure
> > - adapt MCFparser.dll, maybe even include a MPC decoder in it ?
> The MPC decoder is already open source. So it shouldn't be too hard to
adapt it.
> But rather have a UCI decoder instead of anything parallel to that.

Well, i was talking to Alex about the status of UCI this week. He was asking
me kindly to calm down a bit with my enthusiasm for UCI, as from his point
of view it will still take a while until UCI is fixed and ready to use. The
libuci he is doing now is ment to be a kind of example code for app
developers considering to use UCI, but still a good step from completion (
but it already compiled on his machine he said :-)  ). So its maybe not an
option to wait until we can access the MPC codec via UCI, but it seems we
will have to modify your mpa2mcf.exe such that it will transmux MPC files to
MCF, just like what its doing now with MP2/3 . As we can assume that MPC SV8
raw format is somewhat similar to MPEG streams in principal, maybe not a big
problem to to at all ?

UCI interface can be added later to MPC, once its opensource, first decoder,
than encoder. It will fit well into the general structure of MCF then,
without any major changes being necessary . But for the time being, if we
wanted to have a way to mux MPC raw streams into MCF container we had to
have a MPC2MCF.exe IMHO. Do you disagree ?


> > To-Do-List ( medium term ) :
> > - fix UCI specs, at least audio part of codec interfacing
> > - put UCI interface into MPC decoder
> > - adapt MCF parser to be able to call MPC decoder via UCI
> > - put UCI interface into MPC encoder
> > - create encoding tools calling MPC encoder via UCI
> > Am i asking too much ? Any chance MCF will be an alternative container
> > to
> > Ogg for MPC, once MPC SV8 is launched as an opensource project ?
> Sure, but is there really a rush here ? We're not going to work mostly
with one
> codec. Of course we have to start somewhere. But there are more simple
> alternative than MPC to start with (raw audio and video first).

We can do whatever we want, no need to rush. I was asking this as a question
if we should maybe consider changing some of our priorities to make sure MCF
is a usable and specs compliant as a container for MPC, once SV8 encoder is
ready to go, and released as an opensource project. Once people start to use
Ogg for this it will be hard to revert this . Apps coders like EAC, CDeX,
etc. dont have their major priority in adding a few different containers for
a single audio codec, especially if one is already working.

Are we really that far away from an updated libmcf , producing spec
compliant MCF files ? I cant see MPC SV8 being publically available before
december. This should be still plenty of time for us ?

Adding MPCdecoder to mcfparser cant be such a big problem ( i hope ) ?? As a
result every dshow based player could playback MPC files from MCF container.

If you dont like the idea or if its technically not feasible, ok with me.
But be informed we might miss a big chance here.

The big, bad pusher :-)
Christian






-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en