[Mono-dev] Mono.Media for GSOC

[Andreas Färber]

Hi,

Am 07.04.2008 um 20:51 schrieb Miguel de Icaza:
>> As pointed out previously by someone, Sun's Java Media Framework is
>> not the best point to model from. It is much too complicated and
>> inefficient to use, and can be considered mostly dead (we had to use
>> it at university for a project, but Sun hasn't offered new releases
>> for years). The open source MFJ replacement aimed to be binary
>> compatible and didn't seem to tackle the design issues.
>> (our use case was video cut detection, i.e. navigating to frames,
>> capturing, analyzing and displaying them)
>
> And that is the point, this is not a replacement for something like
> GStreamer, the idea is to provide stuff like midi control (input,
> playback, control) and not the other layers that people typically
> associate with "Media".
>
> And that is why you failed using it, its for something different.

No, you're most certainly wrong there. JMF was Sun's attempt of an  
integrated, general-purpose audio+video codec/streaming/playback/ 
control/what-not framework. It is not for something different, and we  
therefore didn't fail either - its API was just impo "ugly" to use and  
thus not recommendable and we have mostly turned to C++ since then.

JMF is no scientific research framework, and I hope we can agree that  
it shouldn't take a scientist to retrieve, for instance, the length of  
a media clip! With JMF it almost does, since it was at least a three- 
step process iirc. And for virtually every thinkable functionality you  
need to pass a string in order to retrieve and cast a controller  
object, one for navigating, one for getting at the actual decoded data  
etc. pp. Most of that is part of a regular use case - it you want to  
display the length of your input, you will need to retrieve it  
somehow, and navigation is obviously a common 'control' scenario for  
video players. Building a specialized AWT+JMF player was pretty much  
what we did.

<snip>
FramePositioningControl fpc = (FramePositioningControl)  
player.getControl("javax.media.control.FramePositioningControl");
fpc.mapTimeToFrame(player.getDuration());
</snip>

JMF's codec support is documented here:
http://java.sun.com/products/java-media/jmf/2.1.1/formats.html
MIDI is only one among the list of its supported media formats, and it  
was not even supported outside Windows and Solaris.

I am fine with if you intend Mono.Media to become a nice MIDI or  
whatever media framework, but then that has little to do with JMF,  
especially in terms of architecture. So in fact you make exactly my  
point, which was:

Mono.Media shouldn't be derived from JMF.

I never mentioned GStreamer or anything else, so I'm arguing neither  
for nor against that library.
You however have already had two independent JMF users advising  
against any Mono.Media API derivation from JMF, while exactly no-one  
has stepped up saying the JMF API were great, so please don't keep  
blindly referring people to JMF, and rather discuss architecture and  
contents of the new Mono.Media library instead.

As a constructive start, I kindly request for a media object to have a  
property Length (or Duration) returning a TimeSpan, if calculatable,  
and where applicable, a FrameCount integer property, so that it can be  
retrieved in a convenient way by frontends.

Thanks for listening,

Andreas