[gst-devel] What projects are underway?

[Dan Dennedy]

Ronald Bultje wrote:

> Hi Dan and others,
> 
> I'd like a small comment here.
> I have double feelings about this quicktime lib from Adam.
> On the one hand, Adam is the only one to have such a lib - so it would be
> logical to implement it.
> But in my work for the MJPEG-tools I've noticed that most people there have
> a certain hate against this quicktime lib (and also broadcast in general
> but that's another story).

Well, I am not over pleased either with the Heroine Warrior approach 
either, which is just one reason why I have not contributed. However, I 
do appreciate Adam's effort and willingness to open source.

> 
> On 2001.04.19 05:44:03 +0200 Dan Dennedy wrote:
> 
>> First of all, I want to comment on the post from 3ivx.com. Please
>> consider
>> using the Quicktime 4 Linux implementation from
>> http://www.heroinewarrior.com/quicktime.php3 for your quicktime parsers.
>> The reason is because this is already a fairly mature implementation.
>> More
>> specific reasons will become clear below.
> 
> 
> Thing is that Adam's quicktime lib is a poor implementation, which is a lib
> on itself without using the real linux properties.
> For example, for jpeg/quicktime, Adam uses an included jpeg library. A MUCH
> MUCH better way of doing this would be to link against a JPEG library which
> is already on the user's hard disk.
> 
> For MJPEG-tools, we use an MMX-accelerated JPEG lib (MMX acceleration can
> be turned off but it makes it LOTS faster!). We need to hack into Adam's
> quicktime library each time he brings out a new version.
> Besides that, I've been told that Adam's lib is - concerning the coding
> quality and easyness to implement somewhere else - very poorly written,
> which is the reason why it is not in gstreamer yet.
> 
> And, not unimportant, it only covers a few of the quicktime movies. Many
> quicktime movies made on windows/macos computers will not play using this
> quicktime lib.

I think most power users and developers are aware that this is due to 
proprietary, non-ported codecs. Does this apply to Quicktimes created 
with more standard codecs like MJPEG as well? I don't know, just wondering.

> 
> Last but not least, all different versions of Adam' lib are incompatible.
> Quicktime3linux-1.2 recorded movies with our MJPEG-tools are not playable
> in the newest broadcast using Quicktime4linux-1.3...
> 
> Do we want that in gstreamer? I suggest that we don't use the lib as it is,
> but AT LEAST make it link against existing jpeg libs instead of its own,
> which would be a huge improvement. Adam should know this himself but he
> doesn't care, probably (no flame intended, this is just what I think).

You are correct. No, I do not want that fiasco either. I suppose when I 
say to (re)use something I imply to evaulate the best approach as 
opposed to simply link against. I like the response from 3ivx.com 
regarding their pragmatic approach.

> 
> [...]

> For Dan again:
> Currently, since LVS is not gstreamified yet (neither is Kino, I suppose),

No, Kino is not yet ported to gstreamer. Arne Schirmacher is the lead, 
and I have asked him to look into gstreamer. It just seems as though 
other things besides Linux hacking have become a priority in Arne's life.

> 
> it's not much use to join venture here, but we coud start thinking about
> this when we have a gstreamer platform which we can use.
> You could work on a DV video capture part, I could work on a zoran
> capturing part and together, we could work on the editor part. This would
> be of much more use.

Full agreement. I did not know about LVS, but it's current simplistic 
approach is similar to Kino. However, Kino affords some more 
sophisticated editing and navigation through a playlist and vi key 
bindings. I liked this approach because I think a consumer video editor 
for high end set-top boxes sporting a 1394 port would be cool, and 
remote control buttons can be mapped to keycode events easier than GUI 
clicks and drags. This would be just one editor interface. A more high 
end editor for workstations is also desirable, of course.

> 
> Since one good editor is much better than 10 editors that can each only
> handle one bit of what it should handle. And since I don't like broadcast
> (working together with that developer there seems to be impossible/out of
> the question), we could make a good Gtk-based alternative here.
> I'm not directly thinking of something like Adobe Premiere here, but with
> gstreamer we should be able to handle a lot of formats, record from lots of
> formats and edit mixed combinations of all different movies.

Gstreamer will also allow the creation of more editing UIs for different 
users and formats as described above. Perhaps, there will eventually be 
integration into GIMPor 3D programs for rotoscoping too. Therefore, we 
should also be considering a set of core Bonobo components, GTK widgets, 
and whatever else that falls outside of gstreamer that an editor my require.

> 
> 
> Interested?

Yes.

> 
> Ronald
> 
+-DRD-+