[gst-devel] controlled shut down problem

sreerenj b bsreerenj at gmail.com
Tue Jul 7 14:32:00 CEST 2009


On Tue, Jul 7, 2009 at 4:06 PM, <
gstreamer-devel-request at lists.sourceforge.net> wrote:

> Send gstreamer-devel mailing list submissions to
>        gstreamer-devel at lists.sourceforge.net
>
> 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
>        gstreamer-devel-request at lists.sourceforge.net
>
> You can reach the person managing the list at
>        gstreamer-devel-owner at lists.sourceforge.net
>
> 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 <yogeshm.007 at gmail.com>
> 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
>        <gstreamer-devel at lists.sourceforge.net>
> Message-ID:
>        <48a42cbe0907062137j7889943an41d044f6dec4b4ec at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2009/7/7 pl bossart <bossart.nospam at gmail.com>:
> > 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<yogeshm.007 at gmail.com>
> 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
> >> gstreamer-devel at lists.sourceforge.net
> >> 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
> > gstreamer-devel at lists.sourceforge.net
> > 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 <oliyu at yahoo.com>
> Subject: [gst-devel] Controlling multiple streams with a videomixer.
> To: gstreamer-devel at lists.sourceforge.net
> Message-ID: <585820.80932.qm at web110215.mail.gq1.yahoo.com>
> 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 <julien.isorce at gmail.com>
> Subject: Re: [gst-devel] Releasing gst-plugins-gl?
> To: Discussion of the development of GStreamer
>        <gstreamer-devel at lists.sourceforge.net>
> Message-ID:
>        <180a127d0907070054j3ee90fd8i498eba7e97a921b4 at mail.gmail.com>
> 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 <thaytan at mad.scientist.com>
>
> > <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
> > gstreamer-devel at lists.sourceforge.net
> > 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 <filippo.argiolas at gmail.com>
> Subject: Re: [gst-devel] Releasing gst-plugins-gl?
> To: Discussion of the development of GStreamer
>        <gstreamer-devel at lists.sourceforge.net>
> Message-ID:
>        <8ceb98f20907070124x44db1e8cl30d1f679296accf5 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Jul 7, 2009 at 9:54 AM, Julien Isorce<julien.isorce at gmail.com>
> 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 <filippo.argiolas at gmail.com>
> Subject: Re: [gst-devel] Cheese, netbooks and resource hungry encoders
> To: Discussion of the development of GStreamer
>        <gstreamer-devel at lists.sourceforge.net>
> Message-ID:
>        <8ceb98f20907070136t6350225do69a957ac60045407 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jul 6, 2009 at 12:49 PM, Axel
> Philipsenburg<axel.philipsenburg at hobnox.com> 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 <filippo.argiolas at gmail.com>
> Subject: Re: [gst-devel] Cheese, netbooks and resource hungry encoders
> To: Discussion of the development of GStreamer
>        <gstreamer-devel at lists.sourceforge.net>
> Message-ID:
>        <8ceb98f20907070153r75e6e083s8277c73260ee46e6 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Jul 7, 2009 at 1:03 AM, David Schleef<ds at entropywave.com> 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
> gstreamer-devel at lists.sourceforge.net
> 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
bsreerenj at gmail.com
mob: +91 9995377714
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090707/3e139e1b/attachment.htm>


More information about the gstreamer-devel mailing list