libquicktime-devel — Discussion about development

Re: [Libquicktime-devel] Unrfesolved symbol dv_peek_vlc

[Arthur P. <am...@si...>]

> If someone wishes it, we can export the initialization function into the 
> public API, so that an application doesn't even have to be restarted, 
> after new codecs are installed.

I don't think that's a bad idea. It might come in handy.

> The dv codec can't always be loaded, it has an unresolved symbol 
> dv_peek_vlc. It is defined extern inline.

I had to hack around that problem earlier. I don't know how to actually
fix the right way. But what I did is make sure the function dv_peek_vlc
in this case is compile exactly once. 

We should prolly just ignore it for now the problem should go away when
we switch to an external libdv. The problem is in the hacked libdv.

> 
> If there don't come any evil surprises, I think I can commit the updated 
> libquicktime into CVS this weekend or so.

Very cool. I need to remember to check the date on emails. I just read
your previus email and thought it was you current stat. Oh well.

-Arthur

-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

Re: [Libquicktime-devel] Re: goals

[Arthur P. <am...@si...>]

> When the codec database is "stable", I'll do the hard part: Replace the
> quicktime4linux functions, which create and destroy codecs. I already
> located all routines, but I must be very careful not to break something.
> 
> Until this happens, the sourcetree compiles (and runs my test programs). But
> it won't play a single file, because it can't load codecs yet. I suggest to 
> commit everything into CVS when it's functional again.
> 

Sounds like thing are going very well.

> 
> Most openquicktime developers work for 3ivx, so they have a natural
> interest, that there will be only poor codecs in openquicktime except their
> 3ivx. And if you check the price of the "real" 3ivx codec (not the feature 
> limited demo and less feature limited shareware), you'll know why
> (http://www.3ivx.com/order.html).
> 
> So I really don't see a reason to join with a project, which has recently
> shut down the openquicktime disscussion forum at www.3ivx.com.

I agree. We might as well do our own thing. openquicktime doesn't have a
whole lot to offer. Anyway if we like some of there code we can always
"borrow" it. ;-)

-Arthur

-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

Re: [Libquicktime-devel] goals

[Arthur P. <am...@si...>]

> Arthur, when I e-mail Charles a couple of weeks ago regarding including
> dv_utils and dv1394.h in libdv, I mentioned that I am also going to work
> on the public encoder interface. He did not mention that he was working
> on anything, and I think he is not very active except when really
> required. 

Sorry. I must have misread an email or misunderstood something.

> So, I have been working very much on including and reconciling
> the changes in the libquicktime/libdv, quicktime4linux/libdv, and a new
> patch from Peter Schlaile. I am only concerned right now about heroine's
> requirements not to clamp to preserve NTSC superblack as you two had
> discussed in his forum. I think I will need to accomodate both
> approaches.

Wonderful.

> I have something you can help with tho. In the public interface for
> encode I only want to support (initially) the same YUV and RGB formats
> that the decoder uses for the sake of consistency. That means: YUV4:2:0
> for PAL, YUV4:1:1 for NTSC, RGB, and simple guchar* instead of row
> pointers. Therefore, in libquicktime, we will need to down-sample
> quicktime YUV 4:2:2 and get rid of the row pointers. Can you work on
> these routines? It will be difficult to test at first, but you can rough
> them out for now.

Sounds good. I'll start working on that. Unless someone has a better
idea, I think I'll just add YUV411 to the libquicktime color model
convertion function: cmodel_transfer. Also in many cases the input to
the quicktime library is RGB (bcast and cinalerra as well I think use
RGB interally) so we could just re arrange the RGB data into one big
guchar buffer and pass that to libdv.

The colormodel convertion code is kind of ugly (check out
cmodel_permutation.h). Maybe we should redesign it a bit. It seems to me
that most of the ogly macro stuff and huge numbers of parameters in
cmodel_permutations.h and colormodels.c, etc. could be avoided by having
something like:

typedef void (*pixel_conversion_func) (unsigned char *input, unsigned
char *output);
typedef void (*image_conversion_func) (unsigned char *input, unsigned
char *output, long width, long height);

pixel_conversion_func pixel_convertion_table[][];
image_conversion_func image_convertion_table[][];

pixel_convertion_table[BC_RGB888][BC_YUV888] = pixel_RGB888_to_YUV888;
...
image_convertion_table[BC_RGB888][BC_YUV422] = image_RGB888_to_YUV422;
image_convertion_table[BC_RGB888][BC_YUV411] = image_RGB888_to_YUV411;
...

Then inside cmodel_transfer this is all that would be nessesary istead
of all the scary switchs and macros:

if( image_convertion_table[in_cmodel][out_cmode] != NULL )
{
	image_convertion_table[in_cmodel][out_cmode]( in_buf, out_buf, width,
height );
}
else if( pixel_convertion_table[in_cmodel][out_cmode] != NULL )
{
	for( int y=0; y < height; y++ )
	{
		for( int x=0; x < width; x++ )
		{
			pixel_convertion_table[in_cmodel][out_cmode]( in_buf[(y*width + x) *
bytes_per_pixel], out_buf[(y*width + x) * bytes_per_pixel] );
		}	
	}
}

Tell me if you think this is a change worth making. As I think it over
it seems to me that it isn't worth it and we should just stick with the
current setup.

Later.

-Arthur 

-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

[Libquicktime-devel] Unrfesolved symbol dv_peek_vlc

[Burkhard P. <pl...@ip...>]

Hi all,

yesterday, I finished the codec registry.
It parses the file ~/.libquicktime_codecs and scans the plugin 
directory, which is hardcoded to <prefix>/lib/libquicktime by the 
configure script.
The codec registry is then built from the file or from the dynamic 
modules, depending on which is newer. New modules, which are not in the 
file, are scanned for codecs, old modules, which are in 
.libquicktime_codecs, but not in the plugin directory, are removed from 
the registry. The updated .libquicktime_codecs is written right after 
the initialization.

This means, you just need to copy a new binary codec into the plugin 
direcory, start an arbitrary libquicktime application and 
.libquicktime_codecs will be updated automatically (This is really the 
simplest possible way).
If someone wishes it, we can export the initialization function into the 
public API, so that an application doesn't even have to be restarted, 
after new codecs are installed.

I also put a global desctructor in the proper section of the ELF module 
(using __attribute__ ((destructor)) ), so the registry will 
automatically be destroyed, if the program is quit (or, hopefully, when 
the shared lib is unloaded).

The dv codec can't always be loaded, it has an unresolved symbol 
dv_peek_vlc. It is defined extern inline.
When I remove the "extern", gcc complains aboput too many symbols 
dv_peek_vlc (I'm using gcc-3.0.2). Does anyone know a workaround for 
this? I don't really want to hack inside libdv, since other project 
members can do this much better. If I remember right, It was loaded 
sometimes, but I couldn't reproduce the compiler switches. In any case, 
I would recommend to add -finline-functions to the default CFLAGS, so 
that inlining is enabled even if we compile without optimization.

If there don't come any evil surprises, I think I can commit the updated 
libquicktime into CVS this weekend or so.

[Libquicktime-devel] Win32 Codecs

[Burkhard P. <pl...@ip...>]

I spent some minutes to reseach a bit in the internet about the 
internals of the original Win32 Quicktime codecs.
I put this message here, to get it into the archive, so I (and others) 
can use this information later.
Maybe we can collect some more data from time to time and see, if we'll 
be able to load Windows DLLs.

It is nothing I'll be able to program with the next time, I was just 
curious.

If we get this working, we can dramatically decrease the number of 
reasons for people to use minor operating
systems from big companies.

So here is, what I found:

The Original Quicktime API is pure C. All header files can be downloaded 
in the Quicktime Windows SDK at http://developer.apple.com/
An API documentation is also available there. So it should, in general, 
be possible to find out, how the
codecs work and if their functionality can be wrapped into our 
libquicktime interface.

So a next step could be to get the original DLLs and see which functions 
are in the DLL, and which
external functions are needed by the DLL. A friend of mine is a windows 
programmer, he knows,
how to do this.

Then we can take a look at the avifile sources and see, how they load 
windows codecs in general and what is different in quicktime DLLs.

2. Here is something about some Codecs (taken from qtcentral.de, German 
site). I guess, the Subtype is identical to the FourCC.

Sorenson - Video 2
==============

QuickTime Image (Video) Decompressor Componentes (imdc)
Sorenson Video 2 Decompressor
ID: 0x000101A3
Subtype: SVQ1
Class: SVis

QuickTime Image (Video) Compressor Componentes (imco)
Sorenson Video 2 Compressor
ID: 0x00020235
Subtype: SVQ1
Class: SVis

Colorspace: YUV-9 (Do we support this?)

Sorenson - Video 3
==============

QuickTime Image (Video) Decompressor Componentes (imdc)
Sorenson Video 2 Decompressor
ID: 0x000101A3
Subtype: SVQ1
Class: SVis
Sorenson Video 3 Decompressor
ID: 0x00010107
Subtype: SVQ3
Class: SMI

QuickTime Image (Video) Compressor Componentes (imco)
Sorenson Video 2 Compressor
ID: 0x00020235
Subtype: SVQ1
Class: SVis
Sorenson Video 3 Compressor
ID: 0x000100C5
Subtype: SVQ3
Class: SMI

Colorspace: YUV-12 (== YUV 4:2:0 planar?)

On2 - VP3
========

QuickTime Image (Video) Decompressor Componentes (imdc)
VP3 Decompressor
ID: 0x0001022C
Subtype: VP31
Class: On2

QuickTime Image (Video) Compressor Componentes (imco)
VP3 Compressor
ID: 0x00040228
Subtype: VP31
Class: On2

Colorspace = YUV 4:2:0

Re: [Libquicktime-devel] goals

[Dan D. <da...@de...>]

On Mon, 2002-02-18 at 00:25, Arthur Peters wrote:
> 
> I like that idea. We all seem to have the same goals. I remember seeing
> something from Charles Krasic (Can't find the message now) saying that
> he was going to start work on the DV encoder and that it will take a
> while. So we may need to work around his progress. I at least would like
> to help him if that is possible. I'm going to email him about it later.

Arthur, when I e-mail Charles a couple of weeks ago regarding including
dv_utils and dv1394.h in libdv, I mentioned that I am also going to work
on the public encoder interface. He did not mention that he was working
on anything, and I think he is not very active except when really
required. So, I have been working very much on including and reconciling
the changes in the libquicktime/libdv, quicktime4linux/libdv, and a new
patch from Peter Schlaile. I am only concerned right now about heroine's
requirements not to clamp to preserve NTSC superblack as you two had
discussed in his forum. I think I will need to accomodate both
approaches.

I have something you can help with tho. In the public interface for
encode I only want to support (initially) the same YUV and RGB formats
that the decoder uses for the sake of consistency. That means: YUV4:2:0
for PAL, YUV4:1:1 for NTSC, RGB, and simple guchar* instead of row
pointers. Therefore, in libquicktime, we will need to down-sample
quicktime YUV 4:2:2 and get rid of the row pointers. Can you work on
these routines? It will be difficult to test at first, but you can rough
them out for now.

Re: [Libquicktime-devel] Proposal for a codec plugin interface

[Dan D. <da...@de...>]

On Mon, 2002-02-18 at 08:37, Burkhard Plaum wrote:
> >P.S. more on dmSDK...
> >
> >OpenML, the dmSDK successor, is supposed to be cross-platform by
> >abstracting the native platform's multimedia architecture, and it
> >integrates with OpenGL.
> >
> For this, I have also choosen the hard way for gmerlin :-)
> I considered using SDL for output, but it doesn't have the kind of 
> features I needed. Especially multichannel support, which is in gmerlin 
> since its first release, is impossible with SDL.
> Having a universal multimedia architecture is, of course, a nice thing. 
> But my own X11 and OSS drivers have the advantage, that new features in 
> XFree86 or in OSS kernel drivers can quickly be implemented without 
> being propagated through another library before :-)

I understand. Keep in mind dmSDK complements something like SDL rather
than compete. SDL takes care of hardware abstraction for some things,
but dmSDK is more about A/V data communication, transformation, and
synchronization. Also, dmSDK is basically an empty framework with only
modules for V4L and OSS right now. Anyway, I have much work right on
libdv to further evaluate it.

Re: [Libquicktime-devel] Re: goals

[Dan D. <da...@de...>]

On Mon, 2002-02-18 at 21:00, Burkhard Plaum wrote:
 
> If it's that easy, it was no mistake to commit your tree :-)
> 
> I used CVS only for checking out packages, so I didn't really know how it
> works. I got some howto now, I'll study this.

Here is the book I use:
http://cvsbook.red-bean.com/
 
> 
> We have a very nice range of codecs for both professional use and low
> bitrate environments. We can eventually think about supporting the xvid 
> codec from www.videocoding.de (Fully GPLed divx codec) to further improve 
> this.

yes, that would be good

I have been working on libdv. First, I applied a new patch from the guy
who first contributed encoding (now supports 16x9). I have run diffs for
the libdv included in libquicktime as well as heroine's latest
quicktime4linux. I am analyzing the changes closely to see what critical
changes he made that he might rely upon.


 

[Libquicktime-devel] Re: goals

[Burkhard P. <pl...@ip...>]

> Hmm, I wonder if I made a mistake commiting the source this soon. CVS
> will not move divx.c automagicly. You already moved to files in your
> working copy so you need to remove the file from the original location
> and add it at it's new location. As follows:

> cvs remove divx.c
> cvs add plugins
> cvs add opendivx
> cvs add plugins/opendivx/divx.c

If it's that easy, it was no mistake to commit your tree :-)

I used CVS only for checking out packages, so I didn't really know how it
works. I got some howto now, I'll study this.

> It seems to me that the first thing we are going to do is implement the
> plugin stuff. Burkhard, it sounds like you are going to reoriginize the
> source. That will be a step in the right direction, and I think the next
> thing we really need to do is finalize (as much as possible) the plugin
> interface.

Actually I do both at once. Today, I transfered all the codec information
from the codec source (and quicktime4linux documentation) into the plugins,
where they can be accessed as info structures (name, long name,
description...).
I put also all codec parameters there, so they can be obtained at runtime.

I wrote a test program, which reads the information from the codec dlls, and
prints them to stderr. It also writes a file in the format of the codec
config file.
This part already works (since one hour ago).

Now, I need a routine, which parses the codec config file at startup, so it
doesn't need to load the modules each time (better startup speed).

When the codec database is "stable", I'll do the hard part: Replace the
quicktime4linux functions, which create and destroy codecs. I already
located all routines, but I must be very careful not to break something.

Until this happens, the sourcetree compiles (and runs my test programs). But
it won't play a single file, because it can't load codecs yet. I suggest to 
commit everything into CVS when it's functional again.

> The plugin interface is specialized to the library (I thought Burkhard had
> implied it was generic)

Allright, it was long ago I looked a it.

> and there has been activity in the OpenQuicktime
> CVS (4 weeks ago). I think we should talk to them maybe the project
> isn't as dead as we thought it was. Tell me what you think.

I observed their CVS for quite a time and noticed only little activity over
the time. And since they exist (for 6 Months), they promised to port all the
quicktime4linux codecs to openquicktime, and nothing happened (I did 
pratically the same for libquicktime in 2 days :-) The only interesting thing
they have, is the xanim plugin, but this can be reproduced.

There are at least 2 projects involved in libquicktime and I could imagine,
that other projects (e.g. gstreamer) use openquicktime only, because 
quicktime4linux a static lib, which cannot be linked with dynamic player 
plugins.

We have a very nice range of codecs for both professional use and low
bitrate environments. We can eventually think about supporting the xvid 
codec from www.videocoding.de (Fully GPLed divx codec) to further improve 
this.

Most openquicktime developers work for 3ivx, so they have a natural
interest, that there will be only poor codecs in openquicktime except their
3ivx. And if you check the price of the "real" 3ivx codec (not the feature 
limited demo and less feature limited shareware), you'll know why
(http://www.3ivx.com/order.html).

So I really don't see a reason to join with a project, which has recently
shut down the openquicktime disscussion forum at www.3ivx.com.

> if you look at openquicktime.h they have changed the
> params for quicktime_{en,de}code_video.

quicktime4linux compatibility is another argument. The highest level
function prototypes, I had to change up to now, are 
quicktime_init_audio_map() and quicktime_init_video_map().
Both of them are not in quicktime.h, so if my knowlegde about dynamic
linking isn't too poor, we'll be even binary compatible. I only need a dummy 
version for quicktime_set_jpeg, which calles quicktime_set_parameter.

BTW, does anyone know, how to call a function automatically, when a dynamic
library is UNloaded? We need this to free the codec database. For executables
linked with libquicktime, this won't be a problem, but if libquicktime 
player plugins (and therefore libquicktime.so) are unloaded, the database 
must be freed or we'll have a memory leak (a similar memory leak
is in the current quicktime4linux too!).

Re: [Libquicktime-devel] Re: goals

[Arthur P. <am...@si...>]

On Mon, 2002-02-18 at 04:59, Burkhard Plaum wrote:
> >>> but I don't use
> >>> any rpm distro so others will have to work on that.
> >>
> flyn is a member of our project. He's the one, who made quicktime4linux 
> rpms before.

Oh yea, I forgot. That's great.

> Well, we could think about making one release (with rpms, debs etc.) 
> from what we have now.
> If we make a freshmeat announcement then, we should become famous enough 
> for the beginning.
> 
> But after dynamic codecs work, we'll have a slightly changed build 
> process and a more complicated installation process (because more files 
> get installed), so the packages will also look different then.

That's a good point. Maybe it would be better to wait until the plugin
stuff is done.

> At this point, we could also think about how to package libquicktime. In 
> any case, we should have libquicktime and libquicktime-devel (because 
> that's standard).
> The question is, if we should have the plugins also in separate packages 
> (libquicktime-plugins) or even one package for each plugin. I think, 
> there are the following possibilities:
> 
> 1. Make plugin packages, which depend on certain libraries (e.g. 
> libquicktime-vorbis, libquicktime-jpeg). In this case, we can put the 
> uncompressed codecs in the core libquicktime, because they don't have 
> any depenencies. (this would also make sense, because without at least 
> one audio and one video plugin, the libquicktime package would be not 
> usable)
> 
> 2. Put all LGPL plugins into libquicktime, but make the package depend 
> on nothing. This would work since only the codecs (not the core library) 
> are linked with the external libs. This means, that the application will 
> start, but the dlopen() of the codec will fail.
> The user will see a warning message then, that the OggVorbis codec can't 
> be loaded (because of missing libvorbis), but the application will work 
> with all other codecs.
> 
> 3. Put all plugins into libquicktime and make it dependend on png, 
> libvorbis and jpeg. Today, it's really hard to find a linux distribution 
> without libjpeg and libpng installed by default, so in my opinion, 
> depending on them would not hurt. Ogg Vorbis is also widely available.

I think 2 or 3 or a combination would be best. Having lots of packages
is confusing.

In the debian system at least (don't know about redhat) you can have
packages that are suggested but not required, so we could have a
libquicktime package with all the codecs. It would require libjpeg,
libpng (becuase they are common and very handy codecs) and libz maybe
and suggest the ogg/vorbis libraries, libdv (when we get that split out)
and any other less common codec libraries.

> 
> Another question:
> I'm not a CVS guru (but I want to become one), so maybe, someone can 
> give me some hint for now:
> I have now the libquicktime on my harddisk with the rearranged directory 
> structure.
> I'm wondering, If I'll be able to commit this into the current CVS 
> directory (e.g. will CVS automatically move divx.c to 
> plugins/opendivx/divx.c?), or should I make another CVS directory 
> (libquicktime-dynamic or so)?

Hmm, I wonder if I made a mistake commiting the source this soon. CVS
will not move divx.c automagicly. You already moved to files in your
working copy so you need to remove the file from the original location
and add it at it's new location. As follows:

cvs remove divx.c
cvs add plugins
cvs add opendivx
cvs add plugins/opendivx/divx.c

[reapeat this for all the plugins you moved]

cvs commit -m'Moved plugins into subdirectories'

Someone please tell us if there is a better way to do this.

It seems to me that the first thing we are going to do is implement the
plugin stuff. Burkhard, it sounds like you are going to reoriginize the
source. That will be a step in the right direction, and I think the next
thing we really need to do is finalize (as much as possible) the plugin
interface. 

BTW, I look over some bits of OpenQuicktime and found two things: The
plugin interface is specialized to the library (I thought Burkhard had
implied it was generic) and there has been activity in the OpenQuicktime
CVS (4 weeks ago). I think we should talk to them maybe the project
isn't as dead as we thought it was. Tell me what you think. I just
realized that I'm not sure what we're doing that couldn't be don't
within thier project. We are planning to keep at least source code
compatibility and if you look at openquicktime.h they have changed the
params for quicktime_{en,de}code_video.

I'm not thinking to well today (I'm a bit sick). I'll think about this
situation more later.

-Arthur

-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

Re: [Libquicktime-devel] Proposal for a codec plugin interface

[Burkhard P. <pl...@ip...>]

>>Isn't the API in quicktime.h enough?
>>
>Now, if
>you need to work with devices for capture, export, and monitoring, the
>codecs need to interface with devices like MJPEG/V4L and Dv/1394.
>
Allright, I forgot this. As soon as you capture compressed data from 
somewhere, you want to write them into a quicktime file without using a 
codec for this.

>Then, the app only needs to deal with the universal API--at least
>you understand this point with your plugin experience. 
>
Yea, gmerlin plugins take a filename and come back with audio samples 
and video frames.
Other players have independent plugins for demuxers and codecs.
I decided to make the higher level API for gmerlin, because there were 
already a lot of decoding libraries available.

>Your plugin
>proposal suggests that you understand the value of eventually making a
>universal codec plugin API. I do not suggest you do that either;
>
It's not really simple to do that because every programmer has his own 
brain :-)
Everyone knows, that a unified Codec API would be great, but noone wants 
to spend several days or weeks to convert his own API to another one. 
avifile and MPlayer had similar plans, but avifile is C++ and MPlayer is C.

>In a media player app like gmerlin, it's not very critical to have this parity.
>
One plan for gmerlin is to support compressed audio and video frame 
inside the playback engine.
This would make it possible. e.g. to rip a VCD, keep the original mp2 
audio (without recompressing), recompress video in Divx and put 
everything into an AVI file.
My mpeg library can already output compressed Mpeg audio- and AC3 frames 
directly.

But even for this, I only need access to compressed data, which is 
possible both with libquicktime and avifile.

> In Kino, where we want to
>support editing mixed media types, it is more critical. Also, I do not
>want to just perpetuate the current state of affairs.
>
Ahh, what I wanted to ask about Kino: According to your webpage, kino is 
for DV video. But will it also become a universal video editor (like 
Bcast2000)? That's important for me, because gmerlin will never become 
an editor, but it should always be compatible audio/video with editing 
programs.
For this, nothing is better, than maintaining libquicktime together :-)

>Therefore, you have some time to work on the plugin architecture while I work on libdv encode. 
>
I hope, It will work the next week(s). The libdv stuff is untouched so 
far, I only moved the codec source into a subdirectory, together with 
the libdv directory.

>P.S. more on dmSDK...
>
>OpenML, the dmSDK successor, is supposed to be cross-platform by
>abstracting the native platform's multimedia architecture, and it
>integrates with OpenGL.
>
For this, I have also choosen the hard way for gmerlin :-)
I considered using SDL for output, but it doesn't have the kind of 
features I needed. Especially multichannel support, which is in gmerlin 
since its first release, is impossible with SDL.
Having a universal multimedia architecture is, of course, a nice thing. 
But my own X11 and OSS drivers have the advantage, that new features in 
XFree86 or in OSS kernel drivers can quickly be implemented without 
being propagated through another library before :-)

[Libquicktime-devel] Re: goals

[Burkhard P. <pl...@ip...>]

Hi all,

>>> I'm a Debian user so I'd be willing to help create debs,
>>
Very good.

>>> but I don't use
>>> any rpm distro so others will have to work on that.
>>
flyn is a member of our project. He's the one, who made quicktime4linux 
rpms before.

> PS: Just to though out a discusion point. I wonder if we should build
> distrobution packages (rpm, deb) first and then start adding features. I
>
> think that not having packages in most dists is one of the main things
> that would stop libquicktime from being used. If we package now then
> people may start running over it more and by the time the now features
> are added we may have a bit of a user base. (it would also make
> intigration with Kino, etc. easier) Please comment.
>
Well, we could think about making one release (with rpms, debs etc.) 
from what we have now.
If we make a freshmeat announcement then, we should become famous enough 
for the beginning.

But after dynamic codecs work, we'll have a slightly changed build 
process and a more complicated installation process (because more files 
get installed), so the packages will also look different then.

As long, as we don't have some small applications suitable for end users 
(maybe a simple SDL player like in openquicktime), our "users" are 
mainly developers from other projects. We should, of course, be in every 
distribution, but another goal should be to be used by many other projects.

At this point, we could also think about how to package libquicktime. In 
any case, we should have libquicktime and libquicktime-devel (because 
that's standard).
The question is, if we should have the plugins also in separate packages 
(libquicktime-plugins) or even one package for each plugin. I think, 
there are the following possibilities:

1. Make plugin packages, which depend on certain libraries (e.g. 
libquicktime-vorbis, libquicktime-jpeg). In this case, we can put the 
uncompressed codecs in the core libquicktime, because they don't have 
any depenencies. (this would also make sense, because without at least 
one audio and one video plugin, the libquicktime package would be not 
usable)

2. Put all LGPL plugins into libquicktime, but make the package depend 
on nothing. This would work since only the codecs (not the core library) 
are linked with the external libs. This means, that the application will 
start, but the dlopen() of the codec will fail.
The user will see a warning message then, that the OggVorbis codec can't 
be loaded (because of missing libvorbis), but the application will work 
with all other codecs.

3. Put all plugins into libquicktime and make it dependend on png, 
libvorbis and jpeg. Today, it's really hard to find a linux distribution 
without libjpeg and libpng installed by default, so in my opinion, 
depending on them would not hurt. Ogg Vorbis is also widely available.

Another question:
I'm not a CVS guru (but I want to become one), so maybe, someone can 
give me some hint for now:
I have now the libquicktime on my harddisk with the rearranged directory 
structure.
I'm wondering, If I'll be able to commit this into the current CVS 
directory (e.g. will CVS automatically move divx.c to 
plugins/opendivx/divx.c?), or should I make another CVS directory 
(libquicktime-dynamic or so)?

Re: [Libquicktime-devel] goals

[Arthur P. <am...@si...>]

Hi, guys,
	My life has slowed down a bit so I have time for libquicktime again. I
just commited the current libquicktime to CVS on sourceforge.

On Wed, 2002-02-13 at 04:45, Burkhard Plaum wrote:
> >I believe libquicktime should be easier for users to build and install.
> >Arthur Peter's step to apply the autotools build to Quicktime4Linux is a
> >big step
> >
> I completely agree. We must make libquicktime a "standard" linux 
> library. So all the nice things, which are available for other libraries 
> (libquicktime-config script, autoconf macros which let other projects 
> ckeck for installed libquicktime, .rpm and/or .deb release) should be made.

I'm a Debian user so I'd be willing to help create debs, but I don't use
any rpm distro so others will have to work on that. But I think working
towards binary packages is a good idea.

> My goal is to have quicktime read support with as many codecs as 
> possible. For writing quicktime files, we already have some nice codecs 
> (opendivx, OggVorbis), so I would focus on reading for now.
> For this, I would like to implement dynamically loadable codecs. I'll 
> post a proposal for the codec interface in a separate mail, so we can 
> discuss that.
> If we have this, I could add read support for mp3, Xanim codecs and 
> maybe even 3ivx. I also located the routine for reading compressed 
> headers in the openquicktime tree, which could be ported to libquicktime.
> 
> So the question is, when to do what. If Arthur allows it, I would first 
> suggest to remove libdv and then implement the dynamic codecs.

I like that idea. We all seem to have the same goals. I remember seeing
something from Charles Krasic (Can't find the message now) saying that
he was going to start work on the DV encoder and that it will take a
while. So we may need to work around his progress. I at least would like
to help him if that is possible. I'm going to email him about it later.

I need to go to bed now.

Later.

-Arthur

PS: Just to though out a discusion point. I wonder if we should build
distrobution packages (rpm, deb) first and then start adding features. I
think that not having packages in most dists is one of the main things
that would stop libquicktime from being used. If we package now then
people may start running over it more and by the time the now features
are added we may have a bit of a user base. (it would also make
intigration with Kino, etc. easier) Please comment.

-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

[Libquicktime-devel] Codec interface

[Burkhard P. <pl...@ip...>]

Hello all,

I have begun to write the dynamic codec interface fir libquicktime.
It already looks quite good (although it doesn't work yet).

I found, that it's possible, not to touch any of the original codec source
files, so we'll be able to apply patches in the codecs.

As far as I see it now, only the files codecs.c and plugin.c from the original
quicktime4linux core code have to be changed.

I renamed them to ltq_codecs.c and ltq_plugin.c (originals will stay in the
sourcetree
but not be compiled).

I also prefixed all new other new files,
functions and datatypes with lqt_ , so we'll see what is our own code.

The plugins are in a subdirectory plugins, with the subdirectories

audiocodec/
dv/
mjpeg/
opendivx/
png/
videocodec/
vorbis/

Each subdirectory contains the code for one plugin. The directories
audiocodec and videocodec contain the uncompressed or weak compressing
codecs, which have no library dependencies.

I also moved the linker flags to the plugin makefiles, so that libquicktime
itself currently needs no single library to be linked with.

The codec database works with linked lists internally, but the user will
access it with the global functions:

int lqt_get_num_audio_codecs();
int lqt_get_num_video_codecs();

const lqt_codec_info_t * lqt_get_audio_codec_info(int index);
const lqt_codec_info_t * lqt_get_video_codec_info(int index);

so it should be simple to handle.

I made files lqt.h and lqt_codecinfo.h, which contain our extensions to the
API, so we can leave the original quicktime.h (with the quicktime4linux
compatible API layer)
untouched.

Still to be done is the detection of all points in quicktime4linux, where
codecs are created and destroyed (should be few). These must be replaced by
(not yet written) lqt_* functions, which do the dynamic (un)loading.

Give me another week or so until I get this running.

I think we should setup the CVS repository, when dynamic loading works,
because we are different enough from quicktime4linux then :-)

I will also make a diff against the newest quicktime4linux and try to apply
it.

Burkhard

Re: [Libquicktime-devel] Proposal for a codec plugin interface

[Dan D. <da...@de...>]

On Fri, 2002-02-15 at 05:32, Burkhard Plaum wrote:
> Maybe I missunderstood this, but why do you need to deal with the codec 
> interface in the application?
> Isn't the API in quicktime.h enough?

Well, Kino will have to deal with raw DV, AVI, and Quicktime muxers. I
think it is a wrong approach to make muxers knowledgeable about codecs
except in the case of MPEG program and transport streams. If you look at
something like your gmerlin or transcode, there is not parity between
codec support in the AVI and Quicktime muxers. To do make parity
requires adapting each codec to the interface of each muxer lib. Now, if
you need to work with devices for capture, export, and monitoring, the
codecs need to interface with devices like MJPEG/V4L and Dv/1394.

The other approach is to treat them indepently and make everything
conform to a higher level API. That is the approach of gstreamer, and
SGI's dmSDK (now a part of OpenML). I think the planning for next
generation artsd is doing the same. In very general terms, the current
approach described above requires interfacing for (x muxers/devices * y
codecs), whereas the universal API approach requires interfacing for (x
+ y). Then, the app only needs to deal with the universal API--at least
you understand this point with your plugin experience. Your plugin
proposal suggests that you understand the value of eventually making a
universal codec plugin API. I do not suggest you do that either; keep
reading....

I understand how evolution has led to the current approach in the Q4L
and avifile projects as each worked independently without an otherwise
dominant, standard, and mature API. In a media player app like gmerlin,
it's not very critical to have this parity. In Kino, where we want to
support editing mixed media types, it is more critical. Also, I do not
want to just perpetuate the current state of affairs.

gstreamer is an awesome effort that I believe will eventually dominate
on *nix and bsd. However, I do not think it is functionally ready for
NLE, and it is difficult for me to keep up with let alone our users! I
am evaluating the SGI dmSDK (LGPL) because it is simpler and appears to
provide just what I need and not too much more. It provides a
comprehensive framework for not only dealing with muxers and codecs but
also devices such as V4L, OSS, and AlSA in addition to our current
support for ieee1394. dmSDK is not as ambitious or flexible as
gstreamer, but I hope that it provides something usable right now so I
do not have to create my own class framework. After all, SGI created it
and must have put some thought into it. Hopefully, all I need to do is
write the various modules.

Linux DV encoding is also in a messy state of affairs between
libquicktime, transcode, and libdv's builtin encode utilities. Now that
dv1394 is finished, I am working on a public interface for libdv encode
that deals only with libdv's native video types: YUY2 4:2:0, YUY2 4:1:1,
and RGB8. Then, I will build the DV plugin against it to retain
compatibility with heroine's work. At a minimum, I'll have to convert to
and from bcast's YUV 4:2:2. Therefore, you have some time to work on the
plugin architecture while I work on libdv encode. When, we are both
done, then I will be able to make the libquicktime dv plugin and remove
the custom, private libdv.
 
> I also investigated into this direction for gmerlin. I found, that this 
> isn't straightforward with the standard autoconf/automake procedure. 
> Actually, I don't see a reason for this right now, but if it's necessary 
> for kino, we should do this.

I think all we will need is a configure --without-plugins where
--with-plugins is the default. Then, we should recommend that a distro
packager create 3 packages: libquicktime, libquicktime-dev, and
libquicktime-plugins. Perhaps, there may come a time to split up
plugins, but leave that for later as needed.


P.S. more on dmSDK...

OpenML, the dmSDK successor, is supposed to be cross-platform by
abstracting the native platform's multimedia architecture, and it
integrates with OpenGL. I have not had the time to explore 3D DVE yet,
so I hope it will make it easier to eventually integrate that
functionality into Kino. Also, I hope it will be possible to make OpenML
run atop gstreamer. If that's the case, then we are possibly looking at
a real, open cross-platform solution for multimedia playback in Mozilla.
Furthermore, OpenML has hardware vendor support much like OpenGL;
however, as it is a new standard, I am only aware of 3DLabs support (and
possibly Intel) on Windows. 

Re: [Libquicktime-devel] Proposal for a codec plugin interface

[Burkhard P. <pl...@ip...>]

Hi,

>At the very least, it will make building or installing the core library
>package much easier for users due to reduced library version
>dependencies!
>
That's it. For the core libquicktime we need nothing but gcc (and zlib 
if we want to read compressed headers).

>I am evaluating an architecture for Kino that would only
>use the current external codec interface of libquicktime.
>
Maybe I missunderstood this, but why do you need to deal with the codec 
interface in the application?
Isn't the API in quicktime.h enough?

> Therefore, we
>should consider a build system that allows building the library alone,
>building individual plugins, or building everything.
>
I also investigated into this direction for gmerlin. I found, that this 
isn't straightforward with the standard autoconf/automake procedure. 
Actually, I don't see a reason for this right now, but if it's necessary 
for kino, we should do this.

Burkhard

Re: [Libquicktime-devel] Proposal for a codec plugin interface

[Dan D. <da...@de...>]

On Wed, 2002-02-13 at 05:58, Burkhard Plaum wrote:
> Hi all,
> 
> here are some thoughts about a libquicktime plugin architecture. These 
> are based on experiences with avifile and gmerlin. I could program all 
> this :-)
> 

Your proposal looks fine if that serves your needs. 
At the very least, it will make building or installing the core library
package much easier for users due to reduced library version
dependencies! I am evaluating an architecture for Kino that would only
use the current external codec interface of libquicktime. Therefore, we
should consider a build system that allows building the library alone,
building individual plugins, or building everything.

[Libquicktime-devel] Website

[Burkhard P. <pl...@ip...>]

I just spent some minutes to write some lines of html, which are at 
least better than nothing.

Actually, I wondered, how we could get an activity percentile of 
50.7714% without even having a homepage [:-)]

Everyone may feel free to make additions or changes.

[Libquicktime-devel] Proposal for a codec plugin interface

[Burkhard P. <pl...@ip...>]

Hi all,

here are some thoughts about a libquicktime plugin architecture. These 
are based on experiences with avifile and gmerlin. I could program all 
this :-)

Please feel free to comment, complain and suggest other solutions.

I never want to program something, which is good for gmerlin, but breaks 
other applications.

==================================================================

PROPOSAL FOR A LIBQUICKTIME PLUGIN INTERFACE
==============================================

1 Code separation
=================

To provide the possibility to add codecs to an already compiled (and 
installed) libquicktime, we need to strictly separate the quicktime core 
code and codec specific code.

In other words, libquicktime knows, where to find and how to use codecs. 
But the library itself should ideally contain no single line of code, 
which deals with special codecs.

To make this easier, I would suggest to make a plugins- or codecs 
directory in the sourcetree (similar to avifile).

2 Organization
==============

There are several possibilities to organize the codecs and the 
corresponding modules. Openquicktime has chosen the following possibility:

codecs are always in modules quicktime_codec_XXXX.so

where XXXX is the four character code (fourcc). The codecs are openend 
by a simple dlopen() with just the filename (without path). This means, 
they must be installed in /usr/lib or /usr/local/lib or another location 
where people have standard libs.

This not the best solution, for several reasons:

- Fourcc's can contain non ASCII characters, which cannot be used in 
filenames

- The en- and decoder MUST be in the same module, even if it would be 
more sensible to put them into separate modules.

- It isn't possible to put different codecs into one module. This would, 
however, be nice for the jpeg and mjpa codecs, because they share a lot 
of code. Especially if we think about a xanim or win32 loader, it is an
  absolute must to have one module, which can create more than one Codec.

- It's not a good idea to pollute the lib directories of the users 
harddisks with files, which are used by only one library. A much cleaner 
way is to have the codec in a directory <prefix>/lib/libquicktime/

Therefore I suggest the following:

- Each codec module (.so file) can contain an arbitrary number of codecs 
(audio, video, encoders, decoders). We should put the codecs, which 
match best together, in one module, e.g. jpeg and mjpa.

One criterium for grouping the codecs can also be external library 
dependencies, so that all codecs which require a certain library (e.g. 
vorbis, jpeg or png) are in one module. This will give a cleaner set of 
required linker flags.
There are also some lincense issues: It's not allowed to distribute free 
mp3 encoders in binary form. So a binary libquicktime could contain only 
the decoder, not the encoder.

- We define a codec info structure, which contains:

  - name (eventually long name and short name, maybe a decription)
  - Filename for dlopen()
  - supported Fourcc's (might be more than one)
  - Number, types and ranges (!!) of the supported codec parameters
  - Type (audio, video, encoder, decoder)
  - The index of the codec inside the module

- Each plugin module exports only 3 functions, which might have
  names like:

  get_num_codecs();
  get_codec_info(int index);
  create_codec(int index);

- We need an initialization function, which fills a global array with
  the info structures of all codecs.

  The most simple way is to scan the codec directory, dlopen() all
  modules and see, what's inside. This, however, is very slow,
  especially if lots of codecs are installed (it gets incredibly
  slow, when running this from gdb!)

  What I have in my view (I already implemented this for gmerlin),
  is a file (~/.libquicktime_codecs or so), where all the codec
  attributes are stored along with the file modification times of the
  modules.
  So the codec "database" is initialized as follows:

  for( all modules in directory )
    {
      Check, if module is in the codec file

      if(yes)
        {
           Check, if module is newer, than entry in codec file
           if(yes)
             dlopen module and get attributes
           else
             /* This will be the normal case! */
             get attributes from codec file
        }
      else
        dlopen module and get attributes
    }

  write updated codec file

Eventually, we could also save codec parameters (bitrate etc.) in the 
file for later use. We can also call this function several times and 
support codecs in the users home directory or codec directories set by 
environment variables.

The global codec "database" should, in any case, be accessible through 
library functions, so that applications can build their configuration 
dialogs for encoding dynamically at runtime.

Gmerlin currently does this in it's avi and ffmpeg encoders, and it 
really rocks :-)

3. API changes:
 
Currently, a libquicktime codec is defined as a structure, which
contains a private pointer (for storing codec specific data) and a
bunch of standardized function pointers:

typedef struct
{
  int (*delete_vcodec)(quicktime_video_map_t *vtrack);

  int (*delete_acodec)(quicktime_audio_map_t *atrack);

  int (*decode_video)(quicktime_t *file, unsigned char **row_pointers, 
 int track);
  int (*encode_video)(quicktime_t *file, unsigned char **row_pointers,  
int track);

  int (*decode_audio)(quicktime_t *file, int16_t *output_i, float 
*output_f, long samples, int track, int channel);

  int (*encode_audio)(quicktime_t *file, int16_t **input_i, float 
**input_f, int track, long samples);

  int (*reads_colormodel)(quicktime_t *file, int colormodel, int track);

  int (*writes_colormodel)(quicktime_t *file, int colormodel, int track);

  int (*set_parameter)(quicktime_t *file, int track, char *key, void 
*value);

  void (*flush)(quicktime_t *file, int track);
  void *priv;
  } quicktime_codec_t;

We need at least one additional void* pointer, which can be passed to 
dlclose() during cleanup.

AFAIK, dlopen and dlclose have internal reference counters, so we can 
dlclose() a module savely, even if another codec from the same module is 
still in use.

Another member, which should also be there, is the native colormodel of 
the codec. Of course, it's possible to use writes_colormodel and 
reads_colormodel, but getting the best colormodel in one function call 
is, in my optinion, a better method.

It should be save to append these additional members to the 
quicktime_codec_t structure after the priv pointer to keep binary 
compatibility with quicktime4linux.

The functions for registering and loading codecs must be completely 
rewritten or replaced (quicktime_find_vcodec, quicktime_find_acodec 
etc). This should, however, be possible without touching the exported 
API (as defined in quicktime.h).

4. Further ideas
================

The proposed codec interface is somewhat different from the others 
(avifile, openquicktime), because it assumes, that codecs are only used 
by libquicktime.

In the more distant future, one could think about a unified codec 
interface, which is shared between several projects (avifile etc).

For this, we should remove the quicktime_t stuff completely from the 
codec interface and have just functions like:

compress_audio(int16_t ** samples, int num_samples, char * out_buf, int 
& out_size, int & samples_encoded);

or similar.

The advantage would be, that the codec itself only deals with the 
numerical task of (de)compression. All stuff, which is related to the 
fileformat (e.g. update quicktime tables...) are not in the codec.

The disadvantage, however, would be a much harder job, when porting the 
quicktime4linux codecs to the plugins. So for now, I would prefer the 
method described above.

Re: [Libquicktime-devel] goals

[Burkhard P. <pl...@ip...>]

Hi,

>My goal is to have full Quicktime4Linux support in Kino (currently AVI
>only). Eventually, I think gstreamer will be a usable architecture and
>the current Quicktime support in it is weak (OpenQuicktime).
>
Yery good goal.

>I believe libquicktime should be easier for users to build and install.
>Arthur Peter's step to apply the autotools build to Quicktime4Linux is a
>big step
>
I completely agree. We must make libquicktime a "standard" linux 
library. So all the nice things, which are available for other libraries 
(libquicktime-config script, autoconf macros which let other projects 
ckeck for installed libquicktime, .rpm and/or .deb release) should be made.

>It is the job of autoconf and distributions to manage version dependencies. 
>
This is already implemented in libquicktime for all libs except libdv.

>First, I want to help by removing libdv from the package and coordinate
>any required changes to libdv to facilitate this.
>
A very good start would be a libdv.m4 file, so we can check for 
installed libdv from our configure script.
Almost all *.m4 files of other libraries were made by changing the 
gtk.m4 file.
If we have a variable $have_libdv, which is set in the configure script, 
this should be straightforward.
One advantage would be, that we would get rid of the glib dependency.
For me, this is no problem, because I use glib/gtk myself, but some 
KDE/qt people don't like glib.

>My SF id is ddennedy.
>
I added you to the project.

My goal is to have quicktime read support with as many codecs as 
possible. For writing quicktime files, we already have some nice codecs 
(opendivx, OggVorbis), so I would focus on reading for now.
For this, I would like to implement dynamically loadable codecs. I'll 
post a proposal for the codec interface in a separate mail, so we can 
discuss that.
If we have this, I could add read support for mp3, Xanim codecs and 
maybe even 3ivx. I also located the routine for reading compressed 
headers in the openquicktime tree, which could be ported to libquicktime.

So the question is, when to do what. If Arthur allows it, I would first 
suggest to remove libdv and then implement the dynamic codecs.

[Libquicktime-devel] What to do about future heroines versions?

[Dan D. <da...@de...>]

In response to the first post about how to work with heroines versions
of libquicktime...

I think we should just run a diff against the code and then treat it
like a patch submitted to any project. It is reviewed, edited, and
applied.

Additional codecs that heroines adds will require more analysis as we
need to view version dependencies, adjust autoconf macros as needed, and
avoid directly including the codec's code.

[Libquicktime-devel] goals

[Dan D. <da...@de...>]

Hi, I'm here guys.
First of all, let's reaffirm goals to help guide us:

My goal is to have full Quicktime4Linux support in Kino (currently AVI
only). Eventually, I think gstreamer will be a usable architecture and
the current Quicktime support in it is weak (OpenQuicktime).
  
I believe libquicktime should be easier for users to build and install.
Arthur Peter's step to apply the autotools build to Quicktime4Linux is a
big step

I believe libquicktime should play nice with other projects. I do not
like how Q4L encompasses various libs and statically compiles them. I
believe in cross-project collaboration and coordination. Therefore, I
support recent efforts to remove certain libs like ogg vorbis. It is the
job of autoconf and distributions to manage version dependencies. 

First, I want to help by removing libdv from the package and coordinate
any required changes to libdv to facilitate this. I am currently
analyzing the code of libquicktime, transcode, and dv_utils against
libdv. Eventually, I'd like to look at gstreamer integration if I ever
get around to working with it again.

My SF id is ddennedy.

+-DRD-+

[Libquicktime-devel] Libquicktime

[Burkhard P. <pl...@ip...>]

Hi Arthur,

>>BTW: quicktime4linux-1.5.5 is out (bugfix release)
>>
>That brings up a good question: Do we want to track the snapshots
>heroines releases on his sourceforge page or only the releases? I've
>found it quite easy to update the source to a new version, so I dont
>have a problem with using the snapshots but I suppose we ought to have a
>stable branch of some kind. Voice your oppinions.
>
First of all, I would make a diff against the previous version of 
quicktime4linux and see, what changed, then we can decide.
New codecs should be included in any case. If they appear to be 
unstable, people still have the possibility to use other codecs.

In principal I would assume, that the quicktime4linux core code is quite 
stable, so no heavy changes should happen here. So applying the 
quicktime4linux changes to libquicktime should be save.

But when we make some changes to the architecture (e.g. codec dlls), 
including the lastest changes will become more and more complicated. So 
our goal should be to keep the code as close to quicktime4linux as 
possible (especially if we want to be a source/binary compatible 
replacement for quicktime4linux).

>I'm willing to setup the one on sourceforge if we can wait a week. But if
>people out there want it up now someone else will need to do it
>
That's ok. I'm currently finishing multiangle DVD support for gmerlin 
(watched Star Wars Episode 1 last weekend :-) and writing (or stealing) 
a subtitle decoder is also on my TODO list. That should be enough for 
next week(s).

Burkhard