0.10.6 Release

[GoogleCodeExporter]

Cont'd from previous discussion...

The Farsight source needs to be updated. They're on 0.0.17+. I'll leave
that in your hands. :)

Original issue reported on code.google.com by david.g.hoyt on 8 Apr 2010 at 12:03

[GoogleCodeExporter]

Issue #34 needs to be fixed before release.

Original comment by david.g.hoyt on 8 Apr 2010 at 5:19

[GoogleCodeExporter]

Because I don't want to delay the release any further, I'm removing speex +
associated plugins from the installers. Once it's fixed it will be added back 
in.

Original comment by david.g.hoyt on 8 Apr 2010 at 11:06

[GoogleCodeExporter]

The first release candidate (RC01) has been uploaded. It includes the latest
dependency update.

Original comment by david.g.hoyt on 9 Apr 2010 at 12:03

[GoogleCodeExporter]

Let's leave the farsight updates until after the release. It's been too long 
since
our last release and the last major gstreamer releases.

Original comment by david.g.hoyt on 9 Apr 2010 at 12:16

[GoogleCodeExporter]

One last thing regarding the SDK. It seems that we are not including the .pc 
files
with the right path. I'll take a look at it tomorrow. A simple port-install .bat
using sed with the pc templates should do the job. It's important for developers
using mingw/msys :)

Original comment by ylatuya on 9 Apr 2010 at 12:20

[GoogleCodeExporter]

Tomorrow I'll also add a closing notice on the wiki redirecting all to this 
site :)

Original comment by ylatuya on 9 Apr 2010 at 12:22

[GoogleCodeExporter]

The templates for the gstreamer's .pc files are also missing. We should add 
them too
before the release

Original comment by ylatuya on 9 Apr 2010 at 3:45

[GoogleCodeExporter]

In order to be compatibles with mingw/msys we need:
 * Add gstreamer's .pc templates
 * Add .pc files to the SDK installer
 * Add .la files to the SDK installer (this is not mandatory since gcc can link
against the dll's)

The Python bindings installer needs also to be fixed, take a look at
http://code.google.com/p/ossbuild/source/browse/trunk/Packaging/Win32/Python/pyt
hon_bindings.iss
to see how it needs to be deployed.

Original comment by ylatuya on 9 Apr 2010 at 10:41

[GoogleCodeExporter]

Package config and libtool files pose a bit of a challenge in MSI packages due 
to 
the file manipulation that would have to take place. Also, we wouldn't know 
where to 
install them to since the mingw installation could be anywhere on disk and it 
doesn't provide any registry entries that we can read to determine its 
installation 
directory.

Originally my intent was to provide these packages for Windows developers. And 
to 
that end eventually I'd like to see complete integration with Visual Studio 
including GStreamer projects that one could create to get off the ground 
running. 
But for now I'm unsure how we should proceed.

Regarding the python bindings, what is it in particular that's not being 
followed? I 
tried to match that as best I could when I originally created the installers.

Original comment by david.g.hoyt on 10 Apr 2010 at 4:47

[GoogleCodeExporter]

dshowvideosrc has issues. If you stop and start it several times very quickly 
it 
freezes (deadlocks). directdrawsink doesn't have that problem. I haven't 
pinpointed 
the exact cause and not being a direct show guru, it's unlikely I'll be able to 
do 
so.

So -- I recommend that directdrawsink be primary until dshowvideosrc can be 
properly 
fixed.

Original comment by david.g.hoyt on 10 Apr 2010 at 7:00

[GoogleCodeExporter]

Yes let's do that. That might be the cause 
https://bugzilla.gnome.org/show_bug.cgi?
id=579926#c15

Original comment by ylatuya on 10 Apr 2010 at 7:34

[GoogleCodeExporter]

>Package config and libtool files pose a bit of a challenge in MSI packages due 
to
>the file manipulation that would have to take place. Also, we wouldn't know 
where to
>install them to since the mingw installation could be anywhere on disk and it
>doesn't provide any registry entries that we can read to determine its 
installation
>directory.
You don't need to know where MSYS was installed. You can install it in the SDK 
folder, since you can do 'export PKG_CONFIG_PATH=/c/Program 
Files/OSSBuild/GStreamer/v0.16/sdk/lib/pkgconfig'.
Can't you add a post-install script which 'sed' the lib/pkgconfig folder and 
replace 
the values in the templates with the installation path?

Original comment by ylatuya on 10 Apr 2010 at 7:35

[GoogleCodeExporter]

>Regarding the python bindings, what is it in particular that's not being 
followed? I
>tried to match that as best I could when I originally created the installers.

You should execute the installer and see how it's deployed.
 1) Defs and examples should be deployed in share/gst-python/0.10/examples and 
share/gst-python/0.10/defs
 2) Binaries should be deployed in lib/site-packages/gst/gst-0.10/
 3) pygst.py should be deployed in lib/site-packages/
 4) gstlibtoolimporter.py is missing and should be deployed  in lib/site-
packages/gst/gst-0.10/
 5) entends are also missing and should be deployed in lib/site-packages/gst/gst-
0.10/extend
 6) __init__.py is missing in lib/site-packages/gst/gst-0.10/

pygst.py needs to be patched, I'll try to integrate it in the build cleanly.

Original comment by ylatuya on 10 Apr 2010 at 7:57

[GoogleCodeExporter]

Can you check before the release why iconv.dll was overwritten wihtout the 
libiconv
support?
)http://code.google.com/p/ossbuild/source/detail?r=386&path=/trunk/Libraries/Bui
ld-All-Windows-x86.sh)
The one in trunk only export iconv* symbols and the patch was to enable also 
libconv*
symbols for compatibility with gnuiconv.

Original comment by ylatuya on 13 Apr 2010 at 1:21

[GoogleCodeExporter]

This the layout that should be used to deploy python:

./pygst.py
./gst-0.10
./gst-0.10/gst
./gst-0.10/gst/extend
./gst-0.10/gst/extend/discoverer.py
./gst-0.10/gst/extend/jukebox.py
./gst-0.10/gst/extend/leveller.py
./gst-0.10/gst/extend/pygobject.py
./gst-0.10/gst/extend/sources.py
./gst-0.10/gst/extend/utils.py
./gst-0.10/gst/extend/__init__.py
./gst-0.10/gst/audio.pyd
./gst-0.10/gst/farsight.pyd
./gst-0.10/gst/interfaces.pyd
./gst-0.10/gst/pbutils.pyd
./gst-0.10/gst/tag.pyd
./gst-0.10/gst/video.pyd
./gst-0.10/gst/_gst.pyd
./gst-0.10/gst/__init__.py
./share
./share/gst-python
./share/gst-python/0.10
./share/gst-python/0.10/defs
./share/gst-python/0.10/defs/audio.defs
./share/gst-python/0.10/defs/base.defs
./share/gst-python/0.10/defs/gst-extrafuncs.defs
./share/gst-python/0.10/defs/gst-types.defs
./share/gst-python/0.10/defs/gst.defs
./share/gst-python/0.10/defs/interfaces.defs
./share/gst-python/0.10/defs/libs.defs
./share/gst-python/0.10/defs/pbutils.defs
./share/gst-python/0.10/defs/tag.defs
./share/gst-python/0.10/defs/video.defs
./share/gst-python/0.10/defs/xoverlay.defs
./share/gst-python/0.10/examples
./share/gst-python/0.10/examples/audio-controller.py
./share/gst-python/0.10/examples/audioconcat.py
./share/gst-python/0.10/examples/bps.py
./share/gst-python/0.10/examples/cp.py
./share/gst-python/0.10/examples/debugslider.py
./share/gst-python/0.10/examples/decodebin.py
./share/gst-python/0.10/examples/f2f.py
./share/gst-python/0.10/examples/filesrc.py
./share/gst-python/0.10/examples/fvumeter.py
./share/gst-python/0.10/examples/gst-discover
./share/gst-python/0.10/examples/gstfile.py
./share/gst-python/0.10/examples/mixer.py
./share/gst-python/0.10/examples/pipeline-tester
./share/gst-python/0.10/examples/play.py
./share/gst-python/0.10/examples/remuxer.py
./share/gst-python/0.10/examples/sinkelement.py
./share/gst-python/0.10/examples/vumeter.py

All the .py .defs files can be copyed from the gst-python sources, except for
./pygst.py which I have stored in
Main\GStreamer\Windows\Build\Bindings\Python\pygst.py (should this be stored in 
the
Windows\Install\ ?)
The .pyd are the ones that we build.

The installer should also update/create  the PYTHONPATH environment variable  
and add
the deployment folder.

Original comment by ylatuya on 14 Apr 2010 at 7:35

[GoogleCodeExporter]

It should be:

./lib
./lib/site-packages
./lib/site-packages/gst-0.10
./lib/site-packages/gst-0.10/gst
./lib/site-packages/gst-0.10/gst/extend
./lib/site-packages/gst-0.10/gst/extend/discoverer.py
./lib/site-packages/gst-0.10/gst/extend/jukebox.py
./lib/site-packages/gst-0.10/gst/extend/leveller.py
./lib/site-packages/gst-0.10/gst/extend/pygobject.py
./lib/site-packages/gst-0.10/gst/extend/sources.py
./lib/site-packages/gst-0.10/gst/extend/utils.py
./lib/site-packages/gst-0.10/gst/extend/__init__.py
./lib/site-packages/gst-0.10/gst/audio.pyd
./lib/site-packages/gst-0.10/gst/farsight.pyd
./lib/site-packages/gst-0.10/gst/interfaces.pyd
./lib/site-packages/gst-0.10/gst/pbutils.pyd
./lib/site-packages/gst-0.10/gst/tag.pyd
./lib/site-packages/gst-0.10/gst/video.pyd
./lib/site-packages/gst-0.10/gst/_gst.pyd
./lib/site-packages/gst-0.10/gst/__init__.py
./lib/site-packages/gst-0.10/gst/__init__.pyc
./lib/site-packages/pygst.py
./share
./share/gst-python
./share/gst-python/0.10
./share/gst-python/0.10/defs
./share/gst-python/0.10/defs/audio.defs
./share/gst-python/0.10/defs/base.defs
./share/gst-python/0.10/defs/gst-extrafuncs.defs
./share/gst-python/0.10/defs/gst-types.defs
./share/gst-python/0.10/defs/gst.defs
./share/gst-python/0.10/defs/interfaces.defs
./share/gst-python/0.10/defs/libs.defs
./share/gst-python/0.10/defs/pbutils.defs
./share/gst-python/0.10/defs/tag.defs
./share/gst-python/0.10/defs/video.defs
./share/gst-python/0.10/defs/xoverlay.defs
./share/gst-python/0.10/examples
./share/gst-python/0.10/examples/audio-controller.py
./share/gst-python/0.10/examples/audioconcat.py
./share/gst-python/0.10/examples/bps.py
./share/gst-python/0.10/examples/cp.py
./share/gst-python/0.10/examples/debugslider.py
./share/gst-python/0.10/examples/decodebin.py
./share/gst-python/0.10/examples/f2f.py
./share/gst-python/0.10/examples/filesrc.py
./share/gst-python/0.10/examples/fvumeter.py
./share/gst-python/0.10/examples/gst-discover
./share/gst-python/0.10/examples/gstfile.py
./share/gst-python/0.10/examples/mixer.py
./share/gst-python/0.10/examples/pipeline-tester
./share/gst-python/0.10/examples/play.py
./share/gst-python/0.10/examples/remuxer.py
./share/gst-python/0.10/examples/sinkelement.py
./share/gst-python/0.10/examples/vumeter.py

The reason to use this layout is because the user can choose to install it under
c:\Python25 and everything will be integrated with the python installation.
Adding the PYTHONPATH variable might not be a good idea...

Original comment by ylatuya on 14 Apr 2010 at 7:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I reintroduced your iconv.dll, but I think the correct solution will require a 
complete rebuild of all libs using iconv.dll. The idea, as I understand it, is 
that 
the win iconv pkg allows you to put in iconv.dll if you want to. Otherwise it's 
meant to be statically linked to those dlls that think they need it.

Original comment by david.g.hoyt on 16 Apr 2010 at 5:22

[GoogleCodeExporter]

I'm not familiar w/ the python bindings at all -- if pygst.py is a customized 
version of an existing file, it needs to have a patch in the 
Main/GStreamer/Source/patches/ directory and should be submitted upstream. If 
it 
doesn't exist, then where you have it is fine unless it might be needed on 
linux/other OSes - in which case we'll have to talk about it further. If it's 
installer-related only it should be in Main/GStreamer/Windows/Install/ (as in 
files 
actually used to create the installer).

Also you mention in comment #13 that gstlibtoolimporter.py is needed, but I 
don't 
see it in your lists above. Is it still needed?

As for the msys integration -- I don't think that'll make it into this release 
unless you can find the time to do it. But perhaps the next one. In Windows 
installers, those kinds of tasks require a custom action and it's easier said 
than 
done. There are some open source projects that will do what we need, but it'll 
take 
me too much time to learn and integrate them for this release.

I believe the gstreamer folks or almost ready for a new release any day now, 
and I 
don't want to be lagging behind so badly w/ our own release. But I do think in 
the 
future we'll be a lot better since we'll have these growing pains all worked 
out.

That said, I think after the new gstreamer release we should do a quick release 
of 
our own (v0.10.6.2 or something of that nature) and then start focusing on x64 
support which I think will end up being fairly difficult and will probably 
require 
even more patches than we have now for win32. The msys/mingw package that's 
provided 
includes a gcc 4.4.3 x64 cross compiler, so we should be able to hit the ground 
running w/ that. That was very much on purpose. (c:

Original comment by david.g.hoyt on 16 Apr 2010 at 7:03

[GoogleCodeExporter]

Hi,
I deleted your message by mistake ;)
The idea of compiling iconv with this flag is that it enables 
cross-compatibility 
wince it's exports both iconv* and libiconv*, thus it's compatible with 
win_iconv and 
gnuiconv

Original comment by ylatuya on 16 Apr 2010 at 9:47

[GoogleCodeExporter]

I think we should release ASAP and take care of the rest on a another "bugfix" 
release. You have done a great job with the installers and the following 
releases 
should go smoothly ;)

glibtoolimporter.py is not needed for Python for the moment. pygst.py is 
generated 
from pygst.py.in y can integrate it in the Generate.bat script if you want, but 
this 
file won't change anymore, at least until the next GStreamer major version 
release :)

Original comment by ylatuya on 16 Apr 2010 at 9:50

[GoogleCodeExporter]

How were you able to get the libiconv* symbols in iconv.dll? No matter what I 
did I
couldn't get them in there short of writing my own code for it or patching the
existing code. I saw nothing in there that exported any libiconv* 
function/variable.
And when you ran the script as it was, it produced the exact same output that 
was in
the repo. I don't think the iconv* symbols were supposed to be there at all. 
Instead
I think other libs were supposed to statically link those functions. The
-DUSE_LIBICONV_DLL allows you to use iconv.dll if you have it available, 
otherwise it
uses a default implementation.

Original comment by david.g.hoyt on 16 Apr 2010 at 3:56

[GoogleCodeExporter]

If I open inconv.dll from r386
(http://code.google.com/p/ossbuild/source/browse/trunk/Shared/Build/Windows/Win3
2/bin/iconv.dll?spec=svn386&r=386)
with Dependency Walker I can see these symbols exported:
_libiconv_version
iconv
iconv_close
iconv_open
libiconv
libiconv_close
libiconv_open
libiconv_set_relocation_prefix
libiconvctl
libiconvlist
locale_charset

That makes this lib comptabile with both implementations. This way a dll 
linking to
iconv and using iconv_open and another dll using libiconv_open can both use the 
same
iconv.dll.

Original comment by ylatuya on 17 Apr 2010 at 1:33

[GoogleCodeExporter]

The readme in win_iconv says:
"I just added some small bits:
the trivial iconv.h header, the win_iconv_dll.c wrapper that makes it
possible to build win_iconv.c into a DLL that has the same API and ABI
as GNU libiconv, the Makefile."

The tricky part is in:

#if defined(USE_LIBICONV_DLL)
static int
libiconv_iconv_open(rec_iconv_t *cd, const char *fromcode, const char *tocode)

If USE_LIBICONV_DLL is not defined this function will never be exported, and 
this
function does the mapping from libiconv to iconv 

Original comment by ylatuya on 17 Apr 2010 at 1:50

[GoogleCodeExporter]

I used what you had defined w/ -DUSE_LIBICONV_DLL and it was not exporting 
those 
symbols. You typically need to specify an external symbol with dllexport. Run 
that 
portion of the script and see if you get a dll w/ all the symbols you mentioned.

As I was saying, I believe win_iconv is meant to be statically linked meaning 
there 
should be no iconv.dll at all. However, if you have the gnu one, it will pick 
it up 
and use it. Please see the description about it here under "About win_iconv":

http://www.gtk.org/download-windows.html

If you want to use win_iconv_dll, I believe that's separate and I'm unsure 
where the 
source is -- but that's not what's in our packages.

Original comment by david.g.hoyt on 17 Apr 2010 at 7:11

[GoogleCodeExporter]

What the about says is the win_iconv is statically linked to GLib and thus is 
not
needed, but if you read the iconv.dll about it says:
"This can either be the GNU libiconv iconv.dll, or the identically named
win_iconv_dll one which obviosuly is intented to be a drop-in replacement."
So both of them can be used as a dynamic dll.
When win_iconv is compiled with the USE_LIBICONV_DLL, it will export libiconv*, 
or at
least this is what I got in r386 and:
"* If $WINICONV_LIBICONV_DLL environment variable was defined, win_iconv

 * loads the specified DLL dynamically and uses it.  If loading the DLL

 * or iconv_open() failed, falls back to internal conversion.
"
Since this env variable is not defined it will fallback to the internal 
conversion.

Anyway the problem we are facing is much simpler to solve. Since win_iconv is 
for
static linking we should use gnu_iconv. The problem we have currently is that 
our
iconv.dll exports iconv* and the gstreamer binaries binaries are expecting an
iconv.dll exporting iconv* funtions, but other FOSS projects like GTK are 
expecting
an iconv.dll exporting libiconv*, and therefore our binaries are incompatibles 
with
other projects. So waht we are doing wrong is using win_iconv to generate a 
dynamic
dll and using gnu_iconv would solve it.

Original comment by ylatuya on 18 Apr 2010 at 7:45

[GoogleCodeExporter]

As I've been saying, **compile it yourself** -- it's not exporting those 
functions 
using the gcc 4.4.3 that I'm using. I see in the source where it has the 
functions, 
but I also don't see an extern C anywhere nor a dll export. Therefore it makes 
sense 
that it's not exporting the functions. If you modified the source to export it, 
then 
a patch needs to be provided.

The GTK folks say glib and related libs will be using win iconv so we should 
continue to use it.

I fail to see after reading your comment how what I said before was in any way 
incorrect or a misunderstanding. I know and understand what other FOSS projects 
expect and what I'm telling you is that the script you modified is in some way 
wrong 
or the compiler I'm using for some reason does not pick up the exports because 
the 
required functions are not being exported as per the original intent of r386.

Please examine the source in the package and the output after compiling it.

Original comment by david.g.hoyt on 19 Apr 2010 at 9:06

[GoogleCodeExporter]

I would be happy if someone else could compile the iconv portion and confirm 
that 
I'm not crazy. :) Well I suppose I could still be crazy, but at least not about 
this 
issue. :p

Original comment by david.g.hoyt on 19 Apr 2010 at 9:09

[GoogleCodeExporter]

I must be the crazy one :) I have misunderstood all the win_iconv thingy and 
indeed
it's impossible that those symbols where exported with the current code. I 
don't know
what the hell I did to build this dll :/
win_iconv is supposed to be be linked statically (as glib do) and indeed the
USE_LIBCONV_DLL flag won't export any of those symbols but will try to load an
existing inconv.dll an map iconv_* to libiconv_* to use gnu iconv for the 
conversion. 
From my point of view we have 2 options:
  * use win_iconv and link it statically
  * use gnu_iconv to build iconv.dll
What do you think?

Original comment by ylatuya on 19 Apr 2010 at 10:31

[GoogleCodeExporter]

For instance
http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/win-iconv-dll_tml-200
90213_win32.zip
exports:
_libiconv_version
libiconv
libiconv_close
libiconv_open
libiconv_set_relocation_prefix
libiconvctl
libiconvlist
locale_charset

Original comment by ylatuya on 19 Apr 2010 at 10:32

[GoogleCodeExporter]

I'm not crazy either ;)
http://win-iconv.googlecode.com/svn-history/trunk/iconv.def

Original comment by ylatuya on 19 Apr 2010 at 10:37

[GoogleCodeExporter]

Okay, I have an updated installer w/ the python fixes. Please validate that it 
does 
the job. You'll notice that it installs it in the C:\Program Files\OSSBuild\... 
folder instead of C:\Python25\. That's due to the feature selection in the MSI 
package and working it out right now would take too much time and I'd like to 
roll 
out this release ASAP. We can get it working for the next release perhaps. At 
any 
rate, if you go into the install folder, you'll see that you can copy 
everything you 
need from the <Install Folder>\sdk\bindings\python\v2.5\ directly into 
C:\Python25\.

I know it's not ideal, but for now I'm setting the PYTHONPATH env. variable. 
That 
may end up being the most intuitive thing to do, though, b/c a lot of users 
might 
not know or even think to set the path to C:\Python25\ if that feature were 
even 
available.

I also prefer to keep the SDK install without any selectable folder b/c it 
automatically detects and knows where to install based off of the 
previous "complete" install.

Anyway, you can download and test the packages here:

http://code.google.com/p/ossbuild/downloads/detail?name=GStreamer-WinBuilds-GPL-
x86.zip

Original comment by david.g.hoyt on 24 Apr 2010 at 8:03

[GoogleCodeExporter]

Also, from what I can tell, the farsight binding should be lib/site-
packages/farsight/farsight.pyd

Is that correct?

Original comment by david.g.hoyt on 24 Apr 2010 at 8:06

[GoogleCodeExporter]

I will try it in a couple of ours, so that we can release tomorrow.

Original comment by ylatuya on 24 Apr 2010 at 11:53

[GoogleCodeExporter]

Someone asked about the fluendo plugins. What should we do? Shouldn't Fluendo 
itself 
be the ones to provide them? If they're looking at integrating w/ us anyway, 
then 
they can easily enough write an intaller that locates our install directory and 
then 
installs their plugins.

But I don't think we should be building their plugins.

Just my $0.02.

Original comment by david.g.hoyt on 24 Apr 2010 at 7:22

[GoogleCodeExporter]

There is small issue in the bindings installer. It should use
Main\GStreamer\Windows\Build\Bindings\Python\pygst.py and not the one included 
in the
sources

Original comment by ylatuya on 24 Apr 2010 at 7:55

[GoogleCodeExporter]

I think we should not include the Fluendo plugins either. 
Some time ago Fluendo had 3 free plugins (mpeg demuxer mpeg muxer and 
mp3decoder).
Currently all the improvements in the mpeg muxer/demuxer are available upstream 
and
there is no need to include them. I think Fluendo hasn't made a public release 
for
years, and those plugins should be considered obsolete.
So agreed, we shouldn't include them.

Original comment by ylatuya on 24 Apr 2010 at 8:04

[GoogleCodeExporter]

There is another issue with the Python installer. PYTHONPATH should point to 
where
'pygst.py' has been deployed. The reason why I wouldn't set this variable is 
that you
would have to include both the python25 and the python26 folders. Depending on 
which
version of python you are using it will load the wrong the pygst bindings. 

Original comment by ylatuya on 25 Apr 2010 at 6:19

[GoogleCodeExporter]

I understand that, but what's the most likely version of python that people 
will be 
using? I figure w/ python being in the 3.1 series, that python 2.6 would be a 
prudent stable version to support. The installer by default is installing the 
2.6 
bindings. v2.5 is still available in the <Install 
Path>\sdk\bindings\python\v2.5\ 
directory, however, if a user needs it.

I can't see us trying to maintain any number of python versions. That becomes 
really 
difficult to manage. It wouldn't be such a big deal, I don't think, if the 
python 
folks didn't keep changing the name of the python shared library with every 
minor 
release.

Perhaps in the future we can enhance the installer to detect python 
installations 
and allow the user to select where they want the bindings installed. But not 
for 
this release.

On another note -- shall I delete the fluendo source in the repo.?

Original comment by david.g.hoyt on 26 Apr 2010 at 3:17

[GoogleCodeExporter]

>On another note -- shall I delete the fluendo source in the repo.?
We could delete the sources but I wouldn't delete the project files in case 
some one 
would want to use it.

Original comment by ylatuya on 26 Apr 2010 at 7:23

[GoogleCodeExporter]

Done.

Original comment by david.g.hoyt on 26 Apr 2010 at 8:41

[GoogleCodeExporter]

There's not a reason to leave the project files, b/c if someone needs them, 
they can 
go back into the repo.'s history and pull them out.

Original comment by david.g.hoyt on 26 Apr 2010 at 11:22

[GoogleCodeExporter]

I think it's time to do the release even w/ the known issues. The ones I know 
about 
are:

* Speex crash
* rtph264pay crash
* svq1 crash

BTW, gstreamer has a new release so we'll need to upgrade ASAP and come out w/ 
a 
point release (0.10.6.1?).

Original comment by david.g.hoyt on 1 May 2010 at 7:52

[GoogleCodeExporter]

If RC02 seems acceptable I'll change the file names and release that.

Original comment by david.g.hoyt on 1 May 2010 at 7:54

[GoogleCodeExporter]

I think it's time to release!!!!!
I think no more changes were added after RC02 so we should just rename it :D

Kudos to you!

Original comment by ylatuya on 2 May 2010 at 3:15

[GoogleCodeExporter]

Kudos to everyone. :)

Original comment by david.g.hoyt on 3 May 2010 at 3:52

[GoogleCodeExporter]

Time to close this out.

Original comment by david.g.hoyt on 6 May 2010 at 7:38

• Changed state: Done