Objects vs File Formats (Messages)

I'm really happy to see someone is working on this, 
as I think media container formats are used to leverage 
the Apple and Windows platform on people who have on need to
work with media, not inadequacy in their software. 

My name is Kiernan Holland, been around on the net for years.. 
More recent interests include Blender, the now open source 3D 
package which is the first open sourced 3D app to be complete enough 
to be used commercially for animation work. I've also been working 
in some degree on OpenEMed a implementation of the OMG's PIDS 
standard which is a abstraction of patient identifiers used in 
healthcare (it identifies patients not with numbers but with unique 
indentifiers such as eye color, weight, telephone number, address, 
and diassociates this from medical information {which is a 
requirement for HIPPA compliance, but is also common sense}. 
OpenEMed is not complete, its based on associate arrays with typ 
any's for the storage of patient information and will fail 
ultimately because it seeks not to detail what a patient identifier 
contains and what are unique identifiers.. ITs dependent somewhat on 
the HL7 format which is heavily backed by Microsoft.. I'm seeing 
similar mistakes made elsewhere, anywhere XML is. 


What is XML really than a creative use of a lexical analyzer and a 
tag-based language like HTML. Its not an object meta-format, it does 
not maintain data internally with methods, it relies on a agreement 
between developers or handling libraries.. If the objects are open 
sourced but detailed precisely, what is the need for developer 
agreements (sense ones such as Microsoft could break it as needed).. 

Really the format should be an object based format, and the 
designers should agree at the time of creation of the format on how 
this format should scale, and the format should be abstracted enough 
that its not seen as a data format, but a object format.. The data 
format need only be XCF with some internal representation that is 
determined when implementing the object libraries, which will be 
completely open sourced.. If they are not, this media format will 
not fly.. If the source code contributing to the data format is not 
commented and outlined clearly, if all the developers haven't 
thought it through, this media format will not fly...     

Here are some ideas about how to arrange things:

Movie -> Sequence of Frames, Objects that describe or add higher 
level functionality (such as compression methods, audio tracks, etc)

Frame -> Layers of Images (each representing some kind of data, be 
it rgb, z-buffer, alpha, float, arbitrary extra data). 

Image -> arbitrary picture-sample format, not an array of pixels 
with uniform spacing that doesn't allow for sparse random sampling, 
vector based images, etc.. (read Alvy Ray Smith's paper on a "Pixel 
is not a little Square"). 

Audio Track is like a movie in a way, it contains an array of audio 
samples, movie is an array of frames.. 

Streaming requires data to be in clumps of time sync'd pieces, 
right, this is just a form of the way objects pass messages, 
its not a data format stored in a particular way to be made 
streamable its not a library that specializes in streaming of 
audio/video.. If objects are involved, when you ask for a 
movie over the Internet, a media object should be smart enough to 
hand itself over in the form of time-sync'd clumps of picture and 
audio data, it need only to say its of a particular format, this 
obliterates the need for MIME types, the client and server need only 
to stream an object, the object itself should only have to negotiate 
with itself (on the other end) about which codecs are needed and how 
to stream the data.. Its a mistake to load this functionality into a 
library, but saying that such object functionality does not exist 
and we use libraries takes us back to C and the days of message 
format dependency.. And the older a message format becomes, the less 
people know about it.. The more people have to know about it, and 
the more complex working with media becomes.. The data should 
contain the methods with it that know best how to handle it.. 
How methods are executed though may present a problem as there 
is no consensus on this.. 

The way things are isn't the best way things can be, its just the 
way they were first implemented.. There is always a better way of 
doing things.. 

We need to be thinking like this, not about what the message format 
looks like, because message formats don't maintain themselves.. 
Objects do.. Therefore the revolutionary media formats should 
be all encompassing object relationships, with an underlying storage 
format.. So that the applications need not implement X number of 
libraries and know every compression method under the sun. In no way 
should a movie program have to know explicitly if a movie file 
format is MPEG or MJPEG. Whatif things change, do we change 
everbodies software or do we change how these objects store and 
retrieve the data? And if files were saved out under a old format, 
should our programs know how to load that format in addition to the 
new one?


I would also be careful who you deal with when coming up with these 
formats, there are industry evangelists, working for Microsoft and 
such, whose job it is to sabotage standards and formats anyway they 
can.. XML is their favorite data format because its integrity cannot 
be enforced because it contains no methods.. Its a prime candidate 
for future sabotage.. Microsoft uses language sabotage in many 
forms, in the language we use to communicate about the programs we 
use, in the languages we program in, in the formats we use, who we 
talk to, etc..  They can make lots of money alone just by changing 
the semantics of the language. And XML is changeable, a object based 
language that is well abstracted and designed for 
extensibility/scalability by identifying relationships between 
information, not on what it looks like or how its interpretted but 
what it is like how it can be reused and puting all of that 
knowledge about how best to implement the information management 
needs to be close to the information, this is an object.

Objects are data maintained with methods in a way that programs 
need not be completely concerned, at least, with the preciseness of 
how data is stored, the programs should only have to understand 
the basics of what an object is.. If its a movie, we should only 
assume the movie can have sound, and that it has a sequence of 
frames. We can assume it lasts some amount of time, it may know 
internally how many actual frames there are..

When we think like this, its called design, we need to detail out 
how much the programmer should actually have to know about movies, 
audio, and other media formats, to totally abstract the formats. 
Nobody should have to know about MPEG in any way unless one needs to 
maintain the concept of MPEG. About the only things that 
should  be abstracted of MPEG are the concepts that prove useful.. 
Object interfacing also allows one to extract more information from 
an object as their needs require. 

So a novice may want just to deal with movies with sequences of 
images, but an expert may need to access motion vectors of the movie 
if it is a MPEG movie. To allow movie editors and 
audio editors, and movie utilities, there needs to be several 
well abstracted layers to the media formats, all of these layers 
need to be objects. There is some question as to what language the 
objects need to be implemented in. I don't know how to answer that 
one. Certainly though should be possible to abstract the interface 
of the language from the objects that the media represents for 
each language, but at some level internally to the media libraries 
it needs to be object oriented and have a level of polymorphism 
so as to not care what format data is stored or retrieved in.. 
At the very least if something is not readable, some description 
of why it isn't should be given, but the movie editor designer 
should not have to deal with the error in relation to their 
editor by knowing something about MPEG.

I think for programmers it seems that complexity is acceptable, but 
which would you rather be doing, making movies or knowing the 
compexities of movie compression. The less there is abstraction, 
the less there are professionals and everyone becomes system 
administrators at some level (making assumptions about things they 
don't know how to manage, as a result of bugs in their code or 
others).  By abstracting things ina meaningful way to people in 
general, we are making life easier for ourselves because its the 
less time we have to waste expressing concepts to people that they 
are not interested in, and they are not experts in.. This is the 
purpose for using objects and interface abstractions..

The more we bring people into unneeded complexity the more the world 
will become hard to deal with, what goes around comes around.. 
Legacy systems design depends on static message formats, 
if you remove that and make the message formats clear and 
maintainable by methods, and open sourced, you lock out legacy 
systems and companies who make money off of changing the syntax and 
semantics (e.g. Microsoft tactics).. 
 

Now I would be happy to help out in determining the abstractions 
for these media formats, I don't know much about movie compression 
or audio compression, just basics.. But I know artists and 
programmers, and I know what a pain it is to deal with uneeded 
complexities. I think in abstractions and my ideas are limited by 
the lack of abstraction in computer software design, its why 
I feel it could be better.. And though I would not be as good as you 
at complex math, I am good at design logical associations and ideas 
about interfacing. I am very good at seeing patterns in usage.

 


Sign up today for your Free E-mail at: http://www.canoe.ca/CanoeMail 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf