[MPlayer-dev-eng] Re: MCF ( Multimedia Container Format ) : Invitation to participate

[Felix Buenemann]

On Sunday 09 June 2002 11:10, Christian HJ Wiesner wrote:
> My reply to Felix :
>
> <I don't see where choosing the right video codec has anything to do with
> the
> <file format
> Unfortunately its not that easy. What you say is certainly true for a
> format that is mainly focussed on one particular OS, maybe two ( Windows,
> Linux ). On Windows all you need is to provide the FourCC for a VfW or
> dshow based player, and as most players on windows use a semi-automatic
> graph rendering ( again dhsow ) it wouldnt be too hard for us to simulate
> the behaviour of AVI for this. In fact, the existing muxer for Ogg ( .ogm )
> from Tobias is based on Dshow also, Tobias created it to be used with
> Graphedit, being M$' tool around Dshow. In principal it is demuxing an
> existing video stream from an AVI, copying the codec related info from the
> AVI header ( WAVEFORMATEX ), writing these into the Ogg header and thats
> it.
> Its interesting to hear ( we truely didnt know ) that you can do the same
> ( or almost the same ) on Linux. But this still doesnt help for other OS
> like MacOS, etc. and hardware support ( standalone players ). Especially
> the last is a big problem, just look at the big varieties of different
> MPEG4V3 clones ( DivX3, SMR, Angelpotion, etc. ). All these can be played
> with the same decoder, but all have different FourCC and GUIDs for codec
> verification. In fact this is the main problem IMHO why there arent any
> hardware players for DivX movies ... its the big variety of different
> FourCCs and GUIDs being used for the very same thing. MCF is taking this
> into account. We are planning to have
> - a dshow mode (AVI compatibility mode ), using FourCC or GUID strings in
> the format header to recognize the codec, plus having a AVI like rendering
> function so every VfW or Dshow based player can use MCF once the format was
> implemented into the player.
> - a x-platform and hardware compatible 'plugin' mode, only for recognized
> and standardized codecs ( like MPEG1,2,4, AAC, Vorbis, Tarkin, MP3, AC3,
> etc. ). In this mode the decoding of the streams is not left to an existing
> decoder or Dshow filter being installed on the PC, but is done with
> specific plugins for each codec ( or better : compression format ), being
> created for every OS. A first plugin could be a generic MPEG4 ISO video
> plugin to be able to play DivX5, XviD, QT6, etc. A next plugin could be
> MP3, AC3, Vorbis, whatever. Of course, this is big effort ! These OS
> specific plugins must be specified, coded and maintained, being major work.
> But doing this we could assure that an MCF file being created in plugin
> mode would run on every OS with an OS specific, best suitable decoder, and
> even hardware support would be much easier.
> Its up to the user to decide on muxing the movie into MCF format whether he
> would prefer Dshow or plugin mode. We have to tell him the pro's and con's
> of each mode, like the ability to use the latest avaialble Dshow decoder
> for his movie if he goes for Dshow mode, or x-platform and giid hardware
> compatibility if he goes for plugin mode. On muxing we have to assume the
> data provided are spec compatible, means our muxer app can not check if the
> stream it gets is really MPEG4 ISO compliant.

I don't know where your problem is here, you don't need any DShow stuff in 
order to choose the right decoder, it is as simple as this in mplayer:
Check AVI FOURCC -> Compare with FOURCC list in codecs.conf -> load decoder 
and display video. That's it, wtf you need DShow for here? Different FOURCCs 
that are compatible are simply mapped to the same codec, still no problem 
here. (Btw. MPlayer also runs on MacOS X also beta state ;)

> < We don't use the windows code, we have an own implementation of the ogm
> < demuxer. Btw. we can even use windows dshow codecs through our dshow
> < emulation layer which is based on wine (code is inherited from aviplay
> project).
> Did Tobias help you with that, f.e. did he give you the basic structure of
> his Dshow implementation, or could you do a kind of reverse engineering
> here ? I know he is using the basic data structure of Ogg, but we cant find
> anything in the Ogg specs where the codec header info is stored. I had no
> idea ( not sure about the MCF dev team, i am only a helping hand ) that
> there is a possibility to emulate Dshow on Linux. Would you think of this
> as a good solution ? Any know downsides ( high CPU power ) ?
The DShow emulation is only needed to interface Win32 decoders written for 
DShow, cpu load is exactly the same as on windows, why should it differ...

OGM: I can't speek for albeu who did this, gut I thinks it's fully reverse 
engineered. Still I see no reason where demuxing this needs any 
knowlegde/emulation of DShow.

> < Yes, the ogg format wasn't at all aimed at video from the beginning,
> < so it's pretty much a hack/suboptimal from what I can see/have heard.
> Well, this is maybe not 100% true as Xiph people are working on Tarkin
> also, being their own Video codec. But for sure it was not ment to hold any
> other video data. Tobias Ogg implementation is in one way or another a kind
> of a hack, yes. It was his decision how to put subtitles in Ogg, etc. .
> Also his decision to copy the AVI header info and using FourCC for codec
> recognition is maybe not a solution the Xiph people would like too much, as
> they are aiming for x-platform compatibility also.
Still I see nothing that keeps this from beeing crossplatform as it is now, 
just player has to know how it works, then it can support it.

-- 
Best Regards,
        Atmos
____________________________________________
- MPlayer Developer - http://mplayerhq.hu/ -
____________________________________________