I am quite new to gstreamer and trying to get some metrics on an existing pipeline. The pipeline is set as 'appsrc queue mpegvideoparse avdec_mpeg2video deinterlace videobalance xvimagesink'.
xvimagesink only has a sink pad and I am not sure where and how its output is connected to but I am interested in knowing when the actual video device/buffer displays the first I frame and then video starts rolling.
The application sets the pipeline state to 'playing' quite early on, so, listening on this event does not help.
Regards,
Check out GST_MESSAGE_STREAM_START and probes. However, I am not sure, what exactly do you want: at GStreamer level you can only detect moment when buffer is handled via some element, not when it's actually displayed.
xvimagesink has no srcpad (output), only sinkpad (input).
You can read about preroll here: http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-preroll.txt
Be sure to read GStreamer manual first:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.html
Related
I am developing an Nvidia deepstream inference application with multiple RTSP sources.
Where each individual source is constructed using uridecodebin plugin. Until this point, I have developed a pipeline with multiple source bins connected to a typical inference pipeline as per our use case something like this.
[source-bin-0]---[Pipeline as per Nvidia Deepstream Inference plugins]
[source-bin-%d]
is either [uridecodebin] or [rtspsrc--decodebin].
Which is working totally fine!
I am looking to incorporate RTSP reconnection in case any of the RTSP sources (camera) is down for a while and comes up after some time.
In case of a source error, I am setting a particular uridecodebin state to NULL and then to PLAY again.
My observations after performing some test cases are:
When I am using [rtspsrc-decodebin] as the source-bin my reconnection logic of setting the state to NULL and PLAY works fine and I am able to reconnect to my RTSP source successfully. Here when I set the source-bin state to PLAY it returns me GST_STATE_CHANGE_ASYNC and the source-bin is able to provide frames to the upstream elements.
But In the case of [uridecodebin] as the source-bin, my same reconnection logic does not work. Here the observation is after I set the source-bin state to PLAY it returns me GST_STATE_CHANGE_NO_PREROLL and my overall pipeline gets stuck. It is not giving me the further error of source disconnected but also not able to provide frames to the upstream elements.
The main difference I can conclude here is that when I am using uridecodebin and changing state to PLAY it is returning with GST_STATE_CHANGE_NO_PREROLL and I am not able to reconnect, while with rtspsrc it is returning GST_STATE_CHANGE_ASYNC and I am able to connect.
I am seeking help to successfully reconnect to my RTSP source when I am using uridecodebin as the source-bin.
Thank you in advance!!
I would like to use gstreamer to play multiple sources (for instance two video files) simultaneously using a single pipeline but each video starting from a different position, for instance first video from the beginning and the second from the middle. Could someone guide me on how to achieve it?
Simplifying, my pipeline is an equivalent of:
gst-launch-1.0 \
uridecodebin uri=file:///Users/tmikolaj/Downloads/videoalpha_video_dancer1.webm ! videoconvert ! autovideosink \
uridecodebin uri=file:///Users/tmikolaj/Downloads/videoalpha_video_dancer1.webm ! videoconvert ! autovideosink
, but created programmatically.
Obviously, simple seeking the pipeline seeks two files at once.
I was trying to register a probe of the GST_PAD_PROBE_TYPE_EVENT_UPSTREAM type from inside the pad-added signal callback of the uridecodebin element. Inside the probe I wanted to catch the GST_EVENT_SEEK event and drop it for the first video. However, it seems that dropping the SEEK message leaves pipeline in a PAUSED state and even an explicit state change to PLAYING does nothing.
Does anybody has some hints on how to solve that problem?
I have a two GStreamer pipelines, one is like a "source" pipeline streaming a live camera feed into an external channel, and the second pipeline is like a "sink" pipeline that reads from the other end of that channel and outputs the live video to some form of sink.
[videotestsrc] -> [appsink] ----- Serial Channel ------> [appsrc] -> [autovideosink]
First Pipeline Second Pipeline
The first pipeline starts from a videotestsrc, encodes the video and wraps it in gdppay payload, and then sinks the pipeline into a serial channel (but for the sake of the question, any sink that can be read from to start another pipeline like a filesink writing to serial port or udpsink), where it is read by the source of the next pipeline and shown via a autovideosrc:
"Source" Pipeline
gst-launch-1.0 -v videotestsrc ! videoconvert ! video/x-raw,format=I420 ! x265enc ! gdppay ! udpsink host=127.0.0.1 port=5004
"Sink" pipeline
gst-launch-1.0 -v udpsrc uri=udp://127.0.0.1:5004 ! gdpdepay ! h265parse ! avdec_h265 ! autovideosink
Note: Given the latency induced using a udpsink/udpsrc, that pipeline complains about timestamp issues. If you replace the udpsrc/udpsink with a filesrc/filesink to a serial port you can see the problem that I am about to describe.
Problem:
Now that I have described the pipelines, here is the problem:
If I start both pipelines, everything works as expected. However, if after 30s, I stop the "source" pipeline, and restart the pipeline, the Running Time gets reset back to zero, causing the timestamps of all buffers to be sent to be considered old buffers by the sink pipeline because it has already received buffers for timestamps 0 through 30s, so the playback on the other end won't resume until after 30s:
Source Pipeline: [28][29][30][0 ][1 ][2 ][3 ]...[29][30][31]
Sink Pipeline: [28][29][30][30][30][30][30]...[30][30][31]
________________________^
Source pipeline restarted
^^^^^^^^^^^^^^^^...^^^^^^^^
Sink pipeline will continue
to only show the "frame"
received at 30s until a
"newer" frame is sent, when
in reality each sent frame
is newer and should be shown
immediately.
Solution
I have found that adding sync=false to the autovideosink does solve the problem, however I was hoping to find a solution where the source would send its timestamps (DTS and PTS) based on the Clock time as seen in the image on that page.
I have seen this post and experimented with is-live and do-timestamp on my video source, but they do not seem to do what I want. I also tried to manually set the timestamps (DTS, PTS) in the buffers based on system time, however to no avail.
Any suggestions?
I think you should just restart the receiver pipeline as well. You could add the -e switch to the sender pipeline and when you stop the pipeline it should correctly propagate EOS via the GDP element to the receiver pipeline. Else I guess you can send a new segment or discontinuity to the receiver. Some event has to be signaled though to make the pipeline aware of that change, else it is somewhat bogus data. I'd say restarting the receiver is the simplest way.
I need to implement an architecture where I can push data from AppSink to
Appsrc.
Now, I can't figure out if it can be done within the same pipeline or I
would need two pipelines to achieve this. Considering I am somehow
manipulating the data between apppsink and appsrc.
Another thing is, from AppSink I can extract samples using pull-samples, and to AppSrc push-sample or push-buffer can be used to put data. So, is there a way I can generate a buffer of received samples in AppSink explicitly or I should feed sample by sample to the AppSrc?
Please suggest.
I am developing an application which plays H264 dump using gstreamer
The pipeline is: appsrc - h264parse - ffdec_h264 - ffmpegcolorspace - deinterlace - autovideosink
And data flow is :: PULL Mode from appsrc { using the signals: need-data}
I want to verify the same application using PUSH mode from application: In the documentation it is mentioned that: we need to invoke 'push-buffer' signals and send the buffers
My code snippet is:
gst_app_src_set_emit_signals(source, TRUE);
g_signal_connect (source, "push-buffer", G_CALLBACK (start_feed), source);
Though the pipeline is created, I am not getting any callbacks to : start_feed()
Can anyone help me, what exactly need to do for 'PUSH' mode operation of appsrc.
According to the documentation:
Make appsrc emit the "new-preroll" and "new-buffer" signals. This option is by default disabled because signal emission is expensive and unneeded when the application prefers to operate in pull mode.
So, you could try adding a "new-buffer" signal. "push-buffer" is an action, so attaching a signal handler won't do anything because it's something you're supposed to call when you have data, not something that calls a callback.
Depending on what your start_feed does, you may also be looking for the "need-data" signal (presumably signals when the pipeline needs more data).