gstreamer-devel Digest, Vol 93, Issue 17
何昆
hekun_hekun at 163.com
Sat Oct 6 03:13:28 UTC 2018
help
| |
何昆
|
|
邮箱：hekun_hekun at 163.com
|
签名由 网易邮箱大师 定制
On 10/06/2018 05:56, gstreamer-devel-request at lists.freedesktop.org wrote:
Send gstreamer-devel mailing list submissions to
gstreamer-devel at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
https://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. Gstreamer / Multithreading problem (klex0)
2. Re: Low latency streaming over the network, time sync
(Wolfgang Grandegger)
3. Extract 1 Video Channel from H.264 encoded multi-stream
Matroska File (Class, Phil)
4. Decoded raw buffer sizes inconsistent (Jon.Titzell at L3T.com)
----------------------------------------------------------------------
Message: 1
Date: Fri, 5 Oct 2018 07:37:45 -0500 (CDT)
From: klex0 <alex at kordecki.de>
To: gstreamer-devel at lists.freedesktop.org
Subject: Gstreamer / Multithreading problem
Message-ID: <1538743065522-0.post at n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
Hello,
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")
Has anyone an idea about this ?
Regards,
alex
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
------------------------------
Message: 2
Date: Fri, 5 Oct 2018 14:39:50 +0200
From: Wolfgang Grandegger <wg at grandegger.com>
To: gstreamer-devel at lists.freedesktop.org
Subject: Re: Low latency streaming over the network, time sync
Message-ID: <3d07b69e-94cb-6388-90ed-5e5372d10cce at grandegger.com>
Content-Type: text/plain; charset="utf-8"
Hello,
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 following README was already useful:
https://fossies.org/linux/gst-plugins-good/gst/rtp/README
Wolfgang.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181005/6f7925a0/attachment-0001.sig>
------------------------------
Message: 3
Date: Fri, 5 Oct 2018 12:45:28 +0000
From: "Class, Phil" <phil.class at fluke.com>
To: "gstreamer-devel at lists.freedesktop.org"
<gstreamer-devel at lists.freedesktop.org>
Subject: Extract 1 Video Channel from H.264 encoded multi-stream
Matroska File
Message-ID:
<SN1PR12MB2560B56AD198927AF017FB9799EB0 at SN1PR12MB2560.namprd12.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
On Linux, I am able to mux the streams from 2 different V4L2 webcams into a Matroska container with the following pipeline:
gst-launch-1.0 -v -e \
v4l2src device=/dev/video2 io-mode=4 \
! 'video/x-raw, format=(string)UYVY, width=(int)160, height=(int)120' \
! videoconvert \
! 'video/x-raw, format=(string)NV12, width=(int)160, height=(int)120' \
! ducatih264enc \
! queue \
! "video/x-h264,width=160,height=120" \
! h264parse \
! queue \
! mux. \
v4l2src device=/dev/video1 \
! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 \
! 'video/x-raw, format=(string)YUY2, width=(int)640, height=(int)480, framerate=30/1' \
! videoconvert \
! 'video/x-raw, format=(string)NV12, width=(int)640, height=(int)480' \
! ducatih264enc \
! queue \
! "video/x-h264,width=640,height=480" \
! h264parse \
! queue \
! mux. \
matroskamux name=mux min-index-interval=1000000000 \
! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 \
! filesink location=test-video.mkv
Now I want to be able to exract one of those video streams like shown in: https://gstreamer.freedesktop.org/documentation/tutorials/basic/gstreamer-tools.html
Basic tutorial 10: GStreamer tools<https://gstreamer.freedesktop.org/documentation/tutorials/basic/gstreamer-tools.html>
gstreamer.freedesktop.org
Basic tutorial 10: GStreamer tools Goal. GStreamer comes with a set of tools which range from handy to absolutely essential. There is no code in this tutorial, just sit back and relax, and we will teach you:
I am trying to use the pipeline:
gst-launch-1.0 filesrc location=test-video.mkv ! matroskademux name=d d.video_00 ! queue ! video/x-h264 ! queue ! h264parse ! ducatih264dec ! waylandsink sync=false
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>
------------------------------
Message: 4
Date: Fri, 5 Oct 2018 21:00:24 +0000
From: <Jon.Titzell at L3T.com>
To: <gstreamer-devel at lists.freedesktop.org>
Subject: Decoded raw buffer sizes inconsistent
Message-ID:
<BN3P110MB0292B4340ECE2D97AFDDD41FADEB0 at BN3P110MB0292.NAMP110.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="utf-8"
Hello,
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:
gst-launch-1.0.exe -v videotestsrc num-buffers=1 \
! video/x-raw,width=1280,height=720,format=I420 \
! identity name=raw1 silent=false \
! x264enc \
! avdec_h264 \
! identity name=raw2 silent=false \
! d3dvideosink
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:
gst-launch-1.0 -v videotestsrc num-buffers=1 \
! video/x-raw,width=1280,height=720,format=I420 \
! identity name=raw1 silent=false \
! x265enc \
! avdec_h265 \
! identity name=raw2 silent=false \
! xvimagesink
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>
------------------------------
Subject: Digest Footer
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
------------------------------
End of gstreamer-devel Digest, Vol 93, Issue 17
***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181006/64d1d7ab/attachment-0001.html>
More information about the gstreamer-devel
mailing list