1. How to Stop/start recording using Valve element
harish jenny
harishjennykn at yahoo.com
Tue Aug 27 23:26:02 PDT 2013
You can alternatively use
'async=false' property of filesink element to force the pipeline to go to PLAYING state.
________________________________
From: harish jenny <harishjennykn at yahoo.com>
To: "gstreamer-devel at lists.freedesktop.org" <gstreamer-devel at lists.freedesktop.org>
Sent: Tuesday, 27 August 2013 12:00 PM
Subject: Re: 1. How to Stop/start recording using Valve element
Not sure how you change the pipeline dynamically in the code to launch two different pipeline.
Both valve and identity plugin blocks the entire pipeline when drop properties are set during gst-launch as the pipeline elements will only be prerolled.
Solution to stop the data passing in one side of the tee element which I can think of is -
Launch the pipeline by creating individual elements by gst_element_factory_make and then
*) Probe the data and drop the buffers as mentioned in
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-dataaccess.html
Regards,
Harish Jenny K N
________________________________
From: "gstreamer-devel-request at lists.freedesktop.org" <gstreamer-devel-request at lists.freedesktop.org>
To: gstreamer-devel at lists.freedesktop.org
Sent: Monday, 26 August 2013 6:33 PM
Subject: gstreamer-devel Digest, Vol 31, Issue 80
Send gstreamer-devel mailing list submissions to
gstreamer-devel at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
or, via email, send a message with subject or body 'help' to
gstreamer-devel-request at lists.freedesktop.org
You can reach the person managing the list at
gstreamer-devel-owner at lists.freedesktop.org
When replying, please edit your Subject
line so it is more specific
than "Re: Contents of gstreamer-devel
digest..."
Today's Topics:
1. How to Stop/start recording using Valve element (Harish Sakhare)
2. Re: tcpclient failing to detect EOF/EOS? (Peter Maersk-Moller)
3. Problems with gstreamer on Raspberry PI (quali)
4. problem in linking filesrc and video converter (nikit)
5. Is there any proper element that is opposited of funnel? (???)
6. Re: appsrc and GMainloop problem (Deepak Jain)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Aug 2013 04:49:52 -0700 (PDT)
From: Harish Sakhare <harish_sakhare at yahoo.com>
To: gstreamer-devel at lists.freedesktop.org
Subject: How to Stop/start recording using
Valve element
Message-ID: <1377517792915-4661728.post at n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
Hello All,
I am sending a video stream using a C920 HD camera as
an MP2TS stream. I am able to see video on android tablet also I used "tee"
element to record the video. To start stop video recording I am using
"valve" element. The default property of valve=FALSE so I used it in my
pipeline it works well the streaming as well as recording is done. But when
I used valve = TRUE to stop recording then it stops streaming also.
Streaming gets stuck just one frame is displayed on the screen.
Here below is my working pipeline with recording:--
data->pipeline =
gst_parse_launch("udpsrc
caps=\"video/mpegts,
systemstream=(boolean)true, packet-size=(int)188\" ! tsdemux ! h264parse !
tee name=myvid ! queue ! amcviddec-omxtiducati1videodecoder ! eglglessink
myvid. ! queue ! filesink location=/storage/sdcard0/Movies/Test.mp4",
&error);
Here below is my pipeline where streaming gets STUCK:-
data->pipeline = gst_parse_launch("udpsrc caps=\"video/mpegts,
systemstream=(boolean)true, packet-size=(int)188\" ! tsdemux ! h264parse !
tee name=myvid ! queue ! amcviddec-omxtiducati1videodecoder ! eglglessink
myvid. ! valve drop = true ! queue ! filesink
location=/storage/sdcard0/Movies/Test.mp4",
&error);
So please any one guide how to use Valve to stop recording and how I used it
in my pipeline.
I would appreciate any help for my problem.
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/How-to-Stop-start-recording-using-Valve-element-tp4661728.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
------------------------------
Message: 2
Date: Mon, 26 Aug 2013 14:46:12 +0200
From: Peter Maersk-Moller <pmaersk at gmail.com>
To: Discussion of the development of and with GStreamer
<gstreamer-devel at lists.freedesktop.org>
Subject: Re: tcpclient failing to detect EOF/EOS?
Message-ID:
<CAGf_jGmM14o5vVZOLW4rhTQPwNs5Bv2-Uexb=2Nxb6iar=NMdw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Timm-Phillipp
See comments in-line.
On Sun, Aug 25, 2013 at 2:14 PM, Tim-Philipp M?ller <t.i.m at zen.co.uk> wrote:
> On Sat, 2013-08-24 at 23:59 +0200, Peter Maersk-Moller wrote:
> Hi,
> > Yes, the prerolling receiver needs a queue that in this case will make
> > the pipeline change to playing after it has prerolled. However, that
> > is mostly besides the point.
> It is not besides the point, because without the pipeline prerolling EOS
> propagation will not work.
>
Right. So what you are saying is this: While a pipeline is
prerolling, it
can NOT propagate EOS and later on you write that if a source detects EOF,
it signals to the sink of the pipeline and then the sink may
later signal
EOS, when it enters Playing state.
Then I conclude this: If GStreamer has no other way to handle EOF for input
while prerolling, then GStreamer pipelines has a race condition and as such
it can be impossible to determine the exact outcome of a particular
scenario. Now I will not race to conclusion and race condtions can be many
things and even okay if handled properly, but here the pipeline ends up
doing nothing just sitting there and that somehow sounds pretty bad to me.
Don't you think that is a problem?
Somehow the sink needs to detect if it will NOT receive more data from
upstream, and if the pipeline is still prerolled, the sink should send the
EOS upstream. At least that that is the only way I know a pipeline will
terminate.
Am I wrong ?
> Apparently tcpclientsrc fails to make the pipeline terminate upon
> > EOS/EOF if it is in its prerolling state.
>
>
It is not the source that terminates the pipeline on EOS. It pushes an
> EOS even into the pipeline, which then needs to filter through to sinks,
> which then post EOS messages on the bus, which the pipeline then
> aggregates.
>
True, but problem still apply.
>
> > If the tcpserversink disconnects or the connection is disconnected
> > for any other reason while the receiver pipeline with tcpclientsrc is
> > prerolling, the pipeline may never enter playing state and
> > subsequently the pipeline is not terminated even though its source had
> > its conection terminated. or at least that is what I seem to
> > experience.
>
> Does the sink not post an error messages if its connection is
> disconnected by the peer? Shouldn't it?
>
Not sure if it does, but the sink at the end of the pipeline should somehow
detects when it
will never leave the prerolling state and terminate.
Otherwise you have the race condition. And that is often pretty bad.
Best regards
Peter Maersk-Moller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130826/f0455815/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 26 Aug 2013 05:40:30 -0700 (PDT)
From: quali <alex.pessoa at qualihouse.com.br>
To: gstreamer-devel at lists.freedesktop.org
Subject: Problems with gstreamer on Raspberry
PI
Message-ID: <1377520830522-4661729.post at n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
Hello, I developed an application using gstreamer to play songs in sequence
on Raspberry PI, the problem is that sometimes the application does not play
the sound, but throws no errors and seems to be working, just no sound. I
also realized that sometimes even closing and opening the application again
it still does not work, even resetting the operating system. I tested the
same application on Ubuntu on a PC and it worked normally. Does the problem
is the ARM architecture Rasperry PI that gstreamer does not support right? I
am being pressed to solve this problem, can someone help me?
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Problems-with-gstreamer-on-Raspberry-PI-tp4661729.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
------------------------------
Message: 4
Date: Mon, 26 Aug 2013 05:41:08 -0700 (PDT)
From: nikit <nikitbiraj at gmail.com>
To: gstreamer-devel at lists.freedesktop.org
Subject: problem in linking filesrc and video converter
Message-ID: <1377520868751-4661730.post at n4.nabble.com>
Content-Type: text/plain;
charset=us-ascii
Hi,
I am working on encoding a raw file image to jpeg image in C
Below is working structure in comand line to encode image :
gst-launch filesrc location=/home/root/one.raw blocksize=608256 ! \
'video/x-raw-yuv,
format=(fourcc)I420,width=(int)704,height=(int)576,framerate=(fraction)0/1'
! ffmpegcolorspace !
'video/x-raw-yuv,format=(fourcc)I420,width=(int)704,height=(int)576,,framerate=(fraction)0/1'
! vpuenc codec = 12 ! \
filesink location=/home/root/image.jpg
Below are pipeline structure :
app->src = gst_element_factory_make("filesrc", "mysrc");
app->encoder = gst_element_factory_make("vpuenc", "enc");
app->video_convert = gst_element_factory_make ("ffmpegcolorspace",
"converter");
app->imagesink = gst_element_factory_make("filesink", "myvsink");
have created all elements, objects.
g_object_set
(app->src, "blocksize", BUFF_SIZE, NULL);
where BUFF_SIZE is 608256
g_object_set (app->encoder, "codec", 12, NULL);
gst_bin_add_many(GST_BIN(app->pipeline),
(GstElement*)app->src,app->video_convert,app->encoder,
app->imagesink, NULL);
filesrc location using : g_object_set(G_OBJECT(app->src),
"location", "/home/root/one.raw",NULL);
and,
filesink location using : g_object_set(G_OBJECT(app->imagesink),
"location", "/home/root/tr2.jpg",NULL);
I am getting link failed when I try to link app->src and
app->video_convert,
and
app->video_convert and app->encoder
Below is C code for linking :
link_ok = gst_element_link_filtered (app->src, app->video_convert,
gst_caps_new_simple
("video/x-raw-yuv",
"format",
G_TYPE_STRING, "I420",
"width",G_TYPE_INT,
704,
"height",G_TYPE_INT,
576,
//"framerate",GST_TYPE_FRACTION, 0,1,
NULL));
and
link_ok = gst_element_link_filtered (app->video_convert, app->encoder,
gst_caps_new_simple
("video/x-raw-yuv",
"format",
G_TYPE_STRING, "I420",
"width",G_TYPE_INT, 704,
"height",G_TYPE_INT, 576,
"framerate",GST_TYPE_FRACTION, 1,1,
//
"pixel-aspect-ratio",GST_TYPE_FRACTION,1,1,
NULL));
Surprisingly the same caps works in command line but if I link through C its
giving error.
What am I doing wrong?
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/problem-in-linking-filesrc-and-video-converter-tp4661730.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
------------------------------
Message: 5
Date: Mon, 26 Aug 2013 21:44:23 +0900
From: ??? <hoonh83.lee at gmail.com>
To: gstreamer-devel at lists.freedesktop.org
Subject: Is there any proper element that is opposited of funnel?
Message-ID:
<CAE-EkXOOhHyYp216HBLj+-FwCKDSf6sJyufVHq3J1XLEb7bD2g at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello
When
playing multiple audio or video stream, I am using funnel instead of
using input-selector and I am trying to use output-selector before linking
fakesink.
this is my approach.
/ ac3parse - capsfilter - decoder \
/ fakesink
demux - multiqueue - ac3parse - capsfilter - decoder - funnel -
output-selector - fakesink
\ ac3parse - capsfilter - decoder /
\ fakesink
\ h264parse - capsfilter - decoder -
input-selector - fakesink
Actually, I could not find a proper element that is opposited element of
funnel.
So I am not sure this approach is proper or not?
And I am wondering that output-selector is a kind of opposite of funnel.
Thus, Please let me know if you have correct approach or some advice.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130826/bd200533/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 26 Aug 2013 18:33:26 +0530
From: Deepak Jain <jain1982 at gmail.com>
To: Discussion of the development of and with GStreamer
<gstreamer-devel at lists.freedesktop.org>, t.i.m at zen.co.uk
Subject: Re: appsrc and GMainloop problem
Message-ID:
<CAJhXTGc4GAbMJrZJ=h5xThTdvoeamY0emWZYCfyDjqDsunbj3Q at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
OK...i removed "codec_data" parameter from caps.
But still I dont know why I am getting same no decoder context error
like:
0:00:09.504370712 10014 0xb384f80 DEBUG
ffmpeg
gstffmpegcodecmap.c:2398:gst_ffmpeg_caps_with_codecid: have codec data of
size 53
0:00:09.504388937 10014 0xb384f80 DEBUG ffmpeg
gstffmpegcodecmap.c:2088:gst_ffmpeg_caps_to_pixfmt: converting caps
video/x-h264, width=(int)320, height=(int)240, parsed=(boolean)true,
stream-format=(string)avc, alignment=(string)au,
pixel-aspect-ratio=(fraction)4/3,
codec_data=(buffer)014d400dffe10025674d400dec80a0fd8750808080a000007d200017701c00002b160002b079351807c50a448001000568ebec6c80
0:00:09.504452406 10014 0xb384f80 DEBUG ffmpeg
gstffmpegcodecmap.c:2118:gst_ffmpeg_caps_to_pixfmt: setting
pixel-aspect-ratio 3/4 = 0.750000
0:00:09.504476042 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:781:gst_ffmpegdec_setcaps:<mydecoder>
forcing 25/1 framerate
0:00:09.504492294 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:793:gst_ffmpegdec_setcaps:<mydecoder> sink caps have
pixel-aspect-ratio of 4:3
0:00:09.504509792 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:811:gst_ffmpegdec_setcaps:<mydecoder> Using framerate from
codec
0:00:09.504522619 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:818:gst_ffmpegdec_setcaps:<mydecoder> trying to enable
direct rendering
0:00:09.504537396 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:821:gst_ffmpegdec_setcaps:<mydecoder> disable direct
rendering setup for H264
0:00:09.548427471 10014 0xb384f80 DEBUG
ffmpeg
gstffmpegdec.c:895:gst_ffmpegdec_setcaps:<mydecoder:sink> clipping to
320x240
0:00:09.548465407 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:904:gst_ffmpegdec_setcaps:<mydecoder:sink> final clipping to
320x240
0:00:09.548480556 10014 0xb384f80 DEBUG GST_CAPS
gstpad.c:2741:gst_pad_set_caps:<mydecoder:sink> caps 0xb376a00
video/x-h264, width=(int)320, height=(int)240, parsed=(boolean)true,
stream-format=(string)avc, alignment=(string)au,
pixel-aspect-ratio=(fraction)4/3,
codec_data=(buffer)014d400dffe10025674d400dec80a0fd8750808080a000007d200017701c00002b160002b079351807c50a448001000568ebec6c80
0:00:09.548699885 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:2549:gst_ffmpegdec_chain:<mydecoder>
received DISCONT
0:00:09.548723745 10014 0xb384f80 ERROR ffmpeg
gstffmpegdec.c:2341:gst_ffmpegdec_frame:<mydecoder> no codec context
0:00:09.549552644 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:2566:gst_ffmpegdec_chain:<mydecoder> waiting for keyframe
0:00:09.549607984 10014 0xb384f80 DEBUG ffmpeg
gstffmpegdec.c:2571:gst_ffmpegdec_chain:<mydecoder> got keyframe
0:00:09.549626379 10014 0xb384f80 ERROR ffmpeg
gstffmpegdec.c:2341:gst_ffmpegdec_frame:<mydecoder> no codec context
As I can see from logs, everything is setting perfectly but still no codec
context.
Is it something related to DISCONT?
Thanks for all your help Tim.
Amy be I am
very close..just a couple of steps away from actual playback:(
On Mon, Aug 26, 2013 at 3:39 PM, Tim-Philipp M?ller <t.i.m at zen.co.uk> wrote:
> On Mon, 2013-08-26 at 12:58 +0530, Deepak Jain wrote:
>
> > On appsrc, I am setting Caps as :
> >
> > GstBuffer* buf = gst_buffer_new_and_alloc(extradatalen);
> > memcpy(GST_BUFFER_DATA(buf), extradata, extradatalen);
> > GstCaps* caps = gst_caps_new_simple ("video/x-h264",
> > "codec_data", GST_TYPE_BUFFER, buf,
> > "stream-format", G_TYPE_STRING, "byte-stream",
> > "width", G_TYPE_INT, <Width>,
> >
"height", G_TYPE_INT,
<Height>,
> > "pixel-aspect-ratio", GST_TYPE_FRACTION, <PixelAspectRatioX>,
> > <PixelAspectRatio>,
> > "framerate", GST_TYPE_FRACTION, <RateValue>, <RateScale>,
> > NULL);
> With H.264 in byte-stream format, you should not have codec_data in the
> caps. Instead, the SPS/PPS should be sent as data in the stream (note:
> in proper byte-stream format of course).
>
> The parser might just assume it's AVC when it sees codec_data.
>
> Cheers
> -Tim
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130826/f87b2b99/attachment.html>
------------------------------
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
End of gstreamer-devel Digest,
Vol 31, Issue 80
***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130828/14a91cae/attachment-0001.html>
More information about the gstreamer-devel
mailing list