Window turns transparent (Nicolas Dufresne)
Busayo Famutimi
famutimi.busayo at gmail.com
Thu Jun 25 18:09:53 UTC 2020
@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
> ************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200625/c697c2c6/attachment-0001.htm>
More information about the gstreamer-devel
mailing list