ChristianHJW
15th May 2002, 17:51
thread still to be edited
Hi folks we have a big decision to make and ask anybody with a coding and DirectShow background for help here.
Copied and pasted from Ingo and robux4 discussing about that :
<robUx4> Ingo: do you know if it's possible to play a stream in DShow without the extra informations (cbSize=0 or something like that) ?
<Ingo> Only PCM.
<robUx4> yeah ?
<Ingo> And uncompressed bitmaps.
<robUx4> it's absolutely required ?
<robUx4> have you ever tried ?
<Ingo> Well, downstream filter simply reject the connection.
<robUx4> Ingo: are you sure about that ?
<Ingo> Yes
<robUx4> Ingo: :-(
<robUx4> that's really bad
<Ingo> What did you expect. What media type do you want to play?
<robUx4> because that means we need to store codec headers for all OSes who probably have incompatible systems for that
<robUx4> ANY media type
<Ingo> I know. That is the point.
<Ingo> Determining whether to use GUID or string is only the very beginning.
<robUx4> you put the correct GUID (in a bigger structure) and then set the extra information corresponding to the codec to 0 size
<ChristianHJW> oh no
<robUx4> ChristianHJW: yes ..
<ChristianHJW> dont tell me there are more probs to be expected ?
<Ingo> No there arent't
<Ingo> At least not than I expected.
<Ingo> Can't speak for the others.
<Ing<ChristianHJW> you said teh question GUID or string is only the beginning
<ChristianHJW> so i thought there are more probs on the way
<Ingo> Of course.
<Ingo> Lets assume we have decided about that GUID question.
<Ingo> Now a codec needs a header.
<Ingo> For one time initialization data.
<Ingo> Unfortunately this data on Windows is unknown.
<robUx4> I don't follow you
<Ingo> I meant the format of it.
<robUx4> the format of the extra info ?
<Ingo> Do you want to put the private data of the WAVEFORMATEX (after the cbSize field) into the codec header?
<robUx4> (like the extra data in MP3WAVEFORMAT compared to WAVEFORMATEX)
<Ingo> For example.
<robUx4> ok, these data
<Ingo> MP3 is a special case here, because you can extract the fields from the frame data itself.
<Ingo> But usually you can't.
<robUx4> as long as you know the structure
<robUx4> but using another codec is the same, with an unknown structure (only to the codec)
<robUx4> (only the codec KNOWS)
<Ingo> Yes
<robUx4> that's the same problem on Linux/MacOS for all RIFF files
<Ingo> So the answer is: Yes the data after the cbSize field goes into the codec header?
<Ingo> Or No?
<Ingo> Or partially?
<robUx4> wel, the idea was to avoid that and put nothing (and give nothing)
<robUx4> hoping that the GUID would be enough
<Ingo> With nothing you can't initialize a decompressor.
<robUx4> well, it could initialize itself
<Ingo> Not FLAC, not Monkey's Audio, not Vorbis.
<robUx4> ok :/
<Ingo> MPEG Audio and PCM: yes
<robUx4> but it's completely OS independent
<robUx4> dependant (sorry)
<Ingo> Yes
<robUx4> so...
<Ingo> that is the exact problem
<robUx4> Tronic's version is better
<robUx4> for formats that don't need initialisation we need a string (or whatever) only
<robUx4> for the rest it can only be played on the OS it was created
<Ingo> For widely used formats we should specify a header, like FLAC, Monkey and Vorbis.
<robUx4> (unless the different codec uses the same struture to store their init data across various platforms)
<Ingo> (Is the Vorbis header still in the specs?)
<robUx4> Ingo: dunno
<Ingo> I proposed some months ago:
<Ingo> uint32 InfoSize,CommentSize,CodebooksSize;
<Ingo> uint8[InfoSize] Info;
<Ingo> uint8[CommentSize] Comment;
<Ingo> uint8 Codebooks[CodebooksSize];
<Ingo> Uhh, that was a mix between Java and C
<robUx4> for Vorbis ? or anything ?
<Ingo> For Vorbis.
<Ingo> For others we have to look.
<robUx4> OK, I don't know the header so why not
<robUx4> ok
<Ingo> That is the easiest way and it is also platform independent.
<robUx4> that means that some encoded files in MCF won't be playable on other systems
<Ingo> Yes
<robUx4> shit
<Ingo> But that is ok, as long as we make sure, that most files play.
<Ingo> Reaching 100% is an illusion.
<robUx4> so the current approach in the only possible : WE define the extra info structure for the known formats
<Ingo> Still I prefer a GUID.
<Ingo> Yes
<robUx4> the rest (RIFF related for ex) will likely be stuck to Windows
<Ingo> Yes
<robUx4> so we should encourage people to use the known formats for portability
<Ingo> Yes
<de_xt> i think this was my proposal too
<robUx4> (but still being able to use any Dshow stuff if they want to)
<de_xt> i just sent it to mcf-devel :)
<Ingo> Simply only write software that uses the proposed formats.
<robUx4> he he
<robUx4> we don't control the softwares
<Ingo> s/uses/creates/
<robUx4> ok
<robUx4> that's going to be harder to puch, compared to the current OGG
<Ingo> Why?
<robUx4> because it's a bit closed
<Ingo> It has no disadvantage over Ogg.
<robUx4> the good side is that we'll only be able to define these structures for open formats
<Ingo> Either the codec is known, then the multiplexer creates a open documented track.
<robUx4> so we'll help to push open formats for portability
<Ingo> Or it is unknown, which is the case for ogm all the time, then we simply have some unknown header content only usable on DirectShow, which is the case for ogm also.
<robUx4> no disavantage yes, but we don't encourage this use (DShow based approach)
<robUx4> oki
<robUx4> so you suggest removing RIFF and replace it with "unknown" ? or "DSHOW" ?
<robUx4> BTW, why do you think GUID is better in this case ?
<de_xt> rob: you got my message at mcf-devel? im not sure it ha been sent
<robUx4> BTW2, it's a pity that all this background information is not on the Format page
<robUx4> de_xt: yes
<Ingo> Because you don't have to register for non open formats.
<Ingo> Look at the MS fourcc.
<robUx4> if we keep the unknown you don't have to anywau
<robUx4> you're just platform dependant (likely)
<Ingo> People should register them, but they don't. There are duplicates, some are uppercase, some lowercase, in some players case is ignored, somewhere not and so on.
<robUx4> actually in that case the encoded data rely on the codec you'll use to decode it
<Ingo> With a GUID this can't happen.
<Ingo> You still must have a way to determine the content type of the stream.
<robUx4> yeah but the string is not like a FourCC
<Ingo> FOURCC is a 4 byte long stzring.
<robUx4> I get you
<Ingo> Tronics is a 16 byte (max) string
<de_xt> my proposal was: use format string for supportd formats, use GUID+codec header for unsupported ones
<Ingo> My proposal is:
<robUx4> if you use "unknown" you need a way to distinguish your format from others
<Ingo> Use a GUID everywhere.
<Ingo> Some GUIDs are known and the headers are documented
<de_xt> well you can use a GUID always of course.
<robUx4> but is it the same GUID as known by WIndows ?
<robUx4> actually IMO string=GUID
<Ingo> All the other have their private closed data.
<robUx4> so one or the other is the same for me
<robUx4> of course it's more convenient to use something existing
<Ingo> Well, the human readability limits the number of possibilities of the string.
<Ingo> And there are tools to create distinct GUIDs already.
<robUx4> yep
<robUx4> 16 ASCII strings is smaller than 12 bytes :)
<Ingo> With a string it is much more likely to have duplicates
<robUx4> (is it 12 bytes ?)
<de_xt> we can have both, too. format string + guid.
<Ingo> Well, assume 5 bits per byte
<ChristianHJW> de_xt : i am just reading your mail to mcf dev about that
<Ingo> I think we should use the string only for informational purposes.
<robUx4> same opinion here
<Ingo> Like showing in an explorer column or such.
<ChristianHJW> d_xt : i love your approach
<ChristianHJW> ingo, robux4 : you read that ?
<Ingo> So 16*5=80 bits = 8 bytes maximum.
<Ingo> Instead of 16 for a GUID.
<Ingo> Effective content.
<robUx4> ChristianHJW: ok, I'm going to read it :)
<de_xt> chris: is much like Ingo's one
<ChristianHJW> if its feasible i guess its the way to go
<ChristianHJW> Tronic will also be happy
<ChristianHJW> if the format is supported in MCF string its played that way
<ChristianHJW> if not its looking for GUID
<ChristianHJW> on other OS only supported formats can be played
<Ingo> ChristianHJW: you wanted to ask on gmane.org to put the mailing lists on the news server?
<ChristianHJW> havent done yet
<ChristianHJW> sorry
<robUx4> yeah you have a point here
<de_xt> well we can have a GUID always too. i just asid it isnt really needed
<Ingo> Well, keep in mind, that MPlayer is also able to use GUIDs.
<de_xt> for a supported format
<robUx4> using GUID for both known and unknown formats might lead to confusion
<Ingo> Perhaps you want to ask on #mplayer
<Ingo> Then use the string "Unknown" and fill in a GUID.
<Ingo> But for audio AND video, not only for audio as it is now.
<de_xt> yes of course
<Ingo> Ot better fill in the GUID whenever possible.
<robUx4> dunno
<robUx4> there should be an easy way to distinguish a portable (in the MCF sense) format from a non-portable
<de_xt> so we have three fields: string, guid and codec header. when string is used the others arent needed, but COULD be filled in. when string is "unknown" the others are being used
<Ingo> We need the codec header in any case.
<Ingo> For known formats it contains known fields.
* ChristianHJW slaps Tronic around a bit with a large trout
<ChristianHJW> Hey Lasse, wake up !!!!
<Ingo> And for unknown formats it contains unknown content.
<Ingo> No need to wake up. Everything is clear. Just go and implement. :-)
<de_xt> ok. i was thinking in the possibility to recreate it on the fly, if possible. if not, then just fill in
<Ingo> Is the current string syntax ok?
<de_xt> but we'll have to recreate it in linux, anyways
<de_xt> that's the problem
<ChristianHJW> guys, would you all agree that there is a lot of very precious input to MCF coming from de_xt ??
<ChristianHJW> we should consider
<ChristianHJW> promotoing him
<de_xt> well nothing compared to Ingo, that's for sure :)
<ChristianHJW> to being a core member of the MCF team
<ChristianHJW> sorry for being OT, but this had to be said
<robUx4> what is a core member ?
<Ingo> JMF uses a mime type string. The first part (audio, video, etc) is already defined by the track type.
<robUx4> do we need this hierarchy ?
<Ingo> Maybe we should adapt and limit the string to lowercase.
<de_xt> ingo: from what i saw, JMF also uses FOURCC for video?
<de_xt> i have the IBM MPEG4 for JMF here
<Ingo> Anyway. The string should be as easy as possible.
<Ingo> Put no data for parsing in it.
<Ingo> Instead of "AVI/Video" just "directshow"
<Ingo> I'm talking too much.
<de_xt> the same for both audio and video, then? and text even?
<Ingo> Yes
<Ingo> there's still the track type different.
<de_xt> you mean for unsupported formats, or all. not sure what was AVI/Video used for
<Ingo> Well, for supported formats use strings like:
<Ingo> vorbis, flac, monkeysaudio, mpeg1 and so on.
<Ingo> An unsupported format depends on the media framework it was created for.
<de_xt> ok. that makes sense of course.
<Ingo> For example. If the unsupported type was created with DirectShow, VfW, we have a subytpe GUID.
<Ingo> Then use
<Ingo> "directshow"
<Ingo> and put a subtype GUID into the codec header
<Ingo> (And otherwise don't use GUIDs)
<Ingo> When created on quicktime
<Ingo> Use
<Ingo> "quicktime"
<Ingo> and put a quicktime FOURCC into the codec header.
<Ingo> and so on.
<de_xt> and the user data i guess
<ChristianHJW> Hmmm
<de_xt> guid + user data
<Ingo> Yes that too.
<ChristianHJW> robux4 : you reading Steve ?
<ChristianHJW> what you think ?
<Ingo> It is basically, what we already have.
<Ingo> But the strings are bit too complicated at the moment.
<de_xt> it's the same i though. "directshow" = "unknown" in my example
<de_xt> yes of course there is no need to use AVI/Video and AVI/audio
<de_xt> and it does not make sense anyways, since it's not AVI, it's DS
<de_xt> but still i see a problem. the user data.
<de_xt> how are you supposed to generate the user data area from within linux?
<de_xt> in windows you can just copy it
<Ingo> For every string we have to specify a layout of the codec header.
<Ingo> In case of "directshow" it would look like
<Ingo> struct Header
<Ingo> {
<Ingo> GUID SubType;
<Ingo> . // Some fields of the AM_MEDIA_TYPE and VIDEOINFOHEADER here
<Ingo> BITMAPINFOHEADER Bla;
<Ingo> };
<Ingo> For example.
<de_xt> so we have to learn how this user data is arranged for every supported format. that's the hard part
<de_xt> for unsuported formats that's no problem of course
<Ingo> The good thing is, that "directshow" and "quicktime" is a framework.
<Ingo> So for all those this is 2 definitions.
<Ingo> For all other single formats, like flac, vorbis, etc
<Ingo> we have to specify what goes into the header.
<ChristianHJW> Hmmm .. sound like work
<Ingo> This ensures, that at least the known formats can be played on all platforms.
<Ingo> Didn't I say, that this is just the beginnig.
<ChristianHJW> so, whats coming next ?
<Ingo> - Decide how the string looks like (I vote for all lowercase and simpler. Have strings for the various frameworks and the core media types)
<Ingo> - Define the codec header for the core media types
<Ingo> - Then start the filter.
<Ingo> In this szenario the GUID is only used for the "directshow" subtype and a FOURCC for the "quicktime" subtype. And they are part of the codec header.
<Ingo> and not of the track specific part of the track entry.
<de_xt> i totally agree with this model. no problem from my side.
<de_xt> now it's Tronic who should accept it :)
<Ingo> Our god!
<de_xt> :
<de_xt> :)
<ChristianHJW> nope
<ChristianHJW> copying all of this into a thread
<ChristianHJW> to save it for afterworld
<de_xt> well we are a team. the most voted option should be the one used. point.
<ChristianHJW> maybe an important time documetn one day
<Ingo> I knew, that you object
<ChristianHJW> where is Steve ?
<de_xt> ingo: you talked to me? i don't object at all
<robUx4> away
<robUx4> back
<de_xt> hmm.. everyone dead... again
<robUx4> I'm alive :)
<de_xt> rob: do you agree with ingo's model?
<ChristianHJW> sorry .. editing the thread
<robUx4> I'm finishing to read :)
Hi folks we have a big decision to make and ask anybody with a coding and DirectShow background for help here.
Copied and pasted from Ingo and robux4 discussing about that :
<robUx4> Ingo: do you know if it's possible to play a stream in DShow without the extra informations (cbSize=0 or something like that) ?
<Ingo> Only PCM.
<robUx4> yeah ?
<Ingo> And uncompressed bitmaps.
<robUx4> it's absolutely required ?
<robUx4> have you ever tried ?
<Ingo> Well, downstream filter simply reject the connection.
<robUx4> Ingo: are you sure about that ?
<Ingo> Yes
<robUx4> Ingo: :-(
<robUx4> that's really bad
<Ingo> What did you expect. What media type do you want to play?
<robUx4> because that means we need to store codec headers for all OSes who probably have incompatible systems for that
<robUx4> ANY media type
<Ingo> I know. That is the point.
<Ingo> Determining whether to use GUID or string is only the very beginning.
<robUx4> you put the correct GUID (in a bigger structure) and then set the extra information corresponding to the codec to 0 size
<ChristianHJW> oh no
<robUx4> ChristianHJW: yes ..
<ChristianHJW> dont tell me there are more probs to be expected ?
<Ingo> No there arent't
<Ingo> At least not than I expected.
<Ingo> Can't speak for the others.
<Ing<ChristianHJW> you said teh question GUID or string is only the beginning
<ChristianHJW> so i thought there are more probs on the way
<Ingo> Of course.
<Ingo> Lets assume we have decided about that GUID question.
<Ingo> Now a codec needs a header.
<Ingo> For one time initialization data.
<Ingo> Unfortunately this data on Windows is unknown.
<robUx4> I don't follow you
<Ingo> I meant the format of it.
<robUx4> the format of the extra info ?
<Ingo> Do you want to put the private data of the WAVEFORMATEX (after the cbSize field) into the codec header?
<robUx4> (like the extra data in MP3WAVEFORMAT compared to WAVEFORMATEX)
<Ingo> For example.
<robUx4> ok, these data
<Ingo> MP3 is a special case here, because you can extract the fields from the frame data itself.
<Ingo> But usually you can't.
<robUx4> as long as you know the structure
<robUx4> but using another codec is the same, with an unknown structure (only to the codec)
<robUx4> (only the codec KNOWS)
<Ingo> Yes
<robUx4> that's the same problem on Linux/MacOS for all RIFF files
<Ingo> So the answer is: Yes the data after the cbSize field goes into the codec header?
<Ingo> Or No?
<Ingo> Or partially?
<robUx4> wel, the idea was to avoid that and put nothing (and give nothing)
<robUx4> hoping that the GUID would be enough
<Ingo> With nothing you can't initialize a decompressor.
<robUx4> well, it could initialize itself
<Ingo> Not FLAC, not Monkey's Audio, not Vorbis.
<robUx4> ok :/
<Ingo> MPEG Audio and PCM: yes
<robUx4> but it's completely OS independent
<robUx4> dependant (sorry)
<Ingo> Yes
<robUx4> so...
<Ingo> that is the exact problem
<robUx4> Tronic's version is better
<robUx4> for formats that don't need initialisation we need a string (or whatever) only
<robUx4> for the rest it can only be played on the OS it was created
<Ingo> For widely used formats we should specify a header, like FLAC, Monkey and Vorbis.
<robUx4> (unless the different codec uses the same struture to store their init data across various platforms)
<Ingo> (Is the Vorbis header still in the specs?)
<robUx4> Ingo: dunno
<Ingo> I proposed some months ago:
<Ingo> uint32 InfoSize,CommentSize,CodebooksSize;
<Ingo> uint8[InfoSize] Info;
<Ingo> uint8[CommentSize] Comment;
<Ingo> uint8 Codebooks[CodebooksSize];
<Ingo> Uhh, that was a mix between Java and C
<robUx4> for Vorbis ? or anything ?
<Ingo> For Vorbis.
<Ingo> For others we have to look.
<robUx4> OK, I don't know the header so why not
<robUx4> ok
<Ingo> That is the easiest way and it is also platform independent.
<robUx4> that means that some encoded files in MCF won't be playable on other systems
<Ingo> Yes
<robUx4> shit
<Ingo> But that is ok, as long as we make sure, that most files play.
<Ingo> Reaching 100% is an illusion.
<robUx4> so the current approach in the only possible : WE define the extra info structure for the known formats
<Ingo> Still I prefer a GUID.
<Ingo> Yes
<robUx4> the rest (RIFF related for ex) will likely be stuck to Windows
<Ingo> Yes
<robUx4> so we should encourage people to use the known formats for portability
<Ingo> Yes
<de_xt> i think this was my proposal too
<robUx4> (but still being able to use any Dshow stuff if they want to)
<de_xt> i just sent it to mcf-devel :)
<Ingo> Simply only write software that uses the proposed formats.
<robUx4> he he
<robUx4> we don't control the softwares
<Ingo> s/uses/creates/
<robUx4> ok
<robUx4> that's going to be harder to puch, compared to the current OGG
<Ingo> Why?
<robUx4> because it's a bit closed
<Ingo> It has no disadvantage over Ogg.
<robUx4> the good side is that we'll only be able to define these structures for open formats
<Ingo> Either the codec is known, then the multiplexer creates a open documented track.
<robUx4> so we'll help to push open formats for portability
<Ingo> Or it is unknown, which is the case for ogm all the time, then we simply have some unknown header content only usable on DirectShow, which is the case for ogm also.
<robUx4> no disavantage yes, but we don't encourage this use (DShow based approach)
<robUx4> oki
<robUx4> so you suggest removing RIFF and replace it with "unknown" ? or "DSHOW" ?
<robUx4> BTW, why do you think GUID is better in this case ?
<de_xt> rob: you got my message at mcf-devel? im not sure it ha been sent
<robUx4> BTW2, it's a pity that all this background information is not on the Format page
<robUx4> de_xt: yes
<Ingo> Because you don't have to register for non open formats.
<Ingo> Look at the MS fourcc.
<robUx4> if we keep the unknown you don't have to anywau
<robUx4> you're just platform dependant (likely)
<Ingo> People should register them, but they don't. There are duplicates, some are uppercase, some lowercase, in some players case is ignored, somewhere not and so on.
<robUx4> actually in that case the encoded data rely on the codec you'll use to decode it
<Ingo> With a GUID this can't happen.
<Ingo> You still must have a way to determine the content type of the stream.
<robUx4> yeah but the string is not like a FourCC
<Ingo> FOURCC is a 4 byte long stzring.
<robUx4> I get you
<Ingo> Tronics is a 16 byte (max) string
<de_xt> my proposal was: use format string for supportd formats, use GUID+codec header for unsupported ones
<Ingo> My proposal is:
<robUx4> if you use "unknown" you need a way to distinguish your format from others
<Ingo> Use a GUID everywhere.
<Ingo> Some GUIDs are known and the headers are documented
<de_xt> well you can use a GUID always of course.
<robUx4> but is it the same GUID as known by WIndows ?
<robUx4> actually IMO string=GUID
<Ingo> All the other have their private closed data.
<robUx4> so one or the other is the same for me
<robUx4> of course it's more convenient to use something existing
<Ingo> Well, the human readability limits the number of possibilities of the string.
<Ingo> And there are tools to create distinct GUIDs already.
<robUx4> yep
<robUx4> 16 ASCII strings is smaller than 12 bytes :)
<Ingo> With a string it is much more likely to have duplicates
<robUx4> (is it 12 bytes ?)
<de_xt> we can have both, too. format string + guid.
<Ingo> Well, assume 5 bits per byte
<ChristianHJW> de_xt : i am just reading your mail to mcf dev about that
<Ingo> I think we should use the string only for informational purposes.
<robUx4> same opinion here
<Ingo> Like showing in an explorer column or such.
<ChristianHJW> d_xt : i love your approach
<ChristianHJW> ingo, robux4 : you read that ?
<Ingo> So 16*5=80 bits = 8 bytes maximum.
<Ingo> Instead of 16 for a GUID.
<Ingo> Effective content.
<robUx4> ChristianHJW: ok, I'm going to read it :)
<de_xt> chris: is much like Ingo's one
<ChristianHJW> if its feasible i guess its the way to go
<ChristianHJW> Tronic will also be happy
<ChristianHJW> if the format is supported in MCF string its played that way
<ChristianHJW> if not its looking for GUID
<ChristianHJW> on other OS only supported formats can be played
<Ingo> ChristianHJW: you wanted to ask on gmane.org to put the mailing lists on the news server?
<ChristianHJW> havent done yet
<ChristianHJW> sorry
<robUx4> yeah you have a point here
<de_xt> well we can have a GUID always too. i just asid it isnt really needed
<Ingo> Well, keep in mind, that MPlayer is also able to use GUIDs.
<de_xt> for a supported format
<robUx4> using GUID for both known and unknown formats might lead to confusion
<Ingo> Perhaps you want to ask on #mplayer
<Ingo> Then use the string "Unknown" and fill in a GUID.
<Ingo> But for audio AND video, not only for audio as it is now.
<de_xt> yes of course
<Ingo> Ot better fill in the GUID whenever possible.
<robUx4> dunno
<robUx4> there should be an easy way to distinguish a portable (in the MCF sense) format from a non-portable
<de_xt> so we have three fields: string, guid and codec header. when string is used the others arent needed, but COULD be filled in. when string is "unknown" the others are being used
<Ingo> We need the codec header in any case.
<Ingo> For known formats it contains known fields.
* ChristianHJW slaps Tronic around a bit with a large trout
<ChristianHJW> Hey Lasse, wake up !!!!
<Ingo> And for unknown formats it contains unknown content.
<Ingo> No need to wake up. Everything is clear. Just go and implement. :-)
<de_xt> ok. i was thinking in the possibility to recreate it on the fly, if possible. if not, then just fill in
<Ingo> Is the current string syntax ok?
<de_xt> but we'll have to recreate it in linux, anyways
<de_xt> that's the problem
<ChristianHJW> guys, would you all agree that there is a lot of very precious input to MCF coming from de_xt ??
<ChristianHJW> we should consider
<ChristianHJW> promotoing him
<de_xt> well nothing compared to Ingo, that's for sure :)
<ChristianHJW> to being a core member of the MCF team
<ChristianHJW> sorry for being OT, but this had to be said
<robUx4> what is a core member ?
<Ingo> JMF uses a mime type string. The first part (audio, video, etc) is already defined by the track type.
<robUx4> do we need this hierarchy ?
<Ingo> Maybe we should adapt and limit the string to lowercase.
<de_xt> ingo: from what i saw, JMF also uses FOURCC for video?
<de_xt> i have the IBM MPEG4 for JMF here
<Ingo> Anyway. The string should be as easy as possible.
<Ingo> Put no data for parsing in it.
<Ingo> Instead of "AVI/Video" just "directshow"
<Ingo> I'm talking too much.
<de_xt> the same for both audio and video, then? and text even?
<Ingo> Yes
<Ingo> there's still the track type different.
<de_xt> you mean for unsupported formats, or all. not sure what was AVI/Video used for
<Ingo> Well, for supported formats use strings like:
<Ingo> vorbis, flac, monkeysaudio, mpeg1 and so on.
<Ingo> An unsupported format depends on the media framework it was created for.
<de_xt> ok. that makes sense of course.
<Ingo> For example. If the unsupported type was created with DirectShow, VfW, we have a subytpe GUID.
<Ingo> Then use
<Ingo> "directshow"
<Ingo> and put a subtype GUID into the codec header
<Ingo> (And otherwise don't use GUIDs)
<Ingo> When created on quicktime
<Ingo> Use
<Ingo> "quicktime"
<Ingo> and put a quicktime FOURCC into the codec header.
<Ingo> and so on.
<de_xt> and the user data i guess
<ChristianHJW> Hmmm
<de_xt> guid + user data
<Ingo> Yes that too.
<ChristianHJW> robux4 : you reading Steve ?
<ChristianHJW> what you think ?
<Ingo> It is basically, what we already have.
<Ingo> But the strings are bit too complicated at the moment.
<de_xt> it's the same i though. "directshow" = "unknown" in my example
<de_xt> yes of course there is no need to use AVI/Video and AVI/audio
<de_xt> and it does not make sense anyways, since it's not AVI, it's DS
<de_xt> but still i see a problem. the user data.
<de_xt> how are you supposed to generate the user data area from within linux?
<de_xt> in windows you can just copy it
<Ingo> For every string we have to specify a layout of the codec header.
<Ingo> In case of "directshow" it would look like
<Ingo> struct Header
<Ingo> {
<Ingo> GUID SubType;
<Ingo> . // Some fields of the AM_MEDIA_TYPE and VIDEOINFOHEADER here
<Ingo> BITMAPINFOHEADER Bla;
<Ingo> };
<Ingo> For example.
<de_xt> so we have to learn how this user data is arranged for every supported format. that's the hard part
<de_xt> for unsuported formats that's no problem of course
<Ingo> The good thing is, that "directshow" and "quicktime" is a framework.
<Ingo> So for all those this is 2 definitions.
<Ingo> For all other single formats, like flac, vorbis, etc
<Ingo> we have to specify what goes into the header.
<ChristianHJW> Hmmm .. sound like work
<Ingo> This ensures, that at least the known formats can be played on all platforms.
<Ingo> Didn't I say, that this is just the beginnig.
<ChristianHJW> so, whats coming next ?
<Ingo> - Decide how the string looks like (I vote for all lowercase and simpler. Have strings for the various frameworks and the core media types)
<Ingo> - Define the codec header for the core media types
<Ingo> - Then start the filter.
<Ingo> In this szenario the GUID is only used for the "directshow" subtype and a FOURCC for the "quicktime" subtype. And they are part of the codec header.
<Ingo> and not of the track specific part of the track entry.
<de_xt> i totally agree with this model. no problem from my side.
<de_xt> now it's Tronic who should accept it :)
<Ingo> Our god!
<de_xt> :
<de_xt> :)
<ChristianHJW> nope
<ChristianHJW> copying all of this into a thread
<ChristianHJW> to save it for afterworld
<de_xt> well we are a team. the most voted option should be the one used. point.
<ChristianHJW> maybe an important time documetn one day
<Ingo> I knew, that you object
<ChristianHJW> where is Steve ?
<de_xt> ingo: you talked to me? i don't object at all
<robUx4> away
<robUx4> back
<de_xt> hmm.. everyone dead... again
<robUx4> I'm alive :)
<de_xt> rob: do you agree with ingo's model?
<ChristianHJW> sorry .. editing the thread
<robUx4> I'm finishing to read :)