headers
ChristianHJW | 28 Aug 2002 14:55
Picon

MCF specs ( vital parts ) to be freezed soon

to.: mplayer-dev-eng <at> mplayerhq.hu
cc: mcf-mplayer-coop <at> lists.sourceforge.net

Cheers,

i'd like to inform you that we are planning to freeze all vital parts of MCF
specs now in the next 2 - 3 weeks, so that we can begin with making all
necessary changes in libmcf and also start coding the first transors.

As the topic on #mcf ( irc.openprojects.net ) said :

'... If you dislike anything or have improvements to suggest, speak now or
shut up forever :-)....'

Most important parts  for all mpalyer people to check out are :

http://mcf.sourceforge.net/transor/  ( general description of what transors
are )
http://mcf.sourceforge.net/transor/transor-API.html  ( transor API, to make
MCF - mplayer transor )

Christian

P.S. There was absolutely no input coming from gstreamer and openBeOS people
( despite shatty, being MCF part time member ) ..... but i know mplayer
people will give some input ;-) !!

P.P.S. We have a new webboard to discuss open specs points here :
http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewforum&f
=6&sid=7fd769a01422257ff9642589e0f19cad
(Continue reading)

Permalink | Reply | 0 comments |
headers
ChristianHJW | 6 Aug 2002 17:06
Picon

How about using this list in a different way now ?

Just a stupid idea of mine ( kind of brainstorming - dont jump on me if you
dont like it ) :

As we dont want to exagerate with the numbers of mailing lists for MCF and
as cooperation with Open BeOS ( OBOS ) people is maybe interesting for
mplayer people also ( is there a nice player for OBOS planned BTW ? ) , how
about using this list for discussing Dshow replacement, API and all other
OBOS related subjects also , of course in addition to the cooperation with
the mplayer people that will hopefully go on ?

Or should we direct it all to mcf-devel ?

Lemme know what you think ....
--
Christian

MCF mailing lists : news://news.gmane.org
Sites : http://mcf.sourceforge.net
gmane.comp.video.mcf.general
http://sf.net/projects/mcf
gmane.comp.video.mcf.devel
Soon :  www.corecodec.com
gmane.comp.video.mcf.mplayer
gmane.comp.video.mcf.announce
gmane.comp.video.mcf.mpc
Permalink | Reply | 1 comment |
headers
ChristianHJW | 6 Aug 2002 16:59
Picon

Alban, come back !!

Alban,

whereever you are, stop moving, stop building a house, break out of jail (
whatever ) ... but we need your input now !!

We are currently in the process of redesigning major parts of the specs and
your inout would be more than welcome on this. Also : we forgot the URL
where your MCF spec draft is .. lol ... so we cant even have a look at what
you were proposing !

So, again ... stop doing what you are doing now and come back !
--
Christian

MCF mailing lists : news://news.gmane.org
Sites : http://mcf.sourceforge.net
gmane.comp.video.mcf.general
http://sf.net/projects/mcf
gmane.comp.video.mcf.devel
Soon :  www.corecodec.com
gmane.comp.video.mcf.mplayer
gmane.comp.video.mcf.announce
gmane.comp.video.mcf.mpc
Permalink | Reply | 0 comments |
headers
ChristianHJW | 6 Aug 2002 16:27
Picon

Arpi, if you are still reading the mcf-mplayer list ... check this out :


http://news.gmane.org/article.php?id=190&group=gmane.comp.video.mcf.devel

http://news.gmane.org/article.php?id=199&group=gmane.comp.video.mcf.devel

http://news.gmane.org/thread.php?group=gmane.comp.video.mcf.devel

We had Open BeOS ( OBOS ) guys on our IRC channel lately and the guys showed
great interest in MCF as a standard container for their ( completely
rewritten ) OS.

Plans are to integrate MCF into OBOS as standard container, of course
support for AVI and others will be done also.

As the guys are looking for a kind of Dshow equivalent for OBOS we thought
we let you know there is maybe the chance to create some 'common' API or so
.... is this ever interesting for Linux ?

Regards

Christian

MCF mailing lists : news://news.gmane.org
Sites : http://mcf.sourceforge.net
gmane.comp.video.mcf.general
http://sf.net/projects/mcf
gmane.comp.video.mcf.devel
Soon :  www.corecodec.com
gmane.comp.video.mcf.mplayer
gmane.comp.video.mcf.announce
(Continue reading)

Permalink | Reply | 14 comments |
headers
Steve Lhomme | 15 Jul 2002 11:19
Picon
Favicon

Check this out

Really funny (and true)

http://www.tuxreports.com/modules.php?op=modload&name=News&file=article&sid=892&mode=thread&order=0&thold=0

The best part comes with this comment :
"Many people confuse these two. An application can crash and that''s 
when "kill" comes handy. To say that Linux is unstable just because an 
application has crashed is grossly inaccurate.

Try running Linux without any GUI and see if you ever have to reach for 
that power button!"

Yeah, it's not Linux that crashed, it's only your app that crashed your 
computer...
Permalink | Reply | 13 comments |
headers
Lasse Karkkainen | 11 Jul 2002 18:39
Picon

Re: The big question : Codec recognition from

> could you list these formats, available for more than one mm system?

MJPEG and all "raw" formats (YUY2, RGB24, etc) come to mind.

> so, imho for such multi-system formats the decoder should be able to accept
> all kind of mm system headers (where the codec exists) and translate them to

If MCF can contain stuff for any codec/system, and there are, say, 3 
different systems, this means that all codecs will have to support all 
three options. (VfW codec would need to read VfW, QT and RM)

Easier way is to convert to "MCF format" (like Steve said, could be 
closely related to one currently existing format) when muxing. With 
this, codecs only need to know how to convert to/from "MCF format".

> the codec format. as it's codec dependent (you can't make generic code to
> translate quicktime header to avi header, as the codec specific data is
> stored different way) only the codec (decoder) can, and should deal with it

Transors (MCF codecs) handle that. On one side, all Transors have the 
same API (that supplies "MCF format" data). On other side they either 
contact external VfW/QT/any codecs or actually contain the codec (and 
de/encode internally).

This stuff is not explained well anywhere, yet. :(

- Tronic -
Permalink | Reply | 10 comments |
headers
ChristianHJW | 8 Jul 2002 17:13
Picon

Cooperation between MPC and MCF


Hi Frank,

please allow me to introduce myself. My name is Christian and i am project
administrator for an opensource project called MCF ( Multimedia Container
Format ).

I was posting a thread to the MPC forums at Hydrogenaudio today, but got
informed from JohnV that you may not be reading there for the next 3 weeks,
so he recommended to drop you an email instead. Link to the thread is here :
http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=2576 .

For my convenience i am simply copying and pasting what was said to the mail
here :

----------------------------------------------------------------------------
----------------------------------------------------------------------------
------

MCF ( Multimedia Container Format ) : offer for cooperation to the MPC dev
team
Hi,

please allow me to repeat our offer for a cooperation to the MPC dev team
here in this sector of HA ( original post in News Section ) :

We were informed that current framing system of MPC ( SV7 ) does not offer
any form of CRC, making streaming almost impossible. SV8 should bring a new
framing for MPC, including CRC and other necessary features every modern
format needs.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lasse Karkkainen | 6 Jul 2002 03:06
Picon

Arpi: we need to discuss MPlayer's A/V sync

Albeu said that MPlayer needs timestamp for every audio frame and that 
it cannot just decode those frames and use the duration given by the 
decoder for sync.

So, how exactly does this thing work? How does it handle most current 
containers (AVI, Ogg) that usually contain audio frames without timecodes?

Adding timecode (or even time offset) for every frame makes overhead 
significantly bigger.

Would it be possible to just handle frames of a single Block as one big 
frame, when doing sync? This way you wouldn't need to quess timecodes 
for frames which don't already have one.

In case you are not familiar with MCF, Block is an element that contains 
timecode and data. With audio it normally contains several frames and 
then you only have timecode for the first one. Of course a Block only 
contains audio for around 50 ms, so there is no trouble with seek 
accuracy nor sync drift.

- Tronic -
Permalink | Reply | 1 comment |
headers
Steve Lhomme | 4 Jul 2002 11:35
Picon
Favicon

MPEG audio

I'm about to start a project similar to wav2mcf called mpa2mcf...
It's a program to put MPEG audio data in an MCF file.

I just looked at http://mcf.sourceforge.net/formats.htm

And apparently the MPEG audio is not complete. It says :
# "MPEG-1" - MP3, no Codec Header, set Format Versions to 3

I'm OK for the no codec header.
But why "Format Versions" should be set to 3 ?
As far as I know there are :
MPEG-I, MPEG-II and MPEG-II.5 and Layer1, Layer2 and Layer3 for each...
So Format Version could be 1, 2 or 3 depending on the original file.
Also "MPEG-1" as a format string is not correct. I suggest it should be 
"MPEG-Audio".

As I don't know about MPEG-4 audio (AAC I think), I don't know if it 
will be contained in this "MPEG-Audio" or not.

With that said, mpa2mcf could be working by the end of this week-end. 
I'll need to a small work on the Format String setting in libmcf, then 
I'll change wav2mcf to handle PCM (only for the moment).

Maybe Ingo's work could also make use of the created files (recreating 
the right MP3WAVEFORMATEX or MPEGWAVEFORMATEX structures on the fly).

(so far mpa2wav only support MPEG Layer 3 and is close to be working)

BTW, if anybody could make some equivalent (portable) programs for video 
(HuffYUV, MPEG1, MPEG2, MPEG4 and AVI compatibility) that could be
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian HJ Wiesner | 2 Jul 2002 13:15
Picon

Lossless audio codec inplementation for MCF - FLAC or Monkey ?

Gentlemen,

for your information i am including a log of a conversation i had with some
guys on #project_mayhem this morning :

<ChristianHJW> cheers guys
<ChristianHJW> if we are going to implement a lossless format into MCF as
'supported native format'
<ChristianHJW> should we go for FLAC or Monkey ?
<Garf> if there arent any licensing issues, i'd pick monkey
<Garf> though IIRC it depends on optimized x86 assembly to work well
<Garf> FLAC has buggy code
<ChristianHJW> we dont expect to have licensing probs, as we are only
storing the data
<ChristianHJW> but FLAC is opensource, right ?
<Garf> so is mac
<jonI> has anyone actually packaged monkey for Linux yet?
<jonI> ChristianHJW: the source code for MAC is out there, but under an
unclear license.
<ChristianHJW> so this helps a lot when trying to find the best data
structure to store them in MCF container
<ChristianHJW> jonI : any chance to hand me a link or so ?
<Garf> flac also has the advantage that ogg framing was already done, so you
have an example
<ChristianHJW> thats very good news indeed
<ChristianHJW> can i find that in normal Ogg CVS ?
<jonI> the ogg framing may even be in the FLAC source code.
<jonI> it would be on the FLAC site, not the ogg one, I imagine.
<ChristianHJW> thanks for the hints guys
<ChristianHJW> any objections me sending the  log form here to mcf mailing
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lasse Karkkainen | 30 Jun 2002 17:19
Picon

Storing header backups, and other important stuff

Hi all!

Previously we discussed this topic on the IRC channel and agreed to use 
Magic Blocks for storing header backups, this way:
{[MagicBlock with code for header backups]}(Main Header)...{[...
Legend: {}=Cluster, []=Block, ()=other Element, ...=something

There is one obvious problem in that approach: demuxers which already 
have those headers and don't need to read backups have difficulties 
skipping those headers.

Because of that, I propose that we store backups this way:
{...[MagicBlock that contains header backups]}{[...

Here players could easily skip that Block, just like they skip any 
unknown Block. When reading headers from it, it would contain Main 
Header (1024 octets or bigger) and optionally other Elements and then 
link (Clusters Element position) to the next Cluster start.

Albeu has his own way for storing headers (any (keyframe) Block could 
contain 'em and there would be a flag denoting if the header is there or 
not). His header suggestion is not related to any existing MCF header, 
but is a very stripped-down AVI-only header. The header he is suggesting 
is way too simple for advanced container like MCF, so it will need to be 
enlarged quite a bit until it gets usable.

What's good with Albeu's header is that it is clued to the video Block 
itself (Block explains its settings) and is quite a bit smaller than 
normal MCF headers.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane