|
|
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 < [hidden email]> wrote: @Nicolas Dufresne,
Yes, I already filed an issue.
Thanks.
Send gstreamer-devel mailing list submissions to
[hidden email]
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
[hidden email]
You can reach the person managing the list at
[hidden email]
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 <[hidden email]>
To: [hidden email]
Subject: HDR10 metadata using gst-launch-1.0
Message-ID: <[hidden email]>
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 <[hidden email]>
To: Discussion of the development of and with GStreamer
<[hidden email]>
Subject: Re: <v4l2src0:pool:src> Dropping truncated buffer, this is
likely a driver bug.
Message-ID:
<[hidden email]>
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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
------------------------------
Message: 3
Date: Thu, 25 Jun 2020 10:23:11 -0400
From: Nicolas Dufresne <[hidden email]>
To: Discussion of the development of and with GStreamer
<[hidden email]>
Subject: Re: Window turns transparent
Message-ID:
<[hidden email]>
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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
------------------------------
Message: 4
Date: Thu, 25 Jun 2020 10:25:05 -0400
From: Nicolas Dufresne <[hidden email]>
To: Discussion of the development of and with GStreamer
<[hidden email]>
Subject: Re: Watch youtube video using rtspsrc
Message-ID:
<[hidden email]>
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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
------------------------------
Message: 5
Date: Thu, 25 Jun 2020 11:10:10 -0400
From: Nicolas Dufresne <[hidden email]>
To: Discussion of the development of and with GStreamer
<[hidden email]>
Subject: Re: HDR10 metadata using gst-launch-1.0
Message-ID:
<[hidden email]>
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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
------------------------------
Message: 6
Date: Thu, 25 Jun 2020 11:07:50 -0500
From: Mikel P?rez <[hidden email]>
To: Discussion of the development of and with GStreamer
<[hidden email]>
Subject: Re: GStreamer 1.17.1 development release
Message-ID:
<[hidden email]>
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 <[hidden email]> 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
> [hidden email]
> 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 <[hidden email]>
To: gstreamer-devel <[hidden email]>
Subject: Identifying video key frame positions
Message-ID: <[hidden email]>
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
------------------------------
End of gstreamer-devel Digest, Vol 113, Issue 73
************************************************
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
|
Locked
