Asnc-Handling On autovideosink

[Michael MacIntosh]

Hi, I recently started working with gstreamer, and I am trying to make a 
video pipeline where you can watch the video while it is being recorded 
from a live source (an ip camera).  I got something to work, but I do 
not know why it works.

I should start off with I am using the prebuilt windows binary version 
1.11.2 of gstreamer.

The problem I am facing is that setting async-handling to true on the 
autovideosink causes everything to work, but if it is set to false, the 
pipeline is frozen and never starts.

I got to this solution from this Stack Overflow answer:

http://stackoverflow.com/a/8532148/5125564

However the documentation:

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstBin.html#GstBin--async-handling

States that it should only be used if the bin subclass is modifying the 
state of its children on its own, which I don't think autovideosink does.

I just want to make sure I am not doing anything wrong that will come to 
bite me later.



Here is a gst-launch command line to recreate the situtation (this 
command line works).

gst-launch-1.0.exe --gst-debug-level=3 uridecodebin 
uri=rtsp://{username}:{password}@{ip_address} ! queue ! tee name=t ! 
autovideosink async-handling=true t. ! x264enc ! mp4mux ! filesink 
location=C:\\GStreamerTests\\taco123.mp4

And I get this output:

Setting pipeline to PAUSED ...
0:00:00.121268503 19384 00000000042111E0 WARN d3dvideosink 
d3dhelpers.c:1103:d3d_set_window_handle:<autovideosink0-actual-sink-d3dvideo> 
Window HWND already set to: 0
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://{username}:{password}@{ip_address}
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:Progress: (request) Sending PLAY request
00:00.556251111 Progress: (request) Sending PLAY request
19384 0000000004290840 FIXME                default 
gstutils.c:3829:gst_pad_create_stream_id_internal:<fakesrc0:src> 
Creating random stream-id, consider implementing a deterministic way of 
creating a stream-id
Progress: (request) Sent PLAY request
Redistribute latency...
Redistribute latency...
0:00:03.572875522 19384 00000000033E9580 FIXME basesink 
gstbasesink.c:3144:gst_base_sink_default_event:<filesink0> stream-start 
event without group-id. Consider implementing group-id handling in the 
upstream elements
Redistribute latency...


However, if I change async handling from true to false (or just remove 
it because the default is false).  I get this command line (this command 
line does NOT work):

gst-launch-1.0.exe --gst-debug-level=3 uridecodebin 
uri=rtsp://{username}:{password}@{ip_address} ! queue ! tee name=t ! 
autovideosink async-handling=false t. ! x264enc ! mp4mux ! filesink 
location=C:\\GStreamerTests\\taco123.mp4

And I get this output:

Setting pipeline to PAUSED ...
0:00:00.145754270 21360 00000000042391E0 WARN d3dvideosink 
d3dhelpers.c:1103:d3d_set_window_handle:<autovideosink0-actual-sink-d3dvideo> 
Window HWND already set to: 0
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://{username}:{password}@{ip_address}
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSyste0mC:00:00.608258221 lock
213Progress: (request) Sending PLAY request
60 00000000042AC840 Progress: (request) Sending PLAY request
FIXME                default 
gstutils.c:3829:gst_pad_create_stream_id_internal:<fakesrc0:src> 
Creating random stream-id, consider implementing a deterministic way of 
creating a stream-id
Progress: (request) Sent PLAY request
Redistribute latency...

Then nothing happens until i ctrl+c the process.

Any feedback is welcome.  Thanks in advance!

Cheers,

Michael.



--
This message has been scanned by E.F.A. Project and is believed to be clean.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170428/206ae434/attachment.html>