|
|
On Fri, Jul 3, 2009 at 10:50 AM, <[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: 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 <[hidden email]>
Subject: Re: [gst-devel] GStreamer Summit during GCDS
To: [hidden email]
Message-ID: <h2if4m$lub$[hidden email]>
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 <[hidden email]>
Subject: [gst-devel] Udpsrc timeout, bus message and notification when
source is unavailable
To: [hidden email]
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: [gst-devel] Orc-0.4.1 - The Oil Runtime Compiler
To: [hidden email], Gstreamer
<[hidden email]>,
[hidden email]
Message-ID: <[hidden email]>
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
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
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 <[hidden email]>
Subject: [gst-devel] proposal: support for row-stride in gstreamer
To: Discussion of the development of GStreamer
<[hidden email]>
Cc: Daniel Diaz <[hidden email]>, Bindu Kurian <[hidden email]>,
Ravikiran Ramachandra <[hidden email]>
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: [gst-devel] Making GStreamer
To: [hidden email]
Message-ID: <h2k4eb$u8a$[hidden email]>
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
[hidden email]
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
[hidden email]mob: +91 9995377714
------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
|
Locked
