|
|
Thants, guise! I tried that and it worked!
But the Perl bindings are still hidden in my options. Mark Beihoffer Dragonfly Networks [hidden email]
[hidden email](612)508-5128
On Tue, Oct 19, 2010 at 2:51 PM, <[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: Choppy Audio over UDP (Wes Miller)
2. how to create a simple "on/off" element in the pipeline ?
(Wiktor Lisowicz)
3. Re: how to create a simple "on/off" element in the pipeline ?
(Tim-Philipp M?ller)
4. Re: long pauses when viewing RTSP stream (Gruenke, Matt)
5. Re: DV capture pipeline frozen (Andoni Morales)
6. Re: Choppy Audio over UDP (Wes Miller)
7. Re: Reduce latency for a MJPEG over UDP multicast pipe
(Arnout Vandecappelle)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Oct 2010 07:18:24 -0700 (PDT)
From: Wes Miller <[hidden email]>
Subject: Re: [gst-devel] Choppy Audio over UDP
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii
Marco,
Better, still not quite right.
Removing audioconvert and audioresample on both sender and receiver seem to
have little or no effect, so they are now out.
Pulsesink is working on the receiver (my Linux workstation/host). I can use
pulsesrc on the sender wince Ti/RidgeRun don't seem to include the pulse
stuff in their ports of gst. I keep eading about alsa hardware on the
Leopardboard...???
I used fakesink to get the sender caps (from fakesink0:Gstpad:sink) and I
notice that the ssrc, clock-base and seqnum change every time I run the
pipeline.
If the clock-base is different each time I start the sender, how can the
receiver ever actually match the sender?
Is there a tcp-ish way to pass the caps to the receiver and insert them in
the receiver pipeline? (sounds like a great, first, element writing project,
doesn't it?)
I've tried to find out what ssrc is/are and can't find a description. So
what is it? Does it matter?
As ever, many thanks,
Wes
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Choppy-Audio-over-UDP-tp2997741p3002180.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
------------------------------
Message: 2
Date: Tue, 19 Oct 2010 17:11:28 +0200
From: Wiktor Lisowicz <[hidden email]>
Subject: [gst-devel] how to create a simple "on/off" element in the
pipeline ?
To: [hidden email]
Message-ID:
<AANLkTimUXDP8-6RcRSQ2Hrqr05=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"
Following pipeline is equivalent to mine:
gst-launch filesrc location=foobar.mp3 ! decodebin ! tee name=a a. ! queue !
audioconvert ! audioresample ! autoaudiosink a. ! queue ! fakesink
Short summary: I have a mp3 player, which sends the data to tee element. Tee
element copies the data to two audio sinks. So instead of stereo sound, I
have 2x stereo sound.
I would like to ocasionally switch off/on data flow to one of the two
audiosinks. This should be doable independent of the pipeline state (could
be PAUSED, READY, PLAYING - does not matter).
Which existing element could I add between <queue> and <audio sink>, to be
able to turn on / turn off data flow to audiosink?? Is there an element like
Identity (
http://www.gstreamer.net/data/doc/gstreamer/0.10.3/gstreamer-plugins/html/gstreamer-plugins-identity.html),
but with additional feature of stopping the data flow?
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Tue, 19 Oct 2010 16:32:33 +0100
From: Tim-Philipp M?ller <[hidden email]>
Subject: Re: [gst-devel] how to create a simple "on/off" element in
the pipeline ?
To: [hidden email]
Message-ID: <1287502353.20478.20.camel@zingle>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2010-10-19 at 17:11 +0200, Wiktor Lisowicz wrote:
> I would like to ocasionally switch off/on data flow to one of the two
> audiosinks. This should be doable independent of the pipeline state
> (could be PAUSED, READY, PLAYING - does not matter).
>
> Which existing element could I add between <queue> and <audio sink>,
> to be able to turn on / turn off data flow to audiosink?? Is there an
> element like Identity
> (http://www.gstreamer.net/data/doc/gstreamer/0.10.3/gstreamer-plugins/html/gstreamer-plugins-identity.html), but with additional feature of stopping the data flow?
You could use identity drop-probability=1.0, or the 'valve' element from
gst-plugins-bad (to be moved to core, -base or good soon hopefully). You
would probably also want to set the "async" property of the actual
audiosink element to false then.
Cheers
-Tim
------------------------------
Message: 4
Date: Tue, 19 Oct 2010 11:37:37 -0400
From: "Gruenke, Matt" <[hidden email]>
Subject: Re: [gst-devel] long pauses when viewing RTSP stream
To: "Discussion of the development of GStreamer"
<[hidden email]>
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="us-ascii"
Is the 241Q running the latest firmware?
If you change the 'latency' property of rtspsrc, does it affect the
amount of time spent "pausing"?
Matt
-----Original Message-----
From: Doug Crawford [mailto:[hidden email]]
Sent: Friday, October 15, 2010 15:33
To: [hidden email]
Subject: [gst-devel] long pauses when viewing RTSP stream
I am viewing a RTSP stream from an AXIS 241Q video server and displaying
it
on my OMAP3EVM board. My gstreamer pipeline is: gst-launch rtspsrc
location=rtsp://10.5.5.33/mpeg4/media.amp ! decodebin2 ! TIDmaiVideoSink
videoStd=VGA videoOutput=LCD sync=false rotation=90
The video pauses for about 5 seconds then plays very fast for about 2
seconds and this keeps repeating over and over. Any ideas?
--
View this message in context:
<a href="http://gstreamer-devel.966125.n4.nabble.com/long-pauses-when-viewing-RTS
P-stream-tp2997576p2997576.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/long-pauses-when-viewing-RTS
P-stream-tp2997576p2997576.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------
------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that
run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
------------------------------
Message: 5
Date: Tue, 19 Oct 2010 17:55:07 +0200
From: Andoni Morales <[hidden email]>
Subject: Re: [gst-devel] DV capture pipeline frozen
To: Discussion of the development of GStreamer
<[hidden email]>
Message-ID:
<AANLkTim6z=+[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1
2010/8/16 Gregory Petrosyan <[hidden email]>:
> On Mon, Aug 16, 2010 at 11:35 PM, Gregory Petrosyan
> <[hidden email]> wrote:
>> I am having some problems with GStreamer. Basically, I have a
>> pipeline, which used to work (with Ubuntu 9.04 GStreamer packages).
>> Here it is:
>>
>> ...
>>
>> Basically, it captures video from a DV camera, stores raw DV data,
>> encodes it to H.264 on the fly and shows video preview window.
>
> Here are the minimal pipelines, which reproduce the problem:
>
> This works:
> gst-launch-0.10 -e dv1394src ! queue ! dvdemux ! ffdec_dvvideo ! queue
> ! ffmpegcolorspace ! x264enc ! mpegtsmux ! queue ! filesink
> location=test.avi
>
> And this:
> gst-launch-0.10 -e dv1394src ! queue ! dvdemux ! ffdec_dvvideo ! tee
> name=t ! queue ! ffmpegcolorspace ! x264enc ! mpegtsmux ! queue !
> filesink location=test.avi t. ! queue ! ffmpegcolorspace ! xvimagesink
> sync=false
The x264 encoder needs some buffers before the pushing first one
downstream, which full the queue before the video sink.
Disable the limits in the queue (queue max-size-bytes=0
max-size-buffers=0 max-size-time=0) and that will fix you problem:
gst-launch-0.10 -e dv1394src ! queue ! dvdemux ! ffdec_dvvideo ! tee
name=t ! queue ! ffmpegcolorspace ! x264enc ! mpegtsmux ! queue !
filesink location=test.avi t. ! queue max-size-bytes=0
max-size-buffers=0 max-size-time=0 ! ffmpegcolorspace ! xvimagesink
sync=false
Next time you can debug it naming the queues and using GST_DEBUG=*queue*:5:
queue_dataflow gstqueue.c:930:gst_queue_chain:<sink_queue> received
buffer 0xb53029f0 of size 153600, time 0:00:01.033333333, duration
0:00:00.033333333
queue_dataflow gstqueue.c:963:gst_queue_chain:<sink_queue> queue is
full, waiting for free space
queue_dataflow gstqueue.c:968:gst_queue_chain:<sink_queue>
(sink_queue:sink) wait for DEL: 30 of 0-200 buffers, 4608000 of
0-10485760 bytes, 1000000000 of 0-1000000000 ns, 30 items
As you see the limit in time was reached in the queue "1000000000 of
0-1000000000 ns"
Andoni
>
> results in frozen preview window + zero-length test.avi file.
>
> ? ? ? ? ? ? ? ? Gregory
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
--
Andoni Morales Alastruey
LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
------------------------------
Message: 6
Date: Tue, 19 Oct 2010 12:46:13 -0700 (PDT)
From: Wes Miller <[hidden email]>
Subject: Re: [gst-devel] Choppy Audio over UDP
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii
Hi All,
Two additional bit of information:
1. "TURN THAT $@!# THING DOWN" I added volume elements in both sener and
receiver pipes. Made a big difference. Guess I was overdriving everything.
2. For the aac pipes above, I had to slow down the clock-rate on the
receiver to about 20400 to get something that sounded even remotely like it
was matched to the clock-rate=44100 sender.
So, it's still awfully jittery. On a whim, I tried going back to just using
udpsrc/udpsink without rtpbin. Still poor quality. Then I took out the
dmaienc_aac and replaced it with several different encoders (aka, whatever
TI and RidgeRun managed to stick in the GST packages). Finally landed on
alawenc/dec. Suitably altered the clock-rate and nixed gstrtpbin and
behold, pretty good sound. A mite echoy but WAY better.
So, these are the best pipes I have right now:
SENDER:
gst-launch-0.10 -e -v \
alsasrc do-timestamp=true \
! queue2 \
! alawenc \
! udpsink port=5002 host=$1
RECEIVER:
gst-launch-0.10 -v \
udpsrc caps="audio/x-alaw, channels=2, rate=29000" \
port=5002 \
! queue2 \
! alawdec \
! volume volume=0.1 \
! queue2 \
! pulsesink
Thanks for all the help, M4arco.
Wes
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Choppy-Audio-over-UDP-tp2997741p3002698.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
------------------------------
Message: 7
Date: Tue, 19 Oct 2010 21:51:30 +0200
From: Arnout Vandecappelle <[hidden email]>
Subject: Re: [gst-devel] Reduce latency for a MJPEG over UDP multicast
pipe
To: [hidden email]
Cc: STJME <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: Text/Plain; charset="us-ascii"
On Friday 08 October 2010 15:32:22, STJME wrote:
> Another thing is that it appears as if the RTP protocol adds substantial
> delay (70ms or so). By using raw UDP we could decrease the delay. However,
> that is quite uggly. The best thing would be to try to tweek the RTP stack.
> We have tryied, but cannot see any effect. Do you know anything about that?
I didn't know about that... At reception side, RTP has a jitterbuffer which
reorders packets and compensates for clock and network jitter, but I guess you
already configured that down to the minimum.
Do you know if this latency is caused by the sender or by the receiver?
Regards,
Arnout
PS If you want a quick reply, CC me, since I don't read the list very often
:-)
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
------------------------------
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
End of gstreamer-devel Digest, Vol 53, Issue 52
***********************************************
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
|
Locked
