On Mon, 2006-04-10 at 22:02 +0200, Stefan Kost wrote:
> we're seem to skip this class_data parameter in all our plugins (not
> usings it). My change was of cause faulty as I seem to missed the
> prototype. But wouldn't it be better tho remove it from both (proto+def)
> to be consistent with other plugins.
I believe that's because we use GST_BOILERPLATE or G_DEFINE_TYPE for
most of those cases (where the class_init function is prototyped with
one parameter and called via an internal trampoline function).
We should probably use one of those that here as well, I was just trying
to fix the build with as little effort as possible.
Cheers
-Tim

Hi david,
right now you'd better download the file before. GStreamer just starts
to handle situations like this where there are ressource problems
(either bandwith or CPU). But iit will take some time until this is
done.
Stefan
Am Montag, den 10.04.2006, 12:30 -0400 schrieb David Mansfield:
> Hi,
>
> I'm trying to play a file that is coming from a slow network drive. The
> drive is slow, but has about 3x the bandwidth as should be necessary to
> play.
>
> However, the I/O 'read' request is not being issued in time to provide
> the buffer to the pipeline in time, and the audio skips horribly.
>
> I attribute this to insufficient sink buffering, as that is really the
> only part of the pipeline I have full control over (via
> gstreamer-properties).
>
> To debug, I am trying the following:
>
> gst-launch --gst-debug-level=1 filesrc \
> location=file.mp3 ! \
> mad ! \
> audioconvert ! \
> audioresample ! \
> osssink latency-time=2000000 buffer-time=10000000 \
> preroll-queue-len=1
>
> I have tried both alsasink and osssink, with various settings for
> latency-time, buffer-time,nd preroll-queue-len, none of which make one
> whit of difference.
>
> Is there something I'm missing? How do I force read-ahead on the pipeline?
>
> David
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Hi,
I'm trying to play a file that is coming from a slow network drive. The
drive is slow, but has about 3x the bandwidth as should be necessary to
play.
However, the I/O 'read' request is not being issued in time to provide
the buffer to the pipeline in time, and the audio skips horribly.
I attribute this to insufficient sink buffering, as that is really the
only part of the pipeline I have full control over (via
gstreamer-properties).
To debug, I am trying the following:
gst-launch --gst-debug-level=1 filesrc \
location=file.mp3 ! \
mad ! \
audioconvert ! \
audioresample ! \
osssink latency-time=2000000 buffer-time=10000000 \
preroll-queue-len=1
I have tried both alsasink and osssink, with various settings for
latency-time, buffer-time,nd preroll-queue-len, none of which make one
whit of difference.
Is there something I'm missing? How do I force read-ahead on the pipeline?
David

Hi all,
for a while now I've been hacking on a demuxer for MVE movies,
and it's now progressed enough to request some feedback. For the
time being, the source can be found here:
http://www.lanipage.de/jens/gst-mvedemux-0.10.0.1.tar.bz2
MVE is the movie file format used in lots of Interplay game
titles, the ones I know of being Descent (1-3), Freespace (1+2),
Baldur's Gate (1+2), and Fallout (1+2). There are probably
many more.
The decoding parts are based on FFMPEG code with a few
additions (mainly support for 16-bit flicks). So far I've only
been able to test with Descent 2 and both versions of Freespace,
and only on x86, so I'd be happy about other success (or, to a
lesser extent, failure) reports.
Since this is my first ever stroll into GStreamer territory,
I'm also heavily interested in general GStreamer coding
commentary.
Then, there's what I consider a bug, but maybe it's not: Why
does ffmpegcolorspace require and set "endianness" for 8-bit
RGB modes (not for grayscale, though)? Is this just an oversight
or are there scenarios where this actually makes sense?
(And finally, and completely unrelated, it would be nice if
somebody had a look at
http://bugzilla.gnome.org/show_bug.cgi?id=3D335013...)
Thanks,
Jens

Hi,
Just a hint for making the docs. The argument and return values are
exactly the same and in the same order as the C API *except* for those
defined in the gst-python/gst/*.override files.
A simple example:
gstmessage.override : override gst_message_parse_state_changed noargs
This means gst.Message.parse_state_changed() has a different API.
It takes no argument, but returns a tuple with the 3 GstState
(old, new pending).
As a general rule, any function/method that has return values in
it's arguments (like GstBufer **bufer, or guint *value) will have an
override. And most of these override work in the following way:
return_value function(type arg1, type arg2, type * ret1, type *ret2)
Will become :
[return_value, type ret1, type ret2] function(type arg1, type
arg2) in python
Edward
On 4/9/06, Gian Mario Tagliaretti <g.tagliaretti@...> wrote:
> 2006/4/4, Mark Heslep <mark@...>:
> > Okay found them here: http://pygstdocs.berlios.de/ How about a link o=
n
> > the Gstreamer pager?
>
> Hi Mark,
>
> the API docs are not yet finished and most likely there are mistakes
> here and there, if you find any please let me know at my email
> address, thanks
>
> ciao
> --
> Gian Mario Tagliaretti
> PyGTK GUI programming
> http://www.parafernalia.org/pygtk/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
--
Edward Hervey
Junior developer / Fluendo S.L.
http://www.pitivi.org/

S=E9bastien Moutte wrote:
>>>>> It's time to report the WIN32 status of gstreamer packages. Now a=20
>>>>> lot of plugins build successfully with MSVC 6.0 and the ones i have=
=20
>>>>> tested work really good :)
>>>>
>>>> Why not support MSVC2005 (instead) ? That's the only free one and=20
>>>> performs much better.
>>> Yep, sure it is really better than VC6.0 or VC7.1 and I will add=20
>>> project files for it too, but the problem is we can't build binaries =
>>> packages with it as it links on msvcr80.dll which is not LGPL complia=
nt.=20
>>
>> That's the first time I hear something like that. LGPL can use closed =
>> source libraries AFAIK. It's not part of your code. And your code=20
>> doesn't depend on it. Only a version of the binary does, but it's not =
>> mandatory (as in derivative work).
>>
>>> Moreover, most of the binary packages of the gstreamer's dependencies=
=20
>>> are distributed linked on msvcrt.dll (6.0) then peoples who will want=
=20
>>> to work with MSVC2005 will have to build all dependencies before ...
>>
>> I don't think so. It's not because a library you use depend on X that =
>> your library has to depend on library X instead of Y. You could build =
>> a plugin that uses msvcrt90.dll or toto.dll and still leave the rest=20
>> of GStreamer, glib, etc intact.
> That's not always true ! You can't share resources across the msvcrt.dl=
l=20
> and msvcr80.dll boundary.
> http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
True, but I hope GStreamer doesn't need that (the core should be=20
consistent, then the rest should be free). The only case I've=20
encountered so far is when you use different memory models and share=20
FILE* instances.
Steve

On Sun, 2006-04-09 at 20:44 +0200, S=C3=A9bastien Moutte wrote:
> HI Gstreamer !!
>=20
> It's time to report the WIN32 status of gstreamer packages. Now a lot
> of plugins build successfully with MSVC 6.0 and the ones i have tested
> work really good :)
Sounds good!
>=20
> Here is a summary of the common build errors i'm still getting on some
> plugins:
> 1) Some plugins use not supported socket functions (inet_aton,
> socketpair ...). I'll search for a free implementation of the missing
> functions for WIN32 or try to remove this function calls. Does
> somebody know an existing solution ?
Some of these are easy, some are not. inet_aton is easy - if you have
inet_pton(), you can just use a trivial #ifdef, if you don't, an
implementation of it is pretty simple. Anyway, I expect windows has some
roughly-equivalent function that you can use.
socketpair is particularly hard. It's used to enable interruptable
selects() with a self-pipe, which simply can't be done on windows.=20
The right solution for windows is probably something using
WaitForMultipleObjects() and some sort of object that you can signal
from another thread - I don't know enough windows to know what. A lot of
the plugins do things like this, so it'd be nice to abstract it out into
another library somewhere...
> 2) Some plugins use rint (audioresample, videobalance). I've found and
> used #ifdef WIN32 #define rint(x) (floor((x)+0.5)) #endif. Is it
> correct ?
Not strictly correct, but probably close enough for what these plugins
need.
> 3) Some plugins need regex.h which is not on WIN32 dev environment.
There are regexp implementations available for windows, perhaps it's
best to simply use one of those?
> 4) Some plugins (realmedia, qtdemux) use void * in a lot of
> operations. MSVC doesn't support that, it generates error because it
> doesn't know the size of void then it can't move the pointer. I guess
> we can simply replace void * used in operations by byte * or char *,
> can i do that safely ?
This is using a gcc extension (void pointer arithmetic) which we
shouldn't be (it will certainly cause problems on non-windows platforms
too!). These should be considered outright bugs. Using 'char *' or
'unsigned char *' is usually the intended/correct thing.
Mike

Steve Lhomme a =E9crit :
> S=E9bastien Moutte wrote:
>> Steve Lhomme a =E9crit :
>>> S=E9bastien Moutte wrote:
>>>> HI Gstreamer !!
>>>>
>>>> It's time to report the WIN32 status of gstreamer packages. Now a=20
>>>> lot of plugins build successfully with MSVC 6.0 and the ones i have=20
>>>> tested work really good :)
>>>
>>> Why not support MSVC2005 (instead) ? That's the only free one and=20
>>> performs much better.
>> Yep, sure it is really better than VC6.0 or VC7.1 and I will add=20
>> project files for it too, but the problem is we can't build binaries=20
>> packages with it as it links on msvcr80.dll which is not LGPL complian=
t.=20
>
> That's the first time I hear something like that. LGPL can use closed=20
> source libraries AFAIK. It's not part of your code. And your code=20
> doesn't depend on it. Only a version of the binary does, but it's not=20
> mandatory (as in derivative work).
>
>> Moreover, most of the binary packages of the gstreamer's dependencies=20
>> are distributed linked on msvcrt.dll (6.0) then peoples who will want=20
>> to work with MSVC2005 will have to build all dependencies before ...
>
> I don't think so. It's not because a library you use depend on X that=20
> your library has to depend on library X instead of Y. You could build=20
> a plugin that uses msvcrt90.dll or toto.dll and still leave the rest=20
> of GStreamer, glib, etc intact.
That's not always true ! You can't share resources across the msvcrt.dll=20
and msvcr80.dll boundary.
http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
>
> Steve
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting=20
> language
> that extends applications into web and mobile media. Attend the live=20
> webcast
> and join the prime developer group breaking into this new coding=20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>

S=E9bastien Moutte wrote:
> Steve Lhomme a =E9crit :
>> S=E9bastien Moutte wrote:
>>> HI Gstreamer !!
>>>
>>> It's time to report the WIN32 status of gstreamer packages. Now a lot=
=20
>>> of plugins build successfully with MSVC 6.0 and the ones i have=20
>>> tested work really good :)
>>
>> Why not support MSVC2005 (instead) ? That's the only free one and=20
>> performs much better.
> Yep, sure it is really better than VC6.0 or VC7.1 and I will add projec=
t=20
> files for it too, but the problem is we can't build binaries packages=20
> with it as it links on msvcr80.dll which is not LGPL compliant.=20
That's the first time I hear something like that. LGPL can use closed=20
source libraries AFAIK. It's not part of your code. And your code=20
doesn't depend on it. Only a version of the binary does, but it's not=20
mandatory (as in derivative work).
> Moreover, most of the binary packages of the gstreamer's dependencies=20
> are distributed linked on msvcrt.dll (6.0) then peoples who will want t=
o=20
> work with MSVC2005 will have to build all dependencies before ...
I don't think so. It's not because a library you use depend on X that=20
your library has to depend on library X instead of Y. You could build a=20
plugin that uses msvcrt90.dll or toto.dll and still leave the rest of=20
GStreamer, glib, etc intact.
Steve

Steve Lhomme a =E9crit :
> S=E9bastien Moutte wrote:
>> HI Gstreamer !!
>>
>> It's time to report the WIN32 status of gstreamer packages. Now a lot=20
>> of plugins build successfully with MSVC 6.0 and the ones i have=20
>> tested work really good :)
>
> Why not support MSVC2005 (instead) ? That's the only free one and=20
> performs much better.
Yep, sure it is really better than VC6.0 or VC7.1 and I will add project=20
files for it too, but the problem is we can't build binaries packages=20
with it as it links on msvcr80.dll which is not LGPL compliant.=20
Moreover, most of the binary packages of the gstreamer's dependencies=20
are distributed linked on msvcrt.dll (6.0) then peoples who will want to=20
work with MSVC2005 will have to build all dependencies before ...
Sebastien
>
> Steve
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting=20
> language
> that extends applications into web and mobile media. Attend the live=20
> webcast
> and join the prime developer group breaking into this new coding=20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>

On Mon, 2006-04-10 at 09:29 +0200, Steve Lhomme wrote:
> S=C3=A9bastien Moutte wrote:
> > HI Gstreamer !!
> >=20
> > It's time to report the WIN32 status of gstreamer packages. Now a lot=
of=20
> > plugins build successfully with MSVC 6.0 and the ones i have tested w=
ork=20
> > really good :)
>=20
> Why not support MSVC2005 (instead) ? That's the only free one and=20
> performs much better.
What does "that's the only free one" mean ? None of the Microsoft
compilers are free in the real sense of the word.
Also, as far as we know, the only way you can distribute binaries and
not conflict with the LGPL (our license) is to use MSVC 6.0, because its
MSVCRT.dll is shipped with the operating system. For MSVC 7.0, the
updated C runtime is part of the Visual Studio install, and hence people
don't treat it as a system library.
Assuming MSVC2005 is MSVC 8.0 (correct me if I'm wrong), it's the same
problem.
Thomas

Hi,
On Sun, 09 Apr 2006 20:44:09 +0200, Sebastien Moutte wrote:
> 1) Some plugins use not supported socket functions (inet_aton,
> socketpair ...). I'll search for a free implementation of the missing
> functions for WIN32 or try to remove this function calls. Does somebody
> know an existing solution ?
Ffmpeg has free (LGPL) implementations of at least inet_aton(). Copying
those from their sources should be allright. May give hints on how to
get around socketpair(), also.
Ronald