tuituji/ossbuild

Automatically exported from code.google.com/p/ossbuild

ossbuild's Issues

Audio recording issues on Windows

Note: this post is a summary and follow up to the gstreamer mailing list post 
titled "Distorted audio capture on 
Vista" (http://sourceforge.net/mailarchive/forum.php?
thread_name=[e-mail]&forum_na
me=gstreamer-devel).

Following command produces a short recording of the microphone input:

gst-launch-0.10 dshowaudiosrc num-buffers=400 ! audioconvert !
audioresample ! faac ! mp4mux ! filesink location=test.mp4

 I have different results depending on the test machine:

- Macbook Pro running Windows 7: OK
- Acer laptop running Vista: jerky and distorted audio
- 2nd Acer laptop running Vista: jerky and distorted audio
- PC running Windows XP: OK

To ensure that it isn't simply a hardware problem on the Vista laptops I made a 
recording using the vendor built-
in webcam utility. It produced a fine recording which makes me think that 
something is wrong with the 
dshowaudiosrc component.

My hopes are currently on directsoundsrc. This element is not included in the 
current GStreamer WinBuild. After 
adding it locally I can verify that it works find on the Windows XP PC. 
However, I still haven't verified if it 
works on the Vista laptops!! (I'll test Monday)

The patch is included as an attachment. Before applying the patch you need to 
copy the "bad" directsoundsrc source 
files the "good" directsound plugin:

cp Main/GStreamer/Source/gst-plugins-bad/sys/directsound/gstdirectsoundsrc.c 
Main/GStreamer/Source/gst-plugins-
good/sys/directsound
cp Main/GStreamer/Source/gst-plugins-bad/sys/directsound/gstdirectsoundsrc.h 
Main/GStreamer/Source/gst-plugins-
good/sys/directsound


Grts,
Francis

Original issue reported on code.google.com by [email protected] on 6 Feb 2010 at 5:20

Attachments:

• directsound.patch

Pygst installer

We should provide for next releases a separate installer for the Python
bindings. The best solution would be to install the bindings in  python's
installation paht, like pygtk does. This path can be retrieved from the
registry reading the following key:
HKLM\Software\Python\PythonCore\XY\InstallPath
(XY is the python version)

Original issue reported on code.google.com by ylatuya on 25 Apr 2010 at 6:25

Libraries prefix

Hi,
I saw libraries have now a prefix lib-ossbuild-* :/
Any reason for that? It's not unix compilant and '-lgstreamer-0.10' wont work 
anymore for example. Many FOSS are using our libraries and the naming scheme 
should be respected.

Original issue reported on code.google.com by ylatuya on 21 Jan 2010 at 10:42

gstreamer-sharp has incorrect library names resulting in EntryPointNotFoundExceptions

Please see this thread for more information:

https://forja.rediris.es/forum/forum.php?thread_id=5147&forum_id=1624


The basic error reported was:

I'm getting a System.EntryPointNotFoundException in gstreamer-sharp.dll.

I started building the samples that came with the gstreamer bindings
tarball. This particular one TransformSample.cs, reproduced here:
http://pastebin.com/mKTEWUpS.

When the exception occurs, Visual Studio opens the file VideoUtil.custom,
reproduced here: http://pastebin.com/xsn6jd5E, and points to line 30.

Here is the stack trace:

gstreamer-sharp.dll!Gst.Video.VideoUtil.FormatToTemplateCaps(Gst.Video.VideoForm
at
fmt = BGRX) Line 30 C#
TransformSampleDemo.exe!TransformSample.Register() Line 19 + 0x20 bytes C#
TransformSampleDemo.exe!TransformSample.Main(string[] args = {string[0]})
Line 103 + 0x5 bytes C#
[Native to Managed Transition]
[Managed to Native Transition]
mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile,
System.Security.Policy.Evidence assemblySecurity, string[] args) + 0x3a bytes
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.Hosti
ngProcess.HostProc.RunUsersAssembly()
+ 0x2b bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object
state) + 0x66 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionCon
text
executionContext, System.Threading.ContextCallback callback, object state)
+ 0x6f bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes

I used dumpbin to inspect the exports from gstreamersharpglue-0.10.dll and
the function that is called on that line is not exported. This is the list
of modules exported by gstreamersharpglue-0.10.dll:
http://pastebin.com/DKk5MjTa

Original issue reported on code.google.com by david.g.hoyt on 18 Mar 2010 at 8:39

Testing plan

Hi,

Before each release we are used to preform some test by our own praying not
to find in the regression :) That's why we should have a testing plan, at
least to do simple checks for the most conflictive components (like the
dshow components, ffmpeg, auto{video|audio}{src|sink}, some decoders, etc...). 
We should also have a media library with the most common formats to check
that all the formats supported by the old release are also supported with
the new one. 
I think a wiki page for that should be enough

Original issue reported on code.google.com by ylatuya on 17 Mar 2010 at 9:36

Python bindings installer

Hi David,
The Python bindings installer is useless in the current state as some files 
are missing. Please take a look at 
http://code.google.com/p/ossbuild/source/browse/trunk/Packaging/Win32/Pytho
n/python_bindings.iss?r=397 to see how the bindings should be deployed.
Also, do not use this  naming scheme lib$(var.PREFIX)audio.pyd for python 
binaries.
In Python you will do:

import pygst
pygst.require('0.10')
import gst.audio

That will look for  gst-0.10/gst/audio.pyd

I'm fixing it.

Original issue reported on code.google.com by ylatuya on 21 Jan 2010 at 11:01

Unexpected x264 header

This is happening also under Linux when using a new version of x264 (build
greater than 85 apparently).
When trying to use x264enc: 

gst-launch.exe  ksvideosrc ! ffmpegcolorspace ! x264enc! ...

the error is: "Unexpected x264 header"...
I am using GStreamerWinBuild-0.10.6.exe.

Original issue reported on code.google.com by [email protected] on 12 May 2010 at 1:37

Crash with mpeg2dec

When mpeg2dec plugin is used, gst crashes. Using the FFmpeg mpeg2 decoder 
works fine.

For now, the fix has been to exclude this plugin + associated dependencies 
from the installer. But it should be addressed.

The following video, for example, causes the mpeg2dec plugin to crash:

http://samples.mplayerhq.hu/MPEG2/dvd.mpeg

Original issue reported on code.google.com by david.g.hoyt on 15 Mar 2010 at 8:45

GStreamer Core 0.10.23, Base Plugins 0.10.23

I think we should update those module, mostly because I'm trying to add the
the python bindings (0.10.15) and there is some changes in the 'audio' and
'interfaces' libs.
If you don't mind I'll do it as soon as you give me your agreement

Original issue reported on code.google.com by ylatuya on 12 May 2009 at 6:37

Adding non-LGPL support

We should create a new solution called GStreamer-GPL with a configuration
called Release_GPL (to output the binaries to a diferent folder that the
release one and avoid mixing both of them) to build the plugins that
depends on GPL libraries.

We should also build ffmpeg with GPL support and call the libraries
libavcodec-GPL.lib, for example. This way we can have two ffmpeg versions,
the LGPL one and the GPL one. 

We also need to build xvidcore, liba52, liblame, libmad, libmpeg2, dvdnav
and dvdread. 

We need to add the fluendo plugins and the remaining plugins in ugly.

What do you think?

Original issue reported on code.google.com by ylatuya on 2 May 2009 at 6:54

libiconv doesn't export symbols in the Linux way

libiconv is actually exporting symbols like 'iconv', while it should be
exporting them as 'libiconv'.
https://forja.rediris.es/forum/message.php?msg_id=222483

Original issue reported on code.google.com by ylatuya on 17 Dec 2009 at 9:23

Flex tool issue

I'm having problems with the flex tool when generating parse.l both from 
VS and the command line:
1>flex: fatal internal error, exec failed

E:\ossbuild\Tools>flex -P_gst_parse_yy -o"E:\ossbuild\Build\Windows\Win32
\Debug
\obj\gstreamer\common\parse.c" "e:\ossbuild\Main\GStreamer\Source\gstreamer
\gst\
parse\parse.l"
flex: fatal internal error, exec failed

Original issue reported on code.google.com by david.g.hoyt on 27 Apr 2009 at 3:10

Adding git repositories to the build system for GStreamer sources

I'm thinking about adding the git repositories to the build system for the
GStreamer sources, which is basically adding to subversion the .git folder.

That would ease much of our daily work:
 * Syncing with an upstream release/tag: git chechout RELEASE_0_10_28
 * Applying upstream patches commited after the release: git cherry-pick
93ac34b3
 * Managing patches in way that that they can be submitted to bugzilla in
git format: git format-patch HEAD^

Original issue reported on code.google.com by ylatuya on 21 Mar 2010 at 1:39

Dshow source wrapper not working anymore

Julien Isorce did some refactoring to dshowvideosrc and it's not working
anymore... For this release I have included the old
libgstdshowsrcwrapper.dll which works.
I will open a bug report for this in gstreamer's bugzilla

Original issue reported on code.google.com by ylatuya on 8 Dec 2009 at 6:25

"GStreamer (Express Edition).sln" missing libgstopengl pluging

The latest GStreamer (Express   Edition).sln from
http://ossbuild.googlecode.com/svn/trunk/ is missing the build for
libgstopengl pluging

Can you please add to LGPL and GPL Building environment.

Thanks

Nick

Original issue reported on code.google.com by [email protected] on 5 May 2010 at 5:12

Opera v10.50+ Build

A build of it that works with Opera v10.50+ should be made.

Original issue reported on code.google.com by [email protected] on 20 Mar 2010 at 7:54

Source and sink plugins' rank

We need to agree in the rank for some plugins.

For windows we have actually 2 video sink plugins:
Directdraw sink: Less performant but implements the XOverly Expose()
function. That alloww, for example, refresh the current frame after a seek
when the pipeline is paused
Dshowvideosink: Better performance but doesn't update frames after a seek

Audio sinks:
directsoundsink: The best one
waveformsink: People has complained about this plugin in the forum for
example using the following pipeline: dshowaudiosink ! audioconvert !
waveformsink, which works with the directsoundsink

Audio sources:
dshowaudiosrc: Doesn't outputs a clean stream in Windows 7
directsoundsink: Seems to be working fine 

Video sources:
Dshowvideosrc: Needs to be backported, the one from the last release is not
working anymore
winks: I haven't tested it on Vista/7, but it might not work.

Original issue reported on code.google.com by ylatuya on 11 Feb 2010 at 7:42

Unresolved external symbol __CRT_RTC_INITW referenced in function __RTC_InitBase

I get this error at linking to the CRT:

Error   109 error LNK2019: unresolved external symbol __CRT_RTC_INITW
referenced in function __RTC_InitBase   runtmchk.lib

Original issue reported on code.google.com by ylatuya on 29 Apr 2009 at 3:06

RTSPsrc sends unicode characters. It doesn't conform the RTSP standatd.

This element sends unicode characters in the headers, at least in the Date: 
header.
The bug was patched: https://bugzilla.gnome.org/show_bug.cgi?id=617636
It would be good to have this patch

Original issue reported on code.google.com by [email protected] on 5 May 2010 at 6:45

No playing sound in FLV file

In previous version was no problem with this file.

Original issue reported on code.google.com by [email protected] on 13 May 2010 at 6:33

Attachments:

• video_test.flv

Maintaining patches for gstreamer

Hi David,
I'm happy to see you comiting again ;)
I saw that I reverted your fix against gstsoup. It's actually pretty hard
to track all the changes we have in the gstreamer-related source files.
That's why we should keep those patches in a separated folder, at least as
a reminder for each upstream merge.

Original issue reported on code.google.com by ylatuya on 25 Nov 2009 at 9:12

Generate should be called after the first Build

The Generate.bat script should be called after the very first build for two
reasons
1)grammar.y looks for ../gstconfig.h (gstreamer/gst/gstconfig.h) which is
copied by the script to gstreamer/gst 
2)The script generates some files needed to compile the Python bindings.

I think adding a step in the root Readme.txt is enough

5. PyGobject (2.14)
       a. Download from
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/
6. Run ossbuild/Main/GStreamer/Generated.bat

What do you think? 

Original issue reported on code.google.com by ylatuya on 16 Jun 2009 at 12:54

Linker issue with ossbuild

Hello, 

I'm using your build system under VS2005 (2005 is preferred as so many 
other things depend on it). I converted your 2008 projects to load in 
th2005, and while the project files in Libraries.sln fail to load, 
GStreamer.sln works, which is fine, as I already have all the components I 
need from Libraries.sln compiled separately, anyway. I followed the 
instructions in your read me and GStreamer and all the plugins (except 
pango, which seems to fail due to a typo somewhere) compile. 

The issue comes up when I try to link my app using the compiled libraries. 
Here's the log: 

http://pastebin.com/f5cdfe19d

It looks like it's missing a library, but all the .lib files are there and 
correctly listed in Visual Studio, and other GStreamer functions in my 
source don't cause an error. 

I don't have much experience with GStreamer compiling. Do you have any 
idea what's going on? 


1>--- PASS ---
1>Same
1> 
1> 
1>Linking...
1>llmedia.lib(llmediaimplgstreamer.obj) : error LNK2019: unresolved 
external symbol _gst_debug_set_default_threshold referenced in 
function "public: virtual bool __thiscall 
LLMediaImplGStreamer::setDebugLevel(enum LLMediaBase::EDebugLevel)" (?
setDebugLevel@LLMediaImplGStreamer@@UAE_NW4EDebugLevel@LLMediaBase@@@Z)
1>llmedia.lib(llmediaimplgstreamer.obj) : error LNK2019: unresolved 
external symbol _gst_debug_category_get_name referenced in 
function "public: static void __cdecl LLMediaImplGStreamer::gstreamer_log
(struct _GstDebugCategory *,enum GstDebugLevel,char const *,char const 
*,int,struct _GObject *,struct _GstDebugMessage *,void *)" (?
gstreamer_log@LLMediaImplGStreamer@@SAXPAU_GstDebugCategory@@W4GstDebugLeve
l@@PBD2HPAU_GObject@@PAU_GstDebugMessage@@PAX@Z)
1>llmedia.lib(llmediaimplgstreamer.obj) : error LNK2019: unresolved 
external symbol _gst_debug_message_get referenced in function "public: 
static void __cdecl LLMediaImplGStreamer::gstreamer_log(struct 
_GstDebugCategory *,enum GstDebugLevel,char const *,char const 
*,int,struct _GObject *,struct _GstDebugMessage *,void *)" (?
gstreamer_log@LLMediaImplGStreamer@@SAXPAU_GstDebugCategory@@W4GstDebugLeve
l@@PBD2HPAU_GObject@@PAU_GstDebugMessage@@PAX@Z)
1>llmedia.lib(llmediaimplgstreamer.obj) : error LNK2019: unresolved 
external symbol _gst_debug_add_log_function referenced in 
function "public: static bool __cdecl LLMediaImplGStreamer::startup(class 
LLMediaManagerData *)" (?
startup@LLMediaImplGStreamer@@SA_NPAVLLMediaManagerData@@@Z)
1>llmedia.lib(llmediaimplgstreamer.obj) : error LNK2019: unresolved 
external symbol _gst_debug_remove_log_function referenced in 
function "public: static bool __cdecl LLMediaImplGStreamer::startup(class 
LLMediaManagerData *)" (?
startup@LLMediaImplGStreamer@@SA_NPAVLLMediaManagerData@@@Z)
1>llmedia.lib(llmediaimplgstreamer.obj) : error LNK2019: unresolved 
external symbol _gst_debug_log_default referenced in function "public: 
static bool __cdecl LLMediaImplGStreamer::startup(class LLMediaManagerData 
*)" (?startup@LLMediaImplGStreamer@@SA_NPAVLLMediaManagerData@@@Z)
1>llmedia.lib(llmediaimplgstreamervidplug.obj) : error LNK2019: unresolved 
external symbol _gst_debug_log referenced in function "int __cdecl 
gst_slvideo_set_caps(struct _GstBaseSink *,struct _GstCaps *)" (?
gst_slvideo_set_caps@@YAHPAU_GstBaseSink@@PAU_GstCaps@@@Z)
1>llmedia.lib(llmediaimplgstreamervidplug.obj) : error LNK2001: unresolved 
external symbol __imp____gst_debug_min
1>llmedia.lib(llmediaimplgstreamervidplug.obj) : error LNK2019: unresolved 
external symbol __gst_debug_register_funcptr referenced in function "void 
__cdecl gst_slvideo_class_init(struct _GstSLVideoClass *)" (?
gst_slvideo_class_init@@YAXPAU_GstSLVideoClass@@@Z)
1>llmedia.lib(llmediaimplgstreamervidplug.obj) : error LNK2019: unresolved 
external symbol __gst_debug_category_new referenced in function "int 
__cdecl plugin_init(struct _GstPlugin *)" (?
plugin_init@@YAHPAU_GstPlugin@@@Z)
1>C:\imprudence\linden\indra\build-vc80\newview\Release\heritagekey-
bin.exe : fatal error LNK1120: 10 unresolved externals
1>Build Time 28:49
1>Build log was saved at "file://c:\imprudence\linden\indra\build-vc80
\newview\heritagekey-bin.dir\Release\BuildLog.htm"
1>heritagekey-bin - 11 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Original issue reported on code.google.com by david.g.hoyt on 14 Apr 2009 at 3:50

0.10.6 Release

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

Java example review

I'd like for someone else to check out the java example on the downloads 
page and verify that it works fine on their machine (as far as gstreamer 
itself runs) for various versions of windows. It should only work on 32-
bit JREs, but should fail gracefully on other platforms.

The example attempts to extract gstreamer at runtime and load it on-the-
fly. This should enable webstart Java gstreamer apps.

Original issue reported on code.google.com by david.g.hoyt on 17 Feb 2010 at 1:42

DirectDraw Video Sink Memory Leak

I haven't tracked down the cause yet, but directdrawsink causes an approx. 
300-400 KB memory leak every time a transition from PLAYING -> NULL -> 
PLAYING occurs.

Original issue reported on code.google.com by david.g.hoyt on 24 May 2010 at 2:57

SDK PDBs

We need to cleanup the PDBs and include them in the SDK for debugging 
purposes. Right now they're not being put in a sane location or some 
projects have the wrong settings and are overwriting the correct ones b/c 
their PDB name is off.

Original issue reported on code.google.com by david.g.hoyt on 26 Apr 2010 at 11:19

AppSink?

There doesn't appear to be support for the module AppSink in the latest build?

** Message: don't know how to handle audio/mpeg, mpegversion=(int)1,
mpegaudioversion=(int)1, layer=(int)3, rate=(int)44100, channels=(int)2,
parsed=(boolean)true
Exception in thread "bpmthread" java.lang.IllegalArgumentException: No such
Gstreamer factory: appsink
        at org.gstreamer.ElementFactory.makeRawElement(ElementFactory.java:174)
        at org.gstreamer.ElementFactory.make(ElementFactory.java:166)
        at armadilloUI.BPM.TestRun(BPM.java:170)
        at armadilloUI.BPM.run(BPM.java:287)
        at
armadilloUI.ImportSongBPMThread.calculateBPM(ImportSongBPMThread.java:116)
        at armadilloUI.ImportSongBPMThread.run(ImportSongBPMThread.java:85)
        at java.lang.Thread.run(Thread.java:619)

This is an essential part of our java (GStreamer-based) program - it worked
previously with the previous version of WinBuilds so is it just a library
you've missed out including this time around?

Original issue reported on code.google.com by [email protected] on 7 May 2010 at 6:13

Add missing projects

After this update I did not add the new projects to the main solution, can
do it? (I still does not have the Pro version :( )
http://code.google.com/p/ossbuild/source/detail?r=345

Original issue reported on code.google.com by ylatuya on 4 Dec 2009 at 12:29

Add liborc dependency

GStreamer is porting all its oil code to orc. It has a fallback to C, but orc 
speeds up many critical functions with arrays using assembly optimized code. We 
should add this new dependency and make use of it.

Original issue reported on code.google.com by ylatuya on 27 Jun 2010 at 9:10

The installer should delete the old registry

I opened this issue to keep track for a future release.
The gstreamer's registry is usually invalid from one release to another and
needs to be regenerated. The installer should delete the folder
.gstreamer-0.10 folder  to force a rebuild of the registry

Original issue reported on code.google.com by ylatuya on 24 Apr 2010 at 6:59

gst-launch playbin2 crashes on opening files, at least, mpg, avi and mp4

What steps will reproduce the problem?
1. Build and install the latest SVN OSSBuild (GPL)
The build was on MS Visual Studio 2008 SP1.
OS is Windows XP.

2. run 
gst-launch playbin2 uri=file:///d:/path/to/file

What is the expected output? What do you see instead?
I was expecting a window with moving pictures and a sound in my headphones.
I've got an offer to start a MSVS debugger instead.

The crash was at the same source line, with the same addresses, I was reporting 
already.
https://forja.rediris.es/forum/message.php?msg_id=222788

I also tried copying libmpeg2 DLLs both from the previous GStreamer version and 
built by 
myself using mingw32 package from the Ubuntu linux (which contains gcc 
4.2.1-sjlj) - same 
result.

Original issue reported on code.google.com by [email protected] on 17 Mar 2010 at 10:16

New release

I was waiting for the c# bindings for releasing GStreamer-WinBuild-0.10.5,
what do you think?

Original issue reported on code.google.com by ylatuya on 4 Dec 2009 at 12:13

gst_element_query_duration always returns false.

OSSBuild, updated from trunk, svn rev. 545
"Rebuild all" in MSVS 2008 SP1.
All previous versions of the GStreamer are removed, the environment variables 
are cleared 
before install.

gst_element_query_duration always returns false in my app.

I tested it on avi, mpg, mp4, mp3 and ogg files.

Original issue reported on code.google.com by [email protected] on 19 Mar 2010 at 9:24

Iso Codes soft dependencies

From the 'good' release announce in the ML:
"Note to packagers: this release adds a new soft-dependency on the
iso-codes package."
I believe in deploying the iso-codes xml files under the
share/xml/iso-codes/ folder.
Can you handle it?

Original issue reported on code.google.com by ylatuya on 11 Feb 2010 at 11:13

Speex crash

Speex crash. From
https://forja.rediris.es/forum/forum.php?thread_id=5250&forum_id=1624:

I am getting crash when launching pipe with
speexenc!oggmux!oggdemux!speexdec...

I tried it on v0.10.6 winbuild of the gstreamer which seems to be the
latest available at the moment.

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

New GTK+ bundle should be included.

I was unable to run the gstreamer's example 
$OSSBUILD\Main\GStreamer\Source\gst-plugins-base\tests\examples\seek\seek.c 
in windows with the existing GTK+.

The compilation in Visual Studio 2008 was successful, but when I tried to run 
it, the system 
complained about missing entry point gdk_window_ensure_native in 
libgtk-win32-2.0-0.dll.
Dependency walker (http://www.dependencywalker.com/) also highlighted this 
function (and 
two more) with red, in its window, listing parent imports.

I have downloaded the fresh gtk+ bundle  from
http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.20/gtk+-
bundle_2.20.0-20100406_win32.zip
and have simply replaced files in the Gstreamer installation directory (both 
DLLs and SDK) with 
ones from that bundle. 

Then everything has become OK.

Original issue reported on code.google.com by [email protected] on 27 Apr 2010 at 8:09

WinBuilds 0.10.7 release

New upstream releases are comming!
I'll take care of updating all the gstreamer modules in the next week.
We should start thinking on the next release :)

Original issue reported on code.google.com by ylatuya on 27 Jun 2010 at 8:30

Generate.bat should be called in a project inside the main solution

In grammar.tab.c grammar.tab.h and parse.c the some values varies depending
on the installation path:
#line 637 "C:\\David\\Development\\OSSBuild\\Main.....
Besides, it's needed for the Python bindings as the file
'gstversion.override' and 'gst-pbutils.0.10.23' needs to be generated and
copied to the python sources dir.
Therefore, Generated.bat should be the first project to be run.

Original issue reported on code.google.com by ylatuya on 13 May 2009 at 6:56

Adding and external dependency that cannot be built using MinGW

I need to add libnice for the Farsight2's Nice transmitter. 
This library cannot be built using mingw (I already asked in the nice
mailing list). I have the VS project, but I don't really know where to
place it, and how to proceed integrate it in the build system...

Original issue reported on code.google.com by ylatuya on 5 May 2009 at 9:45

mpeg2convert.lib is really a copy of mpeg2.lib

The files mpeg2convert.lib and mpeg2.lib are identical in v0.10.6 GPL

Inspection reveals that mpeg2convert.lib is really just an incorrectly
named copy of mpeg2.lib. As a consequence, it is not possible to link to
the mpeg2convert function in libmpeg2convert-0.dll

Original issue reported on code.google.com by [email protected] on 5 May 2010 at 5:26

New GStreamer Releases

GStreamer will be releasing an update to good, bad, etc. here soon. They 
have a pre-release on git. How soon should we move to the release? And who 
would like to take charge of doing the update?

Original issue reported on code.google.com by david.g.hoyt on 1 Feb 2010 at 5:59

rtph264pay/rtph264depay crash

What steps will reproduce the problem?
1. gst-launch-0.10.exe --gst-plugin-path=. ksvideosrc ! ffmpegcolorspace !
x264enc bitrate=300 ! rtph264pay ! rtph264depay  ! ffdec_h264 !
ffmpegcolorspace ! glimagesink sync=false
2.
3.

What is the expected output? What do you see instead?
It crashes in avcodec-
6AF4A3CE   8B01             MOV EAX,DWORD PTR DS:[ECX]
after a while.
It runs fine in the dgb debugger!!!

What version of the product are you using? On what operating system?
up-to-date ossbuild

Please provide any additional information below.
The pipe without rtph264pay ! rtph264depay works fine.

Original issue reported on code.google.com by [email protected] on 26 Nov 2009 at 5:00

Project dependencies

We should set-up the projects dependencies...

If a new user fetches the build system and tries to build the solution he
will get a bunch of errors, because projects must be built in order.

The "gstreamer" project should depend on "common",to generate all the
enums, marshallers and headers.

All the gst-libs should depend on the "gstreamer pproject"

All the enum's generation should be done by the "common" project. If not,
the first build always fails because the enum types files are not generated.

All the plugins that depends on a gstreamer library (e.g. gstrtp )should 
depend on the library's project, because it copies headers used by the
plugins to the output dir.

The idea is to build the entire Solution with one click.

Original issue reported on code.google.com by ylatuya on 2 May 2009 at 6:41

Just a simple thank you

This isn't really an issue. 

Just wanted to thank you for the credits: http://www.gstreamer-
winbuild.ylatuya.es/doku.php?id=credits 

I appreciate it. (c:

Original issue reported on code.google.com by david.g.hoyt on 8 Jul 2009 at 8:07

Provide svn co and/or zip of gst binaries

You provide some libraries for download via
http://code.google.com/p/ossbuild/source/browse/trunk#trunk/Shared/Build/Windows
/Win32/
but the GStreamer libraries/binaries aren't available like that, are they?

It would be useful to be able to `svn co` them or download a zip containing
them.

Original issue reported on code.google.com by [email protected] on 22 May 2010 at 10:31

DirectShow Video Sink Thread Leak

From r640 comments:

Open and close windows a lot by doing a PLAYING -> NULL -> PLAYING 
transition and you'll quickly end up with hundreds of threads.

It appears that 1 thread is frozen on line 341: CoUninitialize ();

Others are frozen on line 259: while (sink->comInitialized);

It would seem that there's an issue with COM uninitialization that's 
causing it to block and therefore not dropping to line 343 which sets the 
flag other threads are waiting on to exit.

Original issue reported on code.google.com by david.g.hoyt on 25 May 2010 at 7:17

0.10.6 Release

Hi,
I think we are ready to start planning the next release. 
The tests I have done so far have been successful. All the sinks and source 
plugins works well after fixing the bug in the dshowvideosrc plugin. I have 
also tested AVI, MOV/MP4, OGG, ASF/WMV and MPG containers as well as MP3, 
AAC, Vorbis and WMA audio codecs and MPEG2, MPEG4/xvid/divx, Theora, WMV and 
H264 video codecs. We should definitivly have a media library for not missing 
any one, but should be discussed in the testing wiki page.

What I haven't been able to test is the installer. Could you please upload a 
new one with the last changes so I can check if everything is ok? 

Original issue reported on code.google.com by ylatuya on 22 Mar 2010 at 11:31

rsvg and gdk_pixbuf plugins

I've added the rsvg (gst-plugins-pad/ext/) and gdk_pixbuf (gst-plugins-
good/ext/) plugins. Please update the EE solution to include these.

I've updated the WiX installers to include the plugins and the GTK+ libs. 
You'll want to do the same for the Inno Setup scripts.

Original issue reported on code.google.com by david.g.hoyt on 7 Feb 2010 at 8:23

DirectDraw Video Sink Freeze

If you run pipeline-start-stop test app, eventually the app will freeze on 
you.

Attaching a debugger and pausing the app shows there is 1 thread on line 
1561 of gstdirectdrawsink.c (DispatchMessage() call) and another thread on 
line 3573 of gstplaybin2.c (GST_ELEMENT_CLASS (parent_class)->change_state 
(element, transition)).

It appears to be in a deadlock.

Andoni, I could use some help tracking down the issue.

Original issue reported on code.google.com by david.g.hoyt on 15 May 2010 at 10:07