Email address no longer exists
there is a problem using this :
imagine the following case : i'm developing a new revolutionary codec (as usual ) since the type of my codec is not in ML_COMPRESSION_* types the openML implementation on my computer will return ML_COMPRESSION_UNKNOWN preventing further processing.....
int32 <=> FourCC used in avi and quicktime... why not use the same mechanism? a device should return ML_COMPRESSION_UNKNOWN only if there was a problem reading the compression format (ie a bad avi file or a bad quicktime file if I make a openML compliant avi reader/writer or an openML compliant mov writer/reader ) if a device is not able to "understand" the compression format it should return the compression code as is, allowing another device that "understand" this to do the work (in this case decompress the stream).
you could manage to build a userrange of values and a standart range of values. but please [B]don't re-invent the wheel [\B]: fourcc is used in almost all video system i know.....