[Mono-dev] Mono.Media for GSOC
andreas.faerber at web.de
Tue Apr 8 17:02:19 EDT 2008
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.
FramePositioningControl fpc = (FramePositioningControl)
JMF's codec support is documented here:
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,
More information about the Mono-devel-list