<div class="gmail_quote">On Fri, Jul 3, 2009 at 10:50 AM, <<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: GStreamer Summit during GCDS (Colin Guthrie) 2. Udpsrc timeout, bus message and notification when source is unavailable (MailingList SVR) 3. Orc-0.4.1 - The Oil Runtime Compiler (David Schleef) 4. proposal: support for row-stride in gstreamer (Rob Clark) 5. Making GStreamer (Jeffrey Barish) ---------------------------------------------------------------------- Message: 1 Date: Thu, 02 Jul 2009 15:10:30 +0100 From: Colin Guthrie <<a href="mailto:gmane@colin.guthr.ie">gmane@colin.guthr.ie</a>> Subject: Re: [gst-devel] GStreamer Summit during GCDS To: <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> Message-ID: <h2if4m$lub$<a href="mailto:1@ger.gmane.org">1@ger.gmane.org</a>> Content-Type: text/plain; charset=UTF-8; format=flowed 'Twas brillig, and Christian Fredrik Kalager Schaller at 30/06/09 09:17 did gyre and gimble: > It will be an informal gathering where people should feel free to do > lightning talk like presentations on multimedia related subjects aimed > at developers. There will also be some general discussion about our > GStreamer 1.0 roadmap, following on from Jan Schmidts talk on Sunday. While I sadly can't attend the summit, I'd be really interested if some gstreamer+Qt/KDE guys could find some time for a confab. I'd really like to see Phonon on KDE using the phonon-gstreamer backend if possible, but there are several issues to sort out. Having a gstreamer mentory/guru would surely help here! IMO having gstreamer as the defacto backend on KDE would solve a lot of bugs that are being blamed on pulseaudio right now which really boil down to Xine's poor support for the pulseaudio output layer (as Xine seems to have become the standard phonon backend right now). Hopefully the Gnome+KDE crossover will let this kind of meeting go through. :) -- Colin Guthrie gmane(at)<a href="http://colin.guthr.ie" target="_blank">colin.guthr.ie</a> <a href="http://colin.guthr.ie/" target="_blank">http://colin.guthr.ie/</a> Day Job: Tribalogic Limited [<a href="http://www.tribalogic.net/" target="_blank">http://www.tribalogic.net/</a>] Open Source: Mandriva Linux Contributor [<a href="http://www.mandriva.com/" target="_blank">http://www.mandriva.com/</a>] PulseAudio Hacker [<a href="http://www.pulseaudio.org/" target="_blank">http://www.pulseaudio.org/</a>] Trac Hacker [<a href="http://trac.edgewall.org/" target="_blank">http://trac.edgewall.org/</a>] ------------------------------ Message: 2 Date: Thu, 2 Jul 2009 22:42:39 +0200 From: MailingList SVR <<a href="mailto:lists@svrinformatica.it">lists@svrinformatica.it</a>> Subject: [gst-devel] Udpsrc timeout, bus message and notification when source is unavailable To: <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> Message-ID: <<a href="mailto:200907022242.40006.lists@svrinformatica.it">200907022242.40006.lists@svrinformatica.it</a>> Content-Type: text/plain; charset="us-ascii" Hi all, I'm using a simple pipeline to receive and view an rtp live stream using udpsrc to receive data. I setted the udpsrc timeout: source=gst.element_factory_make("udpsrc") source.set_property("port",self.sourceport) source.set_property("timeout",3000) source.set_property("caps",self.caps) I also have: bus = self.pipeline.get_bus() bus.add_signal_watch() bus.connect("message",self.on_message) according to the documentation I have to receive a message on the bus after the timeout, so I disconnect the network cable to the source stream and wait for the timeout message but it seems never to arrive at least as error,warning or state change message, what wrong? How can I be notified when the source stream is not more available? thanks Nicola -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 3 Date: Thu, 2 Jul 2009 15:34:27 -0700 From: David Schleef <<a href="mailto:ds@entropywave.com">ds@entropywave.com</a>> Subject: [gst-devel] Orc-0.4.1 - The Oil Runtime Compiler To: <a href="mailto:liboil@lists.freedesktop.org">liboil@lists.freedesktop.org</a>, Gstreamer <<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a>>, <a href="mailto:schroedinger-devel@lists.sourceforge.net">schroedinger-devel@lists.sourceforge.net</a> Message-ID: <<a href="mailto:20090702223427.GA8070@entropywave.com">20090702223427.GA8070@entropywave.com</a>> Content-Type: text/plain; charset=us-ascii 0.4.1 ===== This release introduces the orcc program, which parses .orc files and outputs C source files to compile into a library or application. The main source file implements the functions described by the .orc source code, by creating Orc programs and compiling them at runtime. Another source file that it outputs is a test program that can be compiled and run to determine if Orc is generating code correctly. In future releases, the orcc tool will be expanded to output assembly code, as well as make it easier to use Orc in a variety of ways. Much of Schroedinger and GStreamer have been converted to use Orc instead of liboil, as well as converting code that wasn't able to use liboil. To enable this in Schroedinger, use the --enable-orc configure option. The GStreamer changes are in the orc branch in the repository at <a href="http://cgit.freedesktop.org/%7Eds/gstreamer" target="_blank">http://cgit.freedesktop.org/~ds/gstreamer</a> Scheduled changes for 0.4.2 include a 2-D array mode for converting the remaining liboil functions used in Schroedinger and GStreamer. Major changes: - Add the orcc compiler. Generates C code that creates Orc programs from .orc source files. - Improved testing - Fixes in the C backend - Fix the MMX backend to emit 'emms' instructions. - Add a few rules to the SSE backend. Links ===== Download: <a href="http://www.schleef.org/orc/download/" target="_blank">http://www.schleef.org/orc/download/</a> GIT: <a href="http://cgit.freedesktop.org/%7Eds/orc" target="_blank">http://cgit.freedesktop.org/~ds/orc</a> Documentation: <a href="http://www.schleef.org/orc/documentation/" target="_blank">http://www.schleef.org/orc/documentation/</a> ORC - The Oil Runtime Compiler ============================== (and OIL stands for Optimized Inner Loops) Entropy Wave Inc (<a href="http://entropywave.com/" target="_blank">http://entropywave.com/</a>) presents Orc, the sucessor to Liboil - The Library of Optimized Inner Loops. Orc is a library and set of tools for compiling and executing very simple programs that operate on arrays of data. The "language" is a generic assembly language that represents many of the features available in SIMD architectures, including saturated addition and subtraction, and many arithmetic operations. At this point, developers interested in using Orc should look at the examples and try out a few Orc programs in an experimental branch of their own projects. And provide feedback on how it works. There will likely be some major changes in ease of use from a developer's perspective over the next few releases. The 0.4 series of Orc releases will be API and ABI compatible, and will be incompatible with the 0.5 series when it comes out. It is anticipated that 0.5 will follow in a few months. Features: - Users can create, compile, and run simple programs that use the vector extensions of the CPU, all directly from an application. - Users can compile Orc programs to assembly source code to be compiled and used without linking against the Orc library. - The generic assembly language can be extended by an application by adding new opcodes. - An application can add rules for converting existing or new opcodes to binary code for a specific target. - Current targets: SSE, MMX, ARM, Altivec. (ARM is very limited.) The NEON and TI c64x+ DSP targets are not open source and can be licensed separately from Entropy Wave. - Programs can optionally be emulated, which is useful for testing, or if no rules are available to convert Orc opcodes to executable code. Questions and Answers: - Q: Why not let gcc vectorize my code? A: Two reasons: first, since Orc's assembly language is much more restrictive than C, Orc can generate better code than gcc, and second, Orc can generate code for functions you define at runtime. Many algorithms require gluing together several stages of operations, and if each stage has several options, the total amount of code to cover all combinations could be inconveniently large. - Q: Why not use compiler intrinsics for SIMD code? A: Compiler intrinsics only work for one target, and need to be hand written. Plus, some compilers are very picky about source code that uses intrinsics, and will silently produce slow code. And, of course, you can't compile intrinsics at runtime. - Q: How big is the Orc library? A: Compiled with only one target (SSE), the library size is about 86 kB uncompressed, or 30 kB compressed. The goal is to keep the uncompressed size under about 100 kB. Caveats (Known Bugs): - ? Future directions: - Addition of more complex loop control and array structures. - Addition of an option to compile the Orc library with only the runtime features for a single target, e.g., for embedded systems. - Addition of rewrite rules, which convert an instruction that cannot be converted to binary code into a series of instructions that can. This is necessary since assembly instructions on most targets do not cover all the features of the Orc assembly language. About Entropy Wave: Entropy Wave creates tools that allow content producers and distributors use open video technology. Through use of open source software like GStreamer and Dirac, Entropy Wave's customers save money on licensing costs for encoding and streaming video on the web. Entropy Wave was founded in 2008 by long-time open source developer David Schleef. ------------------------------ Message: 4 Date: Thu, 2 Jul 2009 18:43:17 -0500 From: Rob Clark <<a href="mailto:rob@ti.com">rob@ti.com</a>> Subject: [gst-devel] proposal: support for row-stride in gstreamer To: Discussion of the development of GStreamer <<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a>> Cc: Daniel Diaz <<a href="mailto:ddiaz@ti.com">ddiaz@ti.com</a>>, Bindu Kurian <<a href="mailto:bkurian@ti.com">bkurian@ti.com</a>>, Ravikiran Ramachandra <<a href="mailto:r.ramachandra@ti.com">r.ramachandra@ti.com</a>> Message-ID: <<a href="mailto:C2E6B13C-6EB6-4D1A-8D74-57865D984D91@ti.com">C2E6B13C-6EB6-4D1A-8D74-57865D984D91@ti.com</a>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi gstreamer folks, The following is a proposal for how to add row-stride (and possibly some related changes) to gstreamer. I gave a couple of possible examples of where this would be useful, but it is probably not exhaustive. Please let me know if you see any cases that I missed, or details that I overlooked, etc. Use-cases: ---------- + display hardware with special constraints on image dimensions, for example if the output buffer must have dimensions that are a power of two + zero-copy cropping of image / videoframe (at least for interleaved color formats.. more on this later) One example to think about is rendering onto a 3d surface. In some cases, graphics hardware could require that the surface dimensions are a power of 2. In this case, you would want the vsink to allocate a buffer with a rowstride that is the next larger power of 2 from the image width. Another example to think about is video stabilization. In this use case, you would ask the camera to capture an oversized frame. Your vstab algorithm would calculate an x,y offset of the stabilized image. But if the decoder understands rowstride, you do not need to actually copy the image buffer. Say, just to pick some numbers, you want your final output to be 640x480, and you want your oversized frame to be +20% in each dimension (768x576): +--------+ +-------+ +------+ | camera |---------->| vstab |---------->| venc | +--------+ width=768 +-------+ width=640 +------+ height=576 height=480 rowstride=768 rowstride=768 In the case of an interleaved color format (RGB, UYVY, etc), you could simply increment the 'data' pointer in the buffer by (y*rowstride)+x. No memcpy() required. As long as the video encoder respects the rowstride, it will see the stabilized frame correctly. Proposal: --------- In all cases that I can think of, the row-stride will not be changing dynamically. So this parameter can be negotiated thru caps negotiation in the same way as image width/height, colorformat, etc. However, we need to know conclusively that there is no element in the pipeline that cares about the image format, but does not understand "rowstride", so we cannot use existing type strings (ex. "video/x-raw- yuv"). And, at least in the cases that I can think of, the video sink will dictate the row-stride. So upstream caps-renegotiation will be used to arrive at the final "rowstride" value. For media types, I propose to continue using existing strings for non- stride-aware element caps, ex. "video/x-raw-yuv". For stride-aware elements, they can support a second format, ex. "video/x-raw-yuv- strided", "image/x-raw-rgb-strided", etc (ie. append "-strided" to whatever the existing string is). In the case that a strided format is negotiated, it is required for there to also be a "rowstride" entry in the final negotiated caps. question: in general, most elements supporting rowstride will have no constraint on what particular rowstride values are supported. Do they just list "rowstride=[0-4294967295]" in their caps template? The video sink allocating the buffer will likely have some constraints on rowstride, although this will be a function of the width (for example, round the width up to next power of two). We will implement some sort of GstRowStrideTransform element to interface between stride-aware and non-stride-aware elements. Non-Interleaved Color Formats: ------------------------------ So, everything I've said so far about zero-copy cropping works until you start considering planar/semi-planar color formats which do not have equal size planes. For example, consider NV12: the offset to add to the Y plane is (y*rowstride)+x, but the offset to add to UV plane is ((y/2)*rowstride)+x. There are only three ways that I can think of to deal with this (listed in order of my preference): 1) add fields to GstBuffer to pass additional pointers to the other color planes within the same GstBuffer 2) add a field(s) to GstBuffer to pass an offset.. either an x,y offset, or a single value that is (y*rowstride)+x. Either way, the various elements in the pipeline can use this to calculate the start of the individual planes of data. 3) pass individual planes of a single image as separate GstBuffer's.. but I'm not a huge fan of this because now every element needs to have some sort of "I've got Y, but I'm waiting for UV" state. I'm not sure if anyone has any thoughts about which of these three approaches is preferred. Or any alternative ideas? BR, -Rob ------------------------------ Message: 5 Date: Thu, 02 Jul 2009 23:20:10 -0600 From: Jeffrey Barish <<a href="mailto:jeff_barish@earthlink.net">jeff_barish@earthlink.net</a>> Subject: [gst-devel] Making GStreamer To: <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> Message-ID: <h2k4eb$u8a$<a href="mailto:1@ger.gmane.org">1@ger.gmane.org</a>> Content-Type: text/plain; charset=us-ascii After an effort lasting many days, I have managed to make gstreamer-0.10.23 and gst-plugins-base-0.10.23 cleanly. However, gst-python-0.10.15 does not make cleanly. I still get many warnings along the lines of Could not write method GstStructure.get_uint: No ArgType for 'guint*' and then ***INFO*** The coverage of global functions is 45.45% (10/22) The make finishes anyway, but when I try to import gst I get: Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gst AttributeError: 'module' object has no attribute 'Element' python: symbol lookup error: gst/.libs/interfaces.so: undefined symbol: gst_navigation_command_get_type When I check interfaces.so in /usr/lib/python2.6/dist-packages/gst-0.10/gst with nm, I confirm that gst_navigation_command_get_type is undefined. I have no idea what to do now, so I would appreciate some suggestions. -- Jeffrey Barish ------------------------------ ------------------------------------------------------------------------------ ------------------------------ _______________________________________________ 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 4 ********************************************** </blockquote></div> Hi, I tried to record the video stream from a vivotek camera .The stream is in mpeg4 format from the camera.I need to avoid extra encodings and decodings.So a simple pipeline to record the video is gst-launch rtspsrc location="rtsp://<a href="http://guest:carinov123@10.0.0.102/live.sdp">guest:carinov123@10.0.0.102/live.sdp</a>" name=rtsp ! rtpmp4vdepay ! filesink location=video.mp4 . but after the recording when i tried to play the video with mplayer, i got the following errors, [lavf] Video stream found, -vid 0 VIDEO: [FMP4] 320x240 0bpp 1000.000 fps 0.0 kbps ( 0.0 kbyte/s) No pts value from demuxer to use for frame!,?% 0 0 pts after filters MISSING I dont know what is happening here!If i use an extra decoding ,then it should work, gst-launch rtspsrc location="rtsp://<a href="http://guest:carinov123@10.0.0.102/live.sdp">guest:carinov123@10.0.0.102/live.sdp</a>" name=rtsp ! rtpmp4vdepay ! video/mpeg, width=320, height=240, framerate=30/1 ! ffdec_mpeg4 ! videorate ! avimux ! filesink location=video.mp4 rtsp. ! fakesink but this is too time consuming and needed one more encoding to get an mp4 file.How can i resolve this issue? -- 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