Window turns transparent (Nicolas Dufresne)
David Ing
ding at panopto.com
Thu Jun 25 18:25:04 UTC 2020
Busayo,
I recommend using the MSVC build: I have observed that it tends to behave
nicely on Windows, and historically there have been problems with the
behavior of MINGW components on Windows (I have personally observed these
problems). I have heard a rumor that the MINGW is gradually improving but
I haven't used it since 1.16, at which time it still had some problems.
On Thu, Jun 25, 2020 at 11:10 AM Busayo Famutimi <famutimi.busayo at gmail.com>
wrote:
> @Nicolas Dufresne,
>
> Yes, I already filed an issue.
>
> Thanks.
>
> On Thu, Jun 25, 2020 at 5:26 PM <
> 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. HDR10 metadata using gst-launch-1.0 (ltreherne)
>> 2. Re: <v4l2src0:pool:src> Dropping truncated buffer, this is
>> likely a driver bug. (Nicolas Dufresne)
>> 3. Re: Window turns transparent (Nicolas Dufresne)
>> 4. Re: Watch youtube video using rtspsrc (Nicolas Dufresne)
>> 5. Re: HDR10 metadata using gst-launch-1.0 (Nicolas Dufresne)
>> 6. Re: GStreamer 1.17.1 development release (Mikel P?rez)
>> 7. Identifying video key frame positions (Andy Robinson)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 25 Jun 2020 08:30:37 -0500 (CDT)
>> From: ltreherne <l_treherne at yahoo.com>
>> To: gstreamer-devel at lists.freedesktop.org
>> Subject: HDR10 metadata using gst-launch-1.0
>> Message-ID: <1593091837092-0.post at n4.nabble.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> Hi,
>>
>> Is there a way to ingest HDR10 metadata (st2086) onto a H265/HEVC stream
>> using gst-launch-1.0
>>
>> Thanks.
>>
>>
>>
>> --
>> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 25 Jun 2020 10:18:13 -0400
>> From: Nicolas Dufresne <nicolas at ndufresne.ca>
>> To: Discussion of the development of and with GStreamer
>> <gstreamer-devel at lists.freedesktop.org>
>> Subject: Re: <v4l2src0:pool:src> Dropping truncated buffer, this is
>> likely a driver bug.
>> Message-ID:
>> <6af6c9470629e733aba7a4a05c89b039a8c489ca.camel at ndufresne.ca>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Le mercredi 24 juin 2020 ? 22:47 -0500, Aniket0987 a ?crit :
>> > Trying to capture I420 FHD at 5fps on RP4.
>> > Pipeline is as follows,
>> >
>> > v4l2src device=/dev/video0 io-mode=dmabuf !
>> > video/x-raw,width=1920,height=1080 ! videoconvert !
>> video/x-raw,format=RGBA
>> > ! videorate ! video/x-raw,framerate=5/1 ! queue leaky=downstream !
>> > v4l2h264enc capture-io-mode=dmabuf ! video/x-h264,profile=main !
>> h264parse
>> > splitmuxsink name=mp4mux max-size-time=60000000000
>> max-size-bytes=134217728
>> > location=/tmp/vid_ sync=false ! queue ! mp4mux.video
>> >
>> > After a certain time, v4l2src starts dropping everything.
>> >
>> > 0:10:33.385742774 42 0xa3bfb0 INFO v4l2src
>> > gstv4l2src.c:961:gst_v4l2src_create:<v4l2src0> sync to
>> 0:10:30.400000000 out
>> > ts 0:10:30.557956381
>> > 0:10:33.585610267 42 0xa3bfb0 DEBUG v4l2src
>> > gstv4l2src.c:925:gst_v4l2src_create:<v4l2src0> ts: 1:05:16.523210000 now
>> > 1:05:16.695278946 delay 0:00:00.172068946
>> > 0:10:33.585754746 42 0xa3bfb0 INFO v4l2src
>> > gstv4l2src.c:961:gst_v4l2src_create:<v4l2src0> sync to
>> 0:10:30.600000000 out
>> > ts 0:10:30.757941863
>> > 0:10:33.689999870 42 0xa3bfb0 WARN v4l2bufferpool
>> >
>> gstv4l2bufferpool.c:2066:gst_v4l2_buffer_pool_process:<v4l2src0:pool:src>
>> > Dropping truncated buffer, this is likely a driver bug.
>> > 0:10:33.690498344 42 0xa3bfb0 WARN v4l2bufferpool
>> >
>> gstv4l2bufferpool.c:2066:gst_v4l2_buffer_pool_process:<v4l2src0:pool:src>
>> > Dropping truncated buffer, this is likely a driver bug.
>> > 0:10:33.693825940 42 0xa3bfb0 WARN v4l2bufferpool
>> >
>> gstv4l2bufferpool.c:2066:gst_v4l2_buffer_pool_process:<v4l2src0:pool:src>
>> > Dropping truncated buffer, this is likely a driver bug.
>> > 0:10:33.694079417 42 0xa3bfb0 WARN v4l2bufferpool
>> >
>> gstv4l2bufferpool.c:2066:gst_v4l2_buffer_pool_process:<v4l2src0:pool:src>
>> > Dropping truncated buffer, this is likely a driver bug.
>> > 0:10:33.697968615 42 0xa3bfb0 WARN v4l2bufferpool
>> >
>> gstv4l2bufferpool.c:2066:gst_v4l2_buffer_pool_process:<v4l2src0:pool:src>
>> > Dropping truncated buffer, this is likely a driver bug.
>> > 0:10:33.698261555 42 0xa3bfb0 WARN v4l2bufferpool
>> >
>> gstv4l2bufferpool.c:2066:gst_v4l2_buffer_pool_process:<v4l2src0:pool:src>
>> > Dropping truncated buffer, this is likely a driver bug.
>> >
>> > Is there any issue in my pipeline or is it a v4l2 driver bug?
>>
>> The warning from gst is correct, it's a driver bug. But as you can see,
>> it has a workaround. The driver I made this workaround for is now fixed
>> in mainline kernel.
>>
>> >
>> >
>> >
>> > --
>> > Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 25 Jun 2020 10:23:11 -0400
>> From: Nicolas Dufresne <nicolas at ndufresne.ca>
>> To: Discussion of the development of and with GStreamer
>> <gstreamer-devel at lists.freedesktop.org>
>> Subject: Re: Window turns transparent
>> Message-ID:
>> <78724cefd73f7e6f0f8623250c4555ed5d512440.camel at ndufresne.ca>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Le jeudi 25 juin 2020 ? 08:21 +0100, Busayo Famutimi a ?crit :
>> > Hi,
>> >
>> > I ran the basic tutorial 5 but the output window was transparent.
>> Kindly see screenshot below:
>> >
>> >
>> >
>> > OS: Windows 10 using Msys2 & Mingw-64
>> >
>> > How can I fix this?
>>
>> Looks like a bug in the sink element, but I think you already filed an
>> issue didn't you ?
>>
>> >
>> > Thanks.
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 25 Jun 2020 10:25:05 -0400
>> From: Nicolas Dufresne <nicolas at ndufresne.ca>
>> To: Discussion of the development of and with GStreamer
>> <gstreamer-devel at lists.freedesktop.org>
>> Subject: Re: Watch youtube video using rtspsrc
>> Message-ID:
>> <30b792374e73719796b7f28d06b7e645e0a810bc.camel at ndufresne.ca>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Le jeudi 25 juin 2020 ? 03:28 -0500, nishitha a ?crit :
>> > Hi,
>> >
>> > I want to view youtube videos using gstreamer pipeline. It worked with
>> > souphttpsrc using the pipeline :
>> >
>> > gst-launch-1.0 souphttpsrc is-live=true location="$(youtube-dl --format
>> > "best[ext=mp4][protocol=https]" --get-url <youtube-link>)" ! decodebin !
>> > videoconvert ! autovideosink
>> >
>> > Now, how can I make it work with rtspsrc ?
>>
>> First step would be to make a feature request to Youtube/Google, and
>> hope they accept. Google/Youtube do no support RTSP protocol, they also
>> do not approve usage of youtube-dl extracted links.
>>
>> >
>> >
>> >
>> > --
>> > Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 25 Jun 2020 11:10:10 -0400
>> From: Nicolas Dufresne <nicolas at ndufresne.ca>
>> To: Discussion of the development of and with GStreamer
>> <gstreamer-devel at lists.freedesktop.org>
>> Subject: Re: HDR10 metadata using gst-launch-1.0
>> Message-ID:
>> <66ec2386a7892cd551a06f71432791544c50e99d.camel at ndufresne.ca>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Le jeudi 25 juin 2020 ? 08:30 -0500, ltreherne a ?crit :
>> > Hi,
>> >
>> > Is there a way to ingest HDR10 metadata (st2086) onto a H265/HEVC stream
>> > using gst-launch-1.0
>>
>> HDR10 static metadata will be exposed inside the caps, so one can
>> inject such meta for testing using capssetter element. This feature is
>> not released yet.
>>
>> >
>> > Thanks.
>> >
>> >
>> >
>> > --
>> > Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Thu, 25 Jun 2020 11:07:50 -0500
>> From: Mikel P?rez <io at mikelpr.com>
>> To: Discussion of the development of and with GStreamer
>> <gstreamer-devel at lists.freedesktop.org>
>> Subject: Re: GStreamer 1.17.1 development release
>> Message-ID:
>> <
>> CAHSRX9_6A9m72OCaWYi2MEf8EHDLhZ2K0nHyfKHAeK-cVfpe5w at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> the android build seems to be broken
>>
>> 1. does not link libiconv by default as did previous releases - had to
>> add GSTREAMER_EXTRA_LIBS := -liconv
>> 2. can't build with dashdemux plugin enabled as it is missing a link too.
>> I
>> just disabled in this case
>> 3. having built after working around #1 and #2, it fails with
>> ../sys/androidmedia/gst-android-hardware-camera.c:1763:_init_classes
>> Failed
>> to initialize android.hardware.Camera classes: Failed to get static field
>> ID EFFECT_EMBOSS (Ljava/lang/String;): java.lang.NoSuchFieldError: no
>> "Ljava/lang/String;" field "EFFECT_EMBOSS" in class
>> "Landroid/hardware/Camera$Parameters;" or its superclasses
>> java.lang.NoSuchFieldError: no "Ljava/lang/String;" field
>> "EFFECT_EMBOSS" in class "Landroid/hardware/Camera$Parameters;" or its
>> superclasses
>>
>> I don't know how to sidestep #3. I don't need the camera in my app but it
>> is part of native_init()
>>
>> On Mon, Jun 22, 2020 at 8:20 AM Tim-Philipp M?ller <t.i.m at zen.co.uk>
>> wrote:
>>
>> >
>> > > Binary packages for Android, iOS, Mac OS X and Windows will be
>> > > provided in the next few days.
>> >
>> > Binaries are up now at the usual location:
>> >
>> > https://gstreamer.freedesktop.org/pkg/
>> >
>> > Please give them a spin and let us know if anything is amiss.
>> >
>> > Cheers
>> > Tim
>> >
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200625/a34f9599/attachment-0001.htm
>> >
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Thu, 25 Jun 2020 17:18:47 +0100
>> From: Andy Robinson <andy at seventhstring.com>
>> To: gstreamer-devel <gstreamer-devel at lists.freedesktop.org>
>> Subject: Identifying video key frame positions
>> Message-ID: <c82edcf0-c99a-98e8-fdca-9aa4c2ec6c2b at seventhstring.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> I would like to locate key frames to enable faster seeking when a video
>> has widely spaced key frames. For example if the place we want to seek
>> to is just before a key frame then the seek will be very slow (I've seen
>> up to 3 seconds), but if we know where the key frames are, then it might
>> well be acceptable to seek instead to the key frame just after the
>> desired point.
>>
>> I have written a "pre-scan" technique which locates all key frames in
>> advance. It works by seeking to the next key frame (flags
>> GST_SEEK_FLAG_KEY_UNIT | GST_SEEK_FLAG_SNAP_AFTER), get the location,
>> add a little, then seek from there to the next key frame, etc. But this
>> can take 10 or 20 seconds on large videos. So my first question is, is
>> there a faster way of doing such a pre-scan?
>>
>> Failing that, I'm thinking of collecting key frame positions
>> incrementally while we play, using a pad probe. I tried placing a pad
>> probe after decodebin but I find *none* of the buffers have
>> GST_BUFFER_FLAG_DELTA_UNIT, so they all appear to be key frames, which
>> is wrong of course. According to this very old post:
>>
>>
>> http://gstreamer-devel.966125.n4.nabble.com/keyframes-from-a-video-td973102.html
>>
>> "- decodebin outputs decoded raw video frames; I don't think the
>> semantics of keyframe/not-keyframe are very well defined for raw video
>> frames. I would not rely on decoders flagging their output buffers
>> consistently one way or another or at all
>> - you are likely to get better results if you check for keyframes on
>> buffers before they go into the decoder"
>>
>> But how can I do that? Do I need to investigate the internals of how
>> decodebin works? Any advice would be welcome.
>>
>> Regards,
>> Andy Robinson, Seventh String Software, www.seventhstring.com
>>
>>
>> ------------------------------
>>
>> 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 113, Issue 73
>> ************************************************
>>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200625/384f86da/attachment-0001.htm>
More information about the gstreamer-devel
mailing list