|
|
On Tue, Jul 7, 2009 at 4:06 PM, <[hidden email]> wrote:
Send gstreamer-devel mailing list submissions to
[hidden email]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
or, via email, send a message with subject or body 'help' to
[hidden email]
You can reach the person managing the list at
[hidden email]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of gstreamer-devel digest..."
Today's Topics:
1. Re: Setting volume (playbin2) has no effect after one track
has ended and other is started. (Yogesh Marwaha)
2. Controlling multiple streams with a videomixer. (Oliver Yu)
3. Re: Releasing gst-plugins-gl? (Julien Isorce)
4. Re: Releasing gst-plugins-gl? (Filippo Argiolas)
5. Re: Cheese, netbooks and resource hungry encoders
(Filippo Argiolas)
6. Re: Cheese, netbooks and resource hungry encoders
(Filippo Argiolas)
----------------------------------------------------------------------
Message: 1
Date: Tue, 7 Jul 2009 10:07:56 +0530
From: Yogesh Marwaha <[hidden email]>
Subject: Re: [gst-devel] Setting volume (playbin2) has no effect after
one track has ended and other is started.
To: Discussion of the development of GStreamer
<[hidden email]>
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset=UTF-8
2009/7/7 pl bossart <[hidden email]>:
> In playbin2 the volume is passed to the sink as a property. If the
> sink doesn't store the volume setting for the next track you are
> hosed. Note that it should work fine with pulsesink since PulseAudio
> will remember and restore the volume. Can you provide more information
> on which audio sink you are using?
> Cheers
> Pierre
>
I meant that volume which was set during track1 is still applied to track2,
but any changes to volume during track2 (and subsequent tracks) is not
applied.
I am using alsasink.
> On Sat, Jul 4, 2009 at 6:55 AM, Yogesh Marwaha<[hidden email]> wrote:
>> Hi,
>>
>> Whenever I try changing the volume on playbin2, change of volume has no effect
>> after one track has ended and other is started.
>> Has anyone of you experienced such behaviour?
>>
>> Regards,
>>
>>
>> Yogesh Marwaha
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
--
Yogesh M
http://sparklemedia.sourceforge.net/
http://snakeeyes.wordpress.com/
------------------------------
Message: 2
Date: Tue, 7 Jul 2009 00:07:50 -0700 (PDT)
From: Oliver Yu <[hidden email]>
Subject: [gst-devel] Controlling multiple streams with a videomixer.
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii
I hope this isn't a newbie kind of question, but I haven't been able to find a working answer. I'm trying to mix multiple media streams together with a video mixer, but I need events about the individual streams, so that I can continue to mix in new streams, since the streams can be very different lengths. The two main methods that I have tried are:
1. Create a full pipeline containing multiple streams. This works for the playback, but I'm having problems getting the end of stream events for the shorter videos. Is there something I need to do to tie events to the individual streams?
here's my test launch definition:
player = gst.parse_launch("""
filesrc name=mp3src ! decodebin ! audioconvert ! audioresample ! pulsesink
filesrc name=videosrc1 ! dvddemux name=demux ! mpeg2dec ! ffmpegcolorspace
! videomixer name=mix ! ffmpegcolorspace ! videoscale
! video/x-raw-yuv,width=800,height=600 ! sdlvideosink name=view
filesrc name=videosrc2 ! dvddemux name=demux ! mpeg2dec ! ffmpegcolorspace
""")
2. I've also tried constructing invidividual playbins for each media stream. Since each are individual pipelines, I'm getting the events for all the individual streams. But I'm having problems mixing the vstreams together. I connect up each playbin to an alphacolor element as the video-sink, but as soon as try to link the alphacolor elements to a videomixer, I get the following error:
test.py:10865): GStreamer-WARNING **: Element alphacolor0 already has parent
(test.py:10865): GStreamer-WARNING **: Trying to connect elements that don't share a common ancestor: vscale and alphacolor0
Which way is the "right" way? Is there any good examples to do this properly?
I'm using GStreamer 0.10 on Ubunto 9.10 and I'm using the gst-python bindings.
Oli
------------------------------
Message: 3
Date: Tue, 7 Jul 2009 09:54:21 +0200
From: Julien Isorce <[hidden email]>
Subject: Re: [gst-devel] Releasing gst-plugins-gl?
To: Discussion of the development of GStreamer
<[hidden email]>
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am ok for a release a gst-plugins-gl.
Other infos:
My current task is to make it work on MacOSX. (note that it works through
X11)
I mean I am fixing our cocoa backend. (for now it only works on GNUstep)
It's in progress but it's a little bit harder without having a Mac computer.
But we do not need to wait for the end of this task because I do not know
how much time it will take.
About OpenGL ES 2.0, I made backends for X and winCE (trough emulators).
(Cocoa is the same as not embedded)
I am still waitting someone try the X backend on Maemo. (the build need to
be fixed for it), or any kind of real device.
Anyway I think gst-gl is working well enough on X and win32 to push a
release.
It will also be a good way to receive more bugs that we can fix to make it
more stable.
Sincerely
Julien
2009/7/7 Jan Schmidt <[hidden email]>
> <quote who="Sebastian Dr?ge">
>
> > Am Dienstag, den 07.07.2009, 04:14 +1000 schrieb Jan Schmidt:
> > > Hi all,
> > >
> > > Daniel Siegel has been poking me here at GCDS about getting a first
> release
> > > tarball of gst-plugins-gl out the door so he can finally start using it
> in
> > > Cheese.
> > >
> > > I wanted to see how you all feel about it - whether you think it is in
> good
> > > enough shape to cut a 0.10.1 tarball, even if it doesn't yet provide
> the
> > > kind of interface guarantees that our stable modules do?
> >
> > Until those guarantees are there I'd make the version 0.9.X to make sure
> > everybody knows that this is still unstable API/ABI.
>
> That would be a bad idea - as GStreamer core won't load plugins that have
> anything other than 0.10 in the PluginDesc major/minor version fields,
> which
> is what they'd end up with without more changes.
>
> Personally, I don't see a problem with using 0.10 version numbers and a
> warning in the release notes about possible API changes in the elements -
> it's the same thing we do with gst-plugins-bad after all.
>
> J.
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 4
Date: Tue, 7 Jul 2009 10:24:40 +0200
From: Filippo Argiolas <[hidden email]>
Subject: Re: [gst-devel] Releasing gst-plugins-gl?
To: Discussion of the development of GStreamer
<[hidden email]>
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 7, 2009 at 9:54 AM, Julien Isorce<[hidden email]> wrote:
> Hi,
>
> I am ok for a release a gst-plugins-gl.
>
> Anyway I think gst-gl is working well enough on X and win32 to push a
> release.
> It will also be a good way to receive more bugs that we can fix to make it
> more stable.
Same for me.
It's been quite difficult to keep hacking on gst-gl as I wanted lately
(well, last year...).
The whole codebase probably needs some polishing and we cannot
guarantee complete stability like other modules do, but that's the
reason we would have a separate release and we won't be part of the
other modulesets release schedule for now.
It's in a pretty good shape, has been tested with all the graphic
hardware we have, but it really needs to face the real world to show
up its flaws and give us a chance to fix them.
A release, for me, would hopefully be an occasion to get back working
on it, at least for bugfixing and other maintenance work.
ciao,
Filippo
------------------------------
Message: 5
Date: Tue, 7 Jul 2009 10:36:01 +0200
From: Filippo Argiolas <[hidden email]>
Subject: Re: [gst-devel] Cheese, netbooks and resource hungry encoders
To: Discussion of the development of GStreamer
<[hidden email]>
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 6, 2009 at 12:49 PM, Axel
Philipsenburg<[hidden email]> wrote:
> Hi there,
>
> Filippo Argiolas wrote:
>> Do you have any suggestion about less cpu avid encoders? We used those
>> ones because they are free but if they don't work it could be worth
>> adding other options (ideally we'd add DeviceProfiles support when
>> it'll be in a good enough shape).
> Did you check the parameters on theoraenc ?
> There is the "speed-level" parameter that could
> limit the motion vector search, which is a very
> time consuming process.
I've tried fiddling with theoraenc parameters, speed-level included,
but I wasn't able to drop cpu load significantly (in the best case it
dropped from 105% to 99% but recording failed anyway).
Also I believe vorbisenc has a great part, it seems it doesn't perform
quite well on atom.
> On the other hand, did you use a queue in the pipeline? If
> I remember correctly, Atom CPUs (used in many
> Netbooks) have Hyperthreading. Thus allowing the
> pipeline to multithread might improve the performance
> a bit.
Sure the pipeline we use is roughly like:
gst-launch-0.10 v4l2src ! tee name=t ! queue ! xvimagesink t. ! queue
! theoraenc ! oggmux name=m ! filesink location=test.ogg pulsesrc !
queue ! audioconvert ! vorbisenc ! m.
> I agree with Erik that using a lower resolution will help a lot
> too. Scaling the image down with a simple filter such as
> bilinear is way faster than the encoding the larger picture.
Sure, lowering the resolution can really drop cpu load (even 40-50%
less) but that unfortunately depends on the user choice. I could write
a FAQ item telling them to lower down recording resolution but that
wouldn't prevent the issue to come up if they don't do it.
Maybe I could look for a way to guess the available cpu power and
lower down recording resolution by default if it's not enough.
Thanks
Filippo
------------------------------
Message: 6
Date: Tue, 7 Jul 2009 10:53:59 +0200
From: Filippo Argiolas <[hidden email]>
Subject: Re: [gst-devel] Cheese, netbooks and resource hungry encoders
To: Discussion of the development of GStreamer
<[hidden email]>
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 7, 2009 at 1:03 AM, David Schleef<[hidden email]> wrote:
> We don't currently have the infrastructure for enforcing real-time
> encoding -- you either have enough CPU and it Just Works, or you
> don't, and it silently fails. ?Encoder libraries are starting to
> get features for controlling this. ?libtheora allows you to mark
> the next several frames as identical, thereby skipping frames when
> the encoder gets behind. ?Schroedinger has a similar mechanism, but
> it's not yet exposed in the API. ?I'll probably add some support
> in GstBaseVideoEncoder for catching QoS messages (which have not
> been defined yet) to connect up to the encoder features. ?(You know,
> in that magical day in the future when I get back to BaseVideo
> hacking.)
Thank you for clearing this. You're totally right, real time recording
just works if the cpu can handle it but silently fails, sometimes
outputting empty files, sometimes just freezing, etc. when the power
is not enough. At least now I can blame for sure gstreamer when it
happens ;-)
A base class for encoding with some kind of Quality of Service would
be really great.
> In general, prefessional capture apps encode to an intermediate
> codec like AIC, ProRes422, DNxHD, or DiracPro, since the CPU usage
> is very predictable and quite low. ?But that requires large bit
> rates and off-line transcoding to whatever long-gop format you
> actually want.
That would probably be an overkill for a simple application like
Cheese, both from an implementation point of view (i.e. we need more
manpower to add advanced features like raw/intermediate codec
recording + delayed transcoding) and from a use target (it's just an
application that takes photos and little videos for fun... you cannot
expect it to behave professionally) point of view.
Thank you,
Filippo
------------------------------
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
End of gstreamer-devel Digest, Vol 38, Issue 12
***********************************************
Hi, can we retrive the name of pipeline from the message which is posted to the pipeline?(suppose i send an EOS event with gst_element_send_event,how can i retrive the name of pipeline in the bus watch function?)
Sreerenj B http://sreerenj.livejournal.com[hidden email]mob: +91 9995377714
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
|
Locked
