Message: 1 Date: Fri, 5 Oct 2018 07:37:45 -0500 (CDT) From: klex0 <[hidden email]> To: [hidden email] Subject: Gstreamer / Multithreading problem Message-ID: <[hidden email]> Content-Type: text/plain; charset=us-ascii
I use Gstreamer together with the Python Twisted Framework. There seems to be a race condition when sending events in the pipeline. With many parallel pipelines which I dynamically create and terminate, a thread hangs reproducibly in the marked line. This seems to happen during a context switch of a twisted thread within this line.
log.msg("TERM: gen EOS") eos = Gst.Event.new_eos() log.msg("TERM: send EOS") self.pipeline.send_event(eos) <-- Here it hangs log.msg("TERM: EOS sent to pipline")
Message: 2 Date: Fri, 5 Oct 2018 14:39:50 +0200 From: Wolfgang Grandegger <[hidden email]> To: [hidden email] Subject: Re: Low latency streaming over the network, time sync Message-ID: <[hidden email]> Content-Type: text/plain; charset="utf-8"
Am 05.10.2018 um 10:53 schrieb Wolfgang Grandegger:
> Hello, > > Am 04.10.2018 um 17:44 schrieb Nicolas Dufresne: >> Le jeudi 04 octobre 2018 à 11:09 +0200, Wolfgang Grandegger a écrit : >>> Hello, >>> >>> I'm looking into low latency real-time streaming of MJPEG videos over >>> the network with GStreamer. I wonder what module does the frame >>> synchronisation on the receivers side and how. On the sender I start: >>> >>> # gst-launch-1.0 filesrc location=output.avi ! avidemux name=demux >>> demux.video_0 ! vaapipostproc ! vaapijpegenc quality=50 ! rtpjpegpay >>> ! >>> udpsink host=192.168.178.52 port=50004 >>> >>> and on the receiver: >>> >>> # gst-launch-1.0 udpsrc port=50004 ! >>> application/x-rtp,encoding-name=JPEG,payload=26 ! queue ! >>> rtpjpegdepay ! >>> vaapijpegdec ! vaapipostproc ! vaapisink >> >> To you first question, none in your pipeline. You'll need a >> jitterbuffer to handle the time, ideally with do-timestamp=1 on the >> udpsrc element. >> >>> >>> I have some basic questions: >>> >>> - Are the frames displayed as they arrive (in "udpsrc")? >> >> It will depends on the jitterbuffer "mode" property. By default it will >> try to slave to the remote clock. This mode is not extremely accurate >> though. > > I see, I will have a closer look into the various modes. Then also > synchronizing clocks of the participating systems is important. Are > there documents around highlighting that topic?
The problem is that all variations of this that I try give a "Delayed linking failed" error - here is an example:
Setting pipeline to PAUSED ...[68219.713998] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1 Pipeline is PREROLLING ... WARNING: from element /GstPipeline:pipeline0/GstMatroskaDemux:d: Delayed linking failed. Additional debug info: ../../../gstreamer-1.12.2/gst/parse/grammar.y(510): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstMatroskaDemux:d: failed delayed linking pad video_00 of GstMatroskaDemux named d to some pad of GstQueue named queue0 ERROR: from element /GstPipeline:pipeline0/GstMatroskaDemux:d: Internal data stream error. Additional debug info: ../../../gst-plugins-good-1.12.2/gst/matroska/matroska-demux.c(4799): gst_matroska_demux_loop (): /GstPipeline:pipeline0/GstMatroskaDemux:d: streaming stopped, reason not-linked (-1) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ...
How can I extract one video stream from the matroska file? Thanks.
Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181005/1f6a67a3/attachment-0001.html>
I am working on maintaining a plugin that writes directly to raw buffers and noticed that sometimes raw video buffers have an inconsistent size after decoding. Attempting to characterize the size led me to discover that it hinges on a multitude of variables; I have observed variance with resolution, codec, video sink, Gstreamer version, and possibly OS. I have tested Gstreamer on Windows (7 and 10) and Linux (Centos 7, Fedora 27, Ubuntu 16, 18, and Arch) with most versions from 1.8.3 to 1.14.1; each of these having minute differences in their results. I have also tested briefly on Windows 7 with Gstreamer 0.10.36 and could not replicate the issue.
Here's a specific example on Windows 10, Gstreamer 1.10.4, coding a single frame of a 1280x720 I420 test signal into H.264, then decoding and displaying the frame:
After running this command, the chain message reveals the buffer size in identity raw1 is as expected ( 1280 * 720 * 1.5 = 1,382,400 bytes ) but the buffer size observed in identity raw2 is completely different at 1,596,672 bytes. Switching d3dvideosink to glimagesink or fakevideosink results in raw2's buffer size becoming 1,629,056 bytes, but using fakesink, appsink, or filesink all result in the expected buffer size, 1,382,400 bytes. Changing the codec results in different results yet again, such as in this example: on Ubuntu 16, Gstreamer 1.13.0, coding the same test signal into H.265, then decoding and displaying:
This resulted in a 1,624,832 byte buffer. I also tried 1920x1080 and 720x480, which resulted in buffer sizes of 3,444,756 and 640,640 bytes, respectively. I have also tested codecs that are not implemented in libav, such as jpeg, openjpeg, png, vp8 and vp9, but only vp9 had a similar ailment.
If anyone can help narrow down the cause of this or how to accommodate for the extra buffer size in my plugin development, it would be greatly appreciated.
Thank you, Jon Titzell Software Engineer L3 Technologies MID ------------------------------------------- CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181005/6bc0a8de/attachment.html>