Sample Designs

[spsa]

I am proposing the initial vertical services for the media engine so there you go. They are meant to be implemented as ServiceMBeans:

MediaSensorFactory: Every possible input of audio and video is encapsulated in this one. The In practical terms it is used to instantiate a Media object that captures data real-time right-now.

Media: The media itself, ( i.e a video or audio file location /metadata ). Some plugins are might be registered on this media and alongside an aditional information stream ( ex pitch if a pitch detector plug-in is registered for an audio media).

MediaPublisherFactory
Uses a Media object to spawn the corresponding MediaPublisher.

MediaPublisher: Controls the presentation of a single media( registers it with a protocol server ( html , whatever ) , file/awt component ( ? )

MediaPluginRegistry: A global registry of all post-decompresion / effect plug-ins.

MediaPlugin: An effect plugin


JMF is going to be used for most of the above. Capturing requires a native version of JMF , which comes with its native libraries. We need to find a proper way to incorporate native libraries into jboss ( ???? !?!? ) or decide that a proper installation of jmf is needed.

Please let me know on any critique on the above. Soon I will create a TO DO list at sourceforge for the above as well.

SpSa

[greenman]

> I am proposing the initial vertical services for the
> media engine so there you go. They are meant to be
> implemented as ServiceMBeans:
<snip>

There will need to be some sort of mechanism for handling transcodings as well. This would be some sort of registry again, I suspect.

> JMF is going to be used for most of the above.
> Capturing requires a native version of JMF , which
> comes with its native libraries. We need to find a
> proper way to incorporate native libraries into jboss
> ( ???? !?!? ) or decide that a proper installation of
> jmf is needed.

Given that the JMF 'power packs' are only available for a limited number of platforms, AFAIK, we probably shouldn't rely upon them architecturally, but as a quick and easy of making certain media types / conversions available.

Limited linear audio support, for example could be achieved with javax.sound.

I hadn't, to this point, considered on-the-fly capture in this scenario, imagining instead that most people would have been using persisted media chunks. How do you see its major application? For serving up live broadcasts etc.?

[spsa]

Well ,

For capturing what I was thinking was both live broadcasting and mobile devices. Let's say you have a small device somewhere with limited storage. You can then capture stuff and send it back to your main server for storing.

One other plausible scenario is the following: You have an array of computer doing real time face detection. The face images you get are then send back to a main server for recognition.

SpSa

[spsa]

Well ,

For capturing what I was thinking was both live broadcasting and mobile devices. Let's say you have a small device somewhere with limited storage. You can then capture stuff and send it back to your main server for storing.

One other plausible scenario is the following: You have an array of computer doing real time face detection. The face images you get are then send back to a main server for recognition.

SpSa