View Full Version : @stux : Question about all the existing 3ivX video codecs
ChristianHJW
28th February 2003, 14:08
Hi Stux, hi you 3ivX experts here,
while we are aiming to complete our list of supported codecs for matrosk a i was wondering :
1. Are there any 3ivX codecs that are not available as VfW codecs ?
2. Do they all have the same FourCC codes ? If not, can you please lsit them here ?
3. Do any of the more modern versions of the codec require another codec interface than VfW, or could any additional functionalities be accomplished that way ?
Thanks for answering
Christian
P.S. No need to hurry, take your time answering
Stux
1st March 2003, 06:27
I'm not sure I understand the question :)
The VfW codec should *ONLY* be used for encoding. The DirectShow decoder is more powerful
BUT there is currently no DirectShow (or other) encoder. But when/if this changes, it is more than possible it will be more capable.
But this should not matter to a well-designed media format ;)
The current in circulation fourccs for 3ivx are
3IV1 3ivx Delta 3.x
3IV2 3ivx Delta 4.x
3IVD 3ivx Delta 4.x
The current D4 (4.0.3) codec suite for Windows includes
QuickTime codec
VfW codec
DirectShow decoder
DirectShow demuxer
DirectShow audio decoder
There was a Delta 3 DMO decoder, but this has been withdrawn.
ChristianHJW
1st March 2003, 10:11
Originally posted by Stux I'm not sure I understand the question :) . The VfW codec should *ONLY* be used for encoding. The DirectShow decoder is more powerful
Sorry, i should have been more precise, i ment are there any Linux or BeOS encoders out there, so that we could neither use our VfW/AVI nor the QT compatibility mode, but had to define a specific codec identifier for your codec(s).
BUT there is currently no DirectShow (or other) encoder. But when/if this changes, it is more than possible it will be more capable. But this should not matter to a well-designed media format ;)
Dont worry, matroska is quite well-designed we hope :D, so for sure we will be able to support your codec fine. It seems we can simply use our 'compatibility modes', for both Quicktime and VfW/AVI. In these modes our matroska codec ID is set to
'V_MS/VFW/FOURCC'
and
'V_QT/FOURCC'
and then the codec relevant data are put into the codec private data field ( KaxCodecPrivateData ). In case of AVI this is the BITMAPINFOHEADER structure, in case of QT we dont know yet :D .. we just hope they have such .. lol .
On Linux it is possible to create those files, but its pain in the a.. to do, so we decided to give Linux people a native matroska codec ID for all existing Linux based encoders, to help the format getting accepted.
The current in circulation fourccs for 3ivx are
3IV1 3ivx Delta 3.x
3IV2 3ivx Delta 4.x
3IVD 3ivx Delta 4.x
The current D4 (4.0.3) codec suite for Windows includes
QuickTime codec
VfW codec
DirectShow decoder
DirectShow demuxer
DirectShow audio decoder
Dohh !! I had no idea you have an audio encoder also ? Is this an ACM codec ? Can it be used in AVI also or only MOV ?
Thanks for listing the FourCC, but as pointed out above we dont need to know them to be able to support your codecs, as they are part of the data contained in BITMAPINFOHEADER anyway.
There was a Delta 3 DMO decoder, but this has been withdrawn. [/B]
Whats DMO ?
BTW, if we ever get a new, open standard codec API to be released, be it UCI or any other working solution, and you guys would decide to support it, you sure get your own codec ID from us :D :D !
Thanks for your help
Christian
Stux
2nd March 2003, 12:08
We do not currently publish an audio encoder. The audio decoder is for AAC audio. It is a DirectShow decoder.
A DMO is a Direct Media Object, its another type of codec interface. Easier to write than a DirectShow module, but not as powerful.
Now, regards your VfW/QT stream handling. This is where you have me confused. I've done a fair bit of work with mov, mp4 and avi files... and as far as I can tell, there is no reason to have anything except a video stream... it gets tricky when you are trying to store codec ids which are not fourccs, but QT and VfW both use compatible fourccs
The QuickTime video stream has width/height and timebase information...
and so does the AVI stream
they both also have extradata, which often contains out of band, decoder configuration information.
One can be transcoded to the other almost trivially, because essentially they are totally compatible.
So, why would you have different methods for handling them in matroska? All you need to do is store the relevant data (timebase/fps width/height and codec/vendor fourccs... and then the Extra Data...
Essentially, QuickTime codecs are capable of decoding AVI video streams... so I'd suggest not worrying about how to define QT storage, as you can store QT data in AVI streams...
If you decide to investigate the QT fileformat, the interesting part is the 'stsd' atom
...
If you are seriously concerned about how to store QT video streams in matroska, then I'm wondering if you've dealt with the variable duration per frame possibility of the QT file format ;)
Stux
2nd March 2003, 12:13
Oh, one more thing, Apple maps WAVE acm codec ids to a fourcc by prepending 'ms' to the ID...
ChristianHJW
2nd March 2003, 17:57
Originally posted by Stux We do not currently publish an audio encoder. The audio decoder is for AAC audio. It is a DirectShow decoder. ... sorry, i should have read your post again before typing ..
A DMO is a Direct Media Object, its another type of codec interface. Easier to write than a DirectShow module, but not as powerful. Never heard of that before. Are there any codecs available as DMOs you know of ? Do we have to support that at all ?
Now, regards your VfW/QT stream handling. This is where you have me confused. I've done a fair bit of work with mov, mp4 and avi files... and as far as I can tell, there is no reason to have anything except a video stream... it gets tricky when you are trying to store codec ids which are not fourccs, but QT and VfW both use compatible fourccs. The QuickTime video stream has width/height and timebase information... and so does the AVI stream
they both also have extradata, which often contains out of band, decoder configuration information.
One can be transcoded to the other almost trivially, because essentially they are totally compatible.
So, why would you have different methods for handling them in matroska? All you need to do is store the relevant data (timebase/fps width/height and codec/vendor fourccs... and then the Extra Data...
Dont misunderstand me, we dont need the data contained in BITMAPINFOHEADER to play the file, not at all. Matroska has native elements for all necessary information like width/height, colour space, bitdepth, etc. . We decided to keep these data in the codec private data to allow the user to convert the matroska video/audio streams easily into an AVI or MOV file, if they were muxed from an AVI or a MOV, and without the muxing app having to know anything about the codec itself or the codec being present on the system where the matroska file is being edited.
Essentially, QuickTime codecs are capable of decoding AVI video streams... so I'd suggest not worrying about how to define QT storage, as you can store QT data in AVI streams...
As said above, its not the decoding/playing part we are worried about, the data that are in the matroska elements are absolutely sufficient for that, maybe with the exception of some codecs that are breaking AVI specs like HuffYuv, storing its Huffman tables in the AVI comment fields.
If you decide to investigate the QT fileformat, the interesting part is the 'stsd' atom
As we found out the 'atoms' in MP4/MOV allow to define new functionalities in MPEG4 files, like what menno, the FAAD/FAAC developer, is doing now with adding APE and ID3V2 tags to MP4 AAC files. EBML is playing this part in our container, and we dont have to fear to be accused of patent violation from MPEG-LA as we are using XML as parent system ;) ...
If you are seriously concerned about how to store QT video streams in matroska, then I'm wondering if you've dealt with the variable duration per frame possibility of the QT file format ;)
matroska doesnt know what a framerate is, all data blocks have a timestamp, so yes, we can deal with variable framerate video streams :) !
Thanks for your answers, they helped me a lot.
bond
2nd March 2003, 18:39
Originally posted by ChristianHJW
Are there any codecs available as DMOs you know of ? Do we have to support that at all ?WMV9
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.