[gst-devel] What projects are underway?

[Ronald Bultje]

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).

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.

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).

> [lots of stuff about Kino...]

Your stuff about Kino sounds really nice. 

For your info (general gstreamer mailing list this time):
MJPEGtools release is almost done, we're close to a release and I expect it
this or next week, after that we will start making gstreamer
implementations of our stuff.
Andrew (our he-knows-it-all-man and project leader) knows more about this,
these were our ideas:

1 - MJPEGtools consists of a lot of lav2..../...2lav programs, they all use
some generic 'lav' library, which is actually a higher level thing where we
input our movie, then decide whether it is quicktime/jpeg, avi/mjpeg or
movtar, and then we do what we're supposed to do.
We want to bring this lav-plugin as a gstreamer plugin into gstreamer to
add support for our mjpeg/'lav' movies into gstreamer. 
2 - Make a gstreamer source for synchronized audio/video capture (hardware,
via zoran) and encapsulate the encoder/multiplexer. Andrew thinks this will
be lots of work so it probably will be :-). I'm not so good at this part
yet, I've mainly worked with the lav library itself and programs with that.

With this, we would be able to port all our current MJPEG-tools to
gstreamer function calls. And it should make the life of my video editor
much much easier (since when gstreamer supports the generic 'lav format', I
can finally start working on gstreamerifying LVS which would imporve
editing etc. etc. etc.).
So after MJPEGtools plugins have been put into gstreamer and gstreamer is
able to handle the format well, I will change Linux Video Studio to use
gstreamer instead of our own formats, as far as possible.
Until gstreamer is able to handle our hardware, though, I will also use the
old lavrec/lavplay utilities to playback/record video using the MJPEG/zoran
hardware.

But first, let's await the stable MJPEGtools and also the next LVS devel
release, after that we will probably start the gstreamer work. And a lot of
other work too.

MJPEGtools: http://mjpeg.sourceforge.net/
LVS       : http://ronald.bitfreak.net/

For Dan again:
LVS can currently do simple cut/paste editig as well (frame-by-frame stuff,
etc). We also didn't work much on the sound yet, we are already happy since
after a few months, we can record video, playback, mpeg encode it and do
this simple editing. These are all actually juist GUI pipeline calls to the
MJPEG-tools themselves (but since I had to create most of these functions
in the mjpegtools too myself, this is actually the same).
With gstreamerifying all this, it would be overkill and double work to make
something that can edit and open all this, since when we use gstreamer, we
can do the same.
Currently, since LVS is not gstreamified yet (neither is Kino, I suppose),
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.
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.

Interested?

Ronald

-- 
---------------------------------------------------.
--   .-.    | Ronald Bultje                        |
--   /V\    | Running: Linux 2.4.3 and OpenBSD 2.8 |
--  // \\   | E-mail : rbultje at ronald.bitfreak.net |
-- /(   )\  | WWW    : http://ronald.bitfreak.net/ |
--  ^^-^^   |    *** Warning: Unix Addicted ***    |
---------------------------------------------------'