[gst-devel] video playing problem, Vol 38, Issue 5
sreerenj b
bsreerenj at gmail.com
Fri Jul 3 08:10:52 CEST 2009
On Fri, Jul 3, 2009 at 10:50 AM, <
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: 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 <gmane at colin.guthr.ie>
> Subject: Re: [gst-devel] GStreamer Summit during GCDS
> To: gstreamer-devel at lists.sourceforge.net
> Message-ID: <h2if4m$lub$1 at ger.gmane.org>
> 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)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
> Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
> Mandriva Linux Contributor [http://www.mandriva.com/]
> PulseAudio Hacker [http://www.pulseaudio.org/]
> Trac Hacker [http://trac.edgewall.org/]
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 2 Jul 2009 22:42:39 +0200
> From: MailingList SVR <lists at svrinformatica.it>
> Subject: [gst-devel] Udpsrc timeout, bus message and notification when
> source is unavailable
> To: gstreamer-devel at lists.sourceforge.net
> Message-ID: <200907022242.40006.lists at svrinformatica.it>
> 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 <ds at entropywave.com>
> Subject: [gst-devel] Orc-0.4.1 - The Oil Runtime Compiler
> To: liboil at lists.freedesktop.org, Gstreamer
> <gstreamer-devel at lists.sourceforge.net>,
> schroedinger-devel at lists.sourceforge.net
> Message-ID: <20090702223427.GA8070 at entropywave.com>
> 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 http://cgit.freedesktop.org/~ds/gstreamer<http://cgit.freedesktop.org/%7Eds/gstreamer>
>
> 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: http://www.schleef.org/orc/download/
> GIT: http://cgit.freedesktop.org/~ds/orc<http://cgit.freedesktop.org/%7Eds/orc>
> Documentation: http://www.schleef.org/orc/documentation/
>
>
> ORC - The Oil Runtime Compiler
> ==============================
>
> (and OIL stands for Optimized Inner Loops)
>
> Entropy Wave Inc (http://entropywave.com/) 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 <rob at ti.com>
> Subject: [gst-devel] proposal: support for row-stride in gstreamer
> To: Discussion of the development of GStreamer
> <gstreamer-devel at lists.sourceforge.net>
> Cc: Daniel Diaz <ddiaz at ti.com>, Bindu Kurian <bkurian at ti.com>,
> Ravikiran Ramachandra <r.ramachandra at ti.com>
> Message-ID: <C2E6B13C-6EB6-4D1A-8D74-57865D984D91 at ti.com>
> 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 <jeff_barish at earthlink.net>
> Subject: [gst-devel] Making GStreamer
> To: gstreamer-devel at lists.sourceforge.net
> Message-ID: <h2k4eb$u8a$1 at ger.gmane.org>
> 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
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
> End of gstreamer-devel Digest, Vol 38, Issue 4
> **********************************************
>
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://guest:carinov123@10.0.0.102/live.sdp"
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://guest:carinov123@10.0.0.102/live.sdp"
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
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/20090703/00c230cb/attachment.htm>
More information about the gstreamer-devel
mailing list