<div class="gmail_quote">On Tue, Jul 7, 2009 at 4:06 PM, <<a href="mailto:gstreamer-devel-request@lists.sourceforge.net">gstreamer-devel-request@lists.sourceforge.net</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Send gstreamer-devel mailing list submissions to <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> To subscribe or unsubscribe via the World Wide Web, visit <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a> or, via email, send a message with subject or body 'help' to <a href="mailto:gstreamer-devel-request@lists.sourceforge.net">gstreamer-devel-request@lists.sourceforge.net</a> You can reach the person managing the list at <a href="mailto:gstreamer-devel-owner@lists.sourceforge.net">gstreamer-devel-owner@lists.sourceforge.net</a> 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 <<a href="mailto:yogeshm.007@gmail.com">yogeshm.007@gmail.com</a>> 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 <<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a>> Message-ID: <<a href="mailto:48a42cbe0907062137j7889943an41d044f6dec4b4ec@mail.gmail.com">48a42cbe0907062137j7889943an41d044f6dec4b4ec@mail.gmail.com</a>> Content-Type: text/plain; charset=UTF-8 2009/7/7 pl bossart <<a href="mailto:bossart.nospam@gmail.com">bossart.nospam@gmail.com</a>>: > 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<<a href="mailto:yogeshm.007@gmail.com">yogeshm.007@gmail.com</a>> 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 >> <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> >> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a> >> > > ------------------------------------------------------------------------------ > 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: <a href="http://p.sf.net/sfu/blackberry" target="_blank">http://p.sf.net/sfu/blackberry</a> > _______________________________________________ > gstreamer-devel mailing list > <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> > <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a> > -- Yogesh M <a href="http://sparklemedia.sourceforge.net/" target="_blank">http://sparklemedia.sourceforge.net/</a> <a href="http://snakeeyes.wordpress.com/" target="_blank">http://snakeeyes.wordpress.com/</a> ------------------------------ Message: 2 Date: Tue, 7 Jul 2009 00:07:50 -0700 (PDT) From: Oliver Yu <<a href="mailto:oliyu@yahoo.com">oliyu@yahoo.com</a>> Subject: [gst-devel] Controlling multiple streams with a videomixer. To: <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> Message-ID: <<a href="mailto:585820.80932.qm@web110215.mail.gq1.yahoo.com">585820.80932.qm@web110215.mail.gq1.yahoo.com</a>> 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 <<a href="mailto:julien.isorce@gmail.com">julien.isorce@gmail.com</a>> Subject: Re: [gst-devel] Releasing gst-plugins-gl? To: Discussion of the development of GStreamer <<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a>> Message-ID: <<a href="mailto:180a127d0907070054j3ee90fd8i498eba7e97a921b4@mail.gmail.com">180a127d0907070054j3ee90fd8i498eba7e97a921b4@mail.gmail.com</a>> 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 <<a href="mailto:thaytan@mad.scientist.com">thaytan@mad.scientist.com</a>> > <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: <a href="http://p.sf.net/sfu/blackberry" target="_blank">http://p.sf.net/sfu/blackberry</a> > _______________________________________________ > gstreamer-devel mailing list > <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> > <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a> > -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 4 Date: Tue, 7 Jul 2009 10:24:40 +0200 From: Filippo Argiolas <<a href="mailto:filippo.argiolas@gmail.com">filippo.argiolas@gmail.com</a>> Subject: Re: [gst-devel] Releasing gst-plugins-gl? To: Discussion of the development of GStreamer <<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a>> Message-ID: <<a href="mailto:8ceb98f20907070124x44db1e8cl30d1f679296accf5@mail.gmail.com">8ceb98f20907070124x44db1e8cl30d1f679296accf5@mail.gmail.com</a>> Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2009 at 9:54 AM, Julien Isorce<<a href="mailto:julien.isorce@gmail.com">julien.isorce@gmail.com</a>> 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 <<a href="mailto:filippo.argiolas@gmail.com">filippo.argiolas@gmail.com</a>> Subject: Re: [gst-devel] Cheese, netbooks and resource hungry encoders To: Discussion of the development of GStreamer <<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a>> Message-ID: <<a href="mailto:8ceb98f20907070136t6350225do69a957ac60045407@mail.gmail.com">8ceb98f20907070136t6350225do69a957ac60045407@mail.gmail.com</a>> Content-Type: text/plain; charset=UTF-8 On Mon, Jul 6, 2009 at 12:49 PM, Axel Philipsenburg<<a href="mailto:axel.philipsenburg@hobnox.com">axel.philipsenburg@hobnox.com</a>> 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 <<a href="mailto:filippo.argiolas@gmail.com">filippo.argiolas@gmail.com</a>> Subject: Re: [gst-devel] Cheese, netbooks and resource hungry encoders To: Discussion of the development of GStreamer <<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a>> Message-ID: <<a href="mailto:8ceb98f20907070153r75e6e083s8277c73260ee46e6@mail.gmail.com">8ceb98f20907070153r75e6e083s8277c73260ee46e6@mail.gmail.com</a>> Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2009 at 1:03 AM, David Schleef<<a href="mailto:ds@entropywave.com">ds@entropywave.com</a>> 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: <a href="http://p.sf.net/sfu/blackberry" target="_blank">http://p.sf.net/sfu/blackberry</a> ------------------------------ _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a> End of gstreamer-devel Digest, Vol 38, Issue 12 *********************************************** </blockquote></div>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 <a href="http://sreerenj.livejournal.com">http://sreerenj.livejournal.com</a> <a href="mailto:bsreerenj@gmail.com">bsreerenj@gmail.com</a> mob: +91 9995377714