GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-02-10T07:59:19Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/845Missing referenced copy of the GPL-2.02021-02-10T07:59:19ZJamin CollinsMissing referenced copy of the GPL-2.0The **EffecTV** [LICENSE](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/gst/effectv/LICENSE#L7-9) file states:
```
* EffecTV is free software. We release this product under the terms of the
* GNU General Publ...The **EffecTV** [LICENSE](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/gst/effectv/LICENSE#L7-9) file states:
```
* EffecTV is free software. We release this product under the terms of the
* GNU General Public License version 2. The license is included in the file
* COPYING.
```
However, the top level [COPYING](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/COPYING) file for the project (and only `COPYING` file within the project) is a copy of the LPGL-2.1.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1526mpegtsmux: PAT/PMT/SI inserted after every PCR carrying packet after a time j...2021-09-24T14:39:08ZMart Raudseppmpegtsmux: PAT/PMT/SI inserted after every PCR carrying packet after a time jump, tripling MPEG-TS sizeFor 1.18 mpegtsmux was reworked for better conformance in !337 - in the process the calculation for when to insert a PAT/PMT packet was reworked in commit 9190541e3cee2 from a last_pat_ts recording approach to a next_pat_pcr approach.
B...For 1.18 mpegtsmux was reworked for better conformance in !337 - in the process the calculation for when to insert a PAT/PMT packet was reworked in commit 9190541e3cee2 from a last_pat_ts recording approach to a next_pat_pcr approach.
Before the last timestamp when PAT was emitted was recorded and then from there it would look whether it's time to insert the next one. Afterwards the timestamp for the next PAT emission is recorded instead, but the current timestamp doesn't influence it at all. After it's initially set, it's just now always incremented by the configured interval, even if the current timestamp jumped ahead for some reason. As a result, if the buffer timestamp suddenly jumps ahead for some reason, every 188 byte PCR PES packet will be preceded with PAT, PMT and SI (if any are configured) packets until it catches up from the constant interval increment - if the time jump was in hours, this catch-up effectively might never happen and thus the whole MPEG-TS stream after that point is at least triple the size (without SI) or more.
I think it's a straightforward fix to provide a MR for, but I'm not sure what the behaviour intention here would be:
* should the configured interval be a minimum - just set the `next_*_pcr` from `cur_ts + interval` instead of `next_*_pcr += interval`
* should the configured interval be a best effort, where if it's a little bit late once, the next interval should be just appropriately shorter - keeping the existing logic, but detecting bigger timestamp differences to reset it to cur_ts base instead to handle the jumps
* something else (like this just ought to not happen without DISCONT from upstreams?)
I got hit by this due to what !2011 tries to solve - amcvideoenc gave a timestamp of 0 in first buffer, and then the correct ones immediately after it, which were over 100 hours PTS values.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/85please add He Junyan as co-maintainer to gstreamer-vaapi2021-02-10T13:22:16ZVíctor Manuel Jáquez Lealplease add He Junyan as co-maintainer to gstreamer-vaapiWhile I'm focusing more on new va plugins in bad I think would be a good idea to share of the maintenance burden of gstreamer-vaapi with He Junyan, besides they are working on more Intel specific fixes and driver updates, so they don't d...While I'm focusing more on new va plugins in bad I think would be a good idea to share of the maintenance burden of gstreamer-vaapi with He Junyan, besides they are working on more Intel specific fixes and driver updates, so they don't diverge too much their internal repository with the official one. Nonetheless I'll still keep and eye on merge request and rubberstamp them.
What do you think?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1525Waylandsink- Video crop not working properly2021-02-06T13:55:34ZArunvistWaylandsink- Video crop not working properlyHi,
We are working with IMX8(NXP) platform.
Display screen size is 1280x480. Since video content is 1280x720 and the actual content is 1060x480 only. so we need to crop the content and then we need to render it(crop top 120 left 110 bot...Hi,
We are working with IMX8(NXP) platform.
Display screen size is 1280x480. Since video content is 1280x720 and the actual content is 1060x480 only. so we need to crop the content and then we need to render it(crop top 120 left 110 bottom 120 right 110).
We are trying to play video with the below pipeline, And we are getting green patch on top of the video.
gst-launch-1.0 filesrc location=dump.h264 ! h264parse ! v4l2h264dec ! videocrop top=120 left=110 right=0 bottom=0 ! imxvideoconvert_g2d ! multifilesink location=step_%02d.raw &
to fix that issue, we tried below pipeline. gst-launch-1.0 filesrc location=dump.h264 ! h264parse ! v4l2h264dec ! imxvideoconvert_g2d ! videocrop top=120 left=110 right=0 bottom=0 ! imxvideoconvert_g2d ! multifilesink location=step_%02d.raw &
Now Crop is not happening correctly. We see that in waylandsink source region from the video is not able to fetch it properly.[aap_dump.h264](/uploads/5c91ddb83d57002df31f172ec71a1328/aap_dump.h264)
We are using gstreamer version 1.14.4 Can you please help me on this?
Please find the attached image file for testing.
Thanks, Arunkumar Rhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1524Should kate be removed?2023-10-26T08:01:28ZFederico Mena QuinteroShould kate be removed?As far as I can tell, libtiger's source is not available anymore in googlecode.com nor git.xiph.org. Distros appear to be carrying an old tarball for years.
Should the kate plugin be removed? This would allow distros to remove libkate...As far as I can tell, libtiger's source is not available anymore in googlecode.com nor git.xiph.org. Distros appear to be carrying an old tarball for years.
Should the kate plugin be removed? This would allow distros to remove libkate / libtiger and lose some unmaintained code.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1523va: postproc: copy frames if downstream doesn't support video meta2021-02-20T17:02:54ZVíctor Manuel Jáquez Lealva: postproc: copy frames if downstream doesn't support video metaAs decoders, postproc might need to copy the source buffers if downstream doesn't support video metaAs decoders, postproc might need to copy the source buffers if downstream doesn't support video metahttps://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/89avviddec: Negotiation failure for alternate interlace stream if deinterlace e...2021-09-24T12:52:42ZSeungha Yangseungha@centricular.comavviddec: Negotiation failure for alternate interlace stream if deinterlace element is not configuredRegression since https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/115
Using hevc interlace stream available at https://trac.ffmpeg.org/ticket/5514, following pipeline doesn't work
`gst-launch-1.0.exe -v filesrc locat...Regression since https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/115
Using hevc interlace stream available at https://trac.ffmpeg.org/ticket/5514, following pipeline doesn't work
`gst-launch-1.0.exe -v filesrc location=src13_interlaced_cut.265 ! h265parse ! avdec_h265 ! d3d11videosink`
`glimagesink` and `d3dvideosink` are showing the same nego failure as well. In case that deinterlace is configured between dec and sink, it works nicely of course.
(I'm sorry, @vivia)https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/81android tutorial 5 SEGVs on an oculus quest2021-09-24T16:20:06ZBob Fandroid tutorial 5 SEGVs on an oculus questI installed android-tutorial-5 onto an Oculus Quest using a USB cable and `gradle installDebug`
I then started the application using
```
adb shell am start -n org.freedesktop.gstreamer.tutorials.tutorial_5/org.freedesktop.gstreamer.tut...I installed android-tutorial-5 onto an Oculus Quest using a USB cable and `gradle installDebug`
I then started the application using
```
adb shell am start -n org.freedesktop.gstreamer.tutorials.tutorial_5/org.freedesktop.gstreamer.tutorials.tutorial_5.Tutorial5 -a android.intent.action.MAIN -c android.intent.category.LAUNCHER
```
Using the default URL for sintel it appears to be reliable.
But if I change the `defaultMediaUri` in java to `http://www.purplefrog.com/~thoth/art/astroneer-gateway-engine.mp4` the results are unreliable. Sometimes it crashes immediately. Sometimes it crashes when I press the B button on the right-hand controller.
```
2021-02-05 11:02:22.156 31292-31379/org.freedesktop.gstreamer.tutorials.tutorial_5 W/GStreamer+qtdemux: 0:00:04.860665310 0x7f5973e720 ../gst/isomp4/qtdemux.c:9866:qtdemux_parse_segments:<qtdemux1> Segment 1 extends to 0:07:47.194000000 past the end of the declared movie duration 0:07:47.131000000 movie segment will be extended
2021-02-05 11:02:22.312 31292-31378/org.freedesktop.gstreamer.tutorials.tutorial_5 E/GLib+GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
2021-02-05 11:02:22.493 31292-31407/org.freedesktop.gstreamer.tutorials.tutorial_5 W/GStreamer+audio-resampler: 0:00:05.197958539 0x7f6f4dbd90 ../gst-libs/gst/audio/audio-resampler.c:274:convert_taps_gint16_c can't find exact taps
2021-02-05 11:02:22.750 31292-31314/org.freedesktop.gstreamer.tutorials.tutorial_5 W/GStreamer+tutorial-5: 0:00:05.454657706 0x7f5ada8700 /home/thoth/vendor/gst-docs/examples/tutorials/android/android-tutorial-5/jni/tutorial-5.c:162:refresh_ui Could not query current position (normal for still pictures)
2021-02-05 11:02:22.971 31292-31385/org.freedesktop.gstreamer.tutorials.tutorial_5 E/GStreamer+glbasetexture: 0:00:05.675947549 0x7f6f4dbf70 ../gst-libs/gst/gl/gstglmemory.c:890:_gl_tex_copy Cannot copy External OES textures
2021-02-05 11:02:37.876 31292-31304/org.freedesktop.gstreamer.tutorials.tutorial_5 E/Parcel: Reading a NULL string not supported here.
2021-02-05 11:02:37.880 31292-31304/org.freedesktop.gstreamer.tutorials.tutorial_5 E/Parcel: Reading a NULL string not supported here.
2021-02-05 11:02:37.885 31292-31304/org.freedesktop.gstreamer.tutorials.tutorial_5 E/Parcel: Reading a NULL string not supported here.
2021-02-05 11:02:37.904 31292-31390/org.freedesktop.gstreamer.tutorials.tutorial_5 E/GStreamer+amcaudiodec: 0:00:20.608289106 0x7f6f4ac4f0 ../sys/androidmedia/gstamcaudiodec.c:1208:gst_amc_audio_dec_handle_frame:<amcaudiodec-omxgoogleaacdecoder1> Downstream returned flushing
2021-02-05 11:02:37.987 31292-31378/org.freedesktop.gstreamer.tutorials.tutorial_5 E/GStreamer+amcvideodec: 0:00:20.691598325 0x7f6f4dd050 ../sys/androidmedia/gstamcvideodec.c:2242:gst_amc_video_dec_handle_frame:<amcvideodec-omxqcomvideodecoderavc1> Downstream returned flushing
2021-02-05 11:02:38.337 1069-6379/? W/WindowManager: Force-removing child win Window{f80790e u0 SurfaceView - org.freedesktop.gstreamer.tutorials.tutorial_5/org.freedesktop.gstreamer.tutorials.tutorial_5.Tutorial5 EXITING} from container Window{bc3cb6f u0 org.freedesktop.gstreamer.tutorials.tutorial_5/org.freedesktop.gstreamer.tutorials.tutorial_5.Tutorial5}
2021-02-05 11:02:38.350 31292-31292/org.freedesktop.gstreamer.tutorials.tutorial_5 A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x38 in tid 31292 (ials.tutorial_5)
2021-02-05 11:02:39.102 31426-31426/? A/DEBUG: pid: 31292, tid: 31292, name: ials.tutorial_5 >>> org.freedesktop.gstreamer.tutorials.tutorial_5 <<<
2021-02-05 11:02:39.105 31426-31426/? A/DEBUG: #00 pc 0000000000489c88 /data/app/org.freedesktop.gstreamer.tutorials.tutorial_5-1/lib/arm64/libgstreamer_android.so
2021-02-05 11:02:39.105 31426-31426/? A/DEBUG: #01 pc 00000000001f4b34 /data/app/org.freedesktop.gstreamer.tutorials.tutorial_5-1/oat/arm64/base.odex (offset 0x1d5000)
```
On a linux/amd64 box, `gst-launch-1.0 playbin uri=http://www.purplefrog.com/~thoth/art/astroneer-gateway-engine.mp4` is able to play the entire video
This may indicate there is a flaw in the gstreamer library on android.
about the oculus quest:
system version 12018300093600000
version 23.0.0.87.517.260511599
runtime version 23.0.0.87.517.260511615
os version user-1201830.9360.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/658Removing a blocking probe still blocks if there's any other blocking probe2021-02-10T12:33:09ZJan SchmidtRemoving a blocking probe still blocks if there's any other blocking probeIf you have a pad with 2 blocking probes - one for events and one for dataflow, and return GST_PAD_PROBE_REMOVE from the dataflow callback, the pad stays blocked, instead of proceeding to process more data until it gets to an event.
Thi...If you have a pad with 2 blocking probes - one for events and one for dataflow, and return GST_PAD_PROBE_REMOVE from the dataflow callback, the pad stays blocked, instead of proceeding to process more data until it gets to an event.
This is also a problem for calling gst_pad_remove_probe() - if it was the dataflow probe that was called and caused things to block, removing the probe won't unblock things. You have to remove both probes so that num_blocked drops to 0 and the block loop in do_probe_callbacks() can exit.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/142provide binary releases of plugins2021-02-05T10:05:49ZGuillaume Desmottesprovide binary releases of pluginsIt's been [pointed on this ticket](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/77#note_790517) that we currently don't provide any Mac OS X and Windows binary builds as we do for the official GStreamer releases.
It w...It's been [pointed on this ticket](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/77#note_790517) that we currently don't provide any Mac OS X and Windows binary builds as we do for the official GStreamer releases.
It would be interesting to consider doing so as well, to ease the use of those plugins for users and making the Rust plugins first class citizens.
Don't know it if would be best to release them separately or as part of the official gst releases?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/141cdgparse: improve seeking2021-02-05T10:04:48ZGuillaume Desmottescdgparse: improve seeking`cdgparse` is marking `CDG_CMD_MEMORY_PRESET` frames as key frames, so seeking using `GST_SEEK_FLAG_KEY_UNIT` jump to one of those, preventing visual artifacts.
We could improve the non key-unit seeking by jumping backward to the neare...`cdgparse` is marking `CDG_CMD_MEMORY_PRESET` frames as key frames, so seeking using `GST_SEEK_FLAG_KEY_UNIT` jump to one of those, preventing visual artifacts.
We could improve the non key-unit seeking by jumping backward to the nearest keyframe and redecode the frames between the kf and the seeking point. Decoding cdg is really fast so that shouldn't be an issue.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/657The textoverlay cannot display Chinese properly in Android2021-09-24T11:08:30ZHoman HuangThe textoverlay cannot display Chinese properly in AndroidChinese has no issue in state_changed_cb():
```
gchar *message = g_strdup_printf ("播放状态: %s",
gst_element_state_get_name (new_state));
```
Problem:
```
gst_parse_launch ("videotestsrc ! textoverlay text=\"测试\" "
...Chinese has no issue in state_changed_cb():
```
gchar *message = g_strdup_printf ("播放状态: %s",
gst_element_state_get_name (new_state));
```
Problem:
```
gst_parse_launch ("videotestsrc ! textoverlay text=\"测试\" "
"font-desc=\"Sans, 72\" ! videoconvert ! autovideosink", &error);
```
![textoverlay](/uploads/090d2b2d579eacb5c9484e2a71cb0246/textoverlay.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/844videoflip: caps criticals with vtdec2023-07-06T12:47:39ZAndy Robinsonvideoflip: caps criticals with vtdecThis is the binary distribution of GST 1.18.3 on an Intel Mac running Big Sur 11.2
It crashes every time with the following pipeline:
% gst-launch-1.0 filesrc location=door_rotn.mov ! decodebin ! videoconvert ! videoflip method=clockwi...This is the binary distribution of GST 1.18.3 on an Intel Mac running Big Sur 11.2
It crashes every time with the following pipeline:
% gst-launch-1.0 filesrc location=door_rotn.mov ! decodebin ! videoconvert ! videoflip method=clockwise ! autovideosink
<br>Setting pipeline to PAUSED ...
<br>Pipeline is PREROLLING ...
<br>Got context from element 'autovideosink0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayCocoa\)\ gldisplaycocoa0";
<br>Redistribute latency...
<br>Pipeline is PREROLLED ...0 %)
<br>Setting pipeline to PLAYING ...
<br>New clock: GstSystemClock
<br>(gst-launch-1.0:3286): GStreamer-CRITICAL **: 17:28:30.389: gst_caps_get_structure: assertion 'index < GST_CAPS_LEN (caps)' failed
<br>It is the videoflip causing the trouble. The "method" doesn't make any difference. The choice of video does make a difference : about half of the videos I've tried crash, the other half play ok. So I attach a small one which does crash this pipeline.
<br>![door_rotn](/uploads/de80f45e685c9b7d59b36a2f78ca00cf/door_rotn.mov)https://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/30webrtc-sendrecv: soup_uri_to_string_internal: assertion 'uri != NULL' failed2021-09-24T22:43:57ZGuillaume Desmotteswebrtc-sendrecv: soup_uri_to_string_internal: assertion 'uri != NULL' failedRunning `webrtc-sendrecv --peer-id $ID` with master is raising this critical:
`(webrtc-sendrecv:376830): libsoup-CRITICAL **: 16:40:45.215: soup_uri_to_string_internal: assertion 'uri != NULL' failed`
```
#0 0x00007f1427b107e3 in g_lo...Running `webrtc-sendrecv --peer-id $ID` with master is raising this critical:
`(webrtc-sendrecv:376830): libsoup-CRITICAL **: 16:40:45.215: soup_uri_to_string_internal: assertion 'uri != NULL' failed`
```
#0 0x00007f1427b107e3 in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007f1427b10a53 in g_log () at /lib64/libglib-2.0.so.0
#2 0x00007f1427a1aa9d in soup_uri_to_string_internal (uri=<optimized out>, just_path_and_query=<optimized out>, include_password=<optimized out>, force_port=<optimized out>) at ../libsoup/soup-uri.c:538
#3 0x00007f1427a0309a in io_run_until
(msg=msg@entry=0x7f13dc03d290, blocking=blocking@entry=0, read_state=read_state@entry=SOUP_MESSAGE_IO_STATE_DONE, write_state=write_state@entry=SOUP_MESSAGE_IO_STATE_DONE, cancellable=cancellable@entry=0x0, error=error@entry=0x7f1404dc6bc0) at ../libsoup/soup-message-io.c:1034
#4 0x00007f1427a03607 in io_run (msg=0x7f13dc03d290, blocking=blocking@entry=0) at ../libsoup/soup-message-io.c:1082
#5 0x00007f1427a0375b in io_run_ready (msg=<optimized out>, user_data=<optimized out>) at ../libsoup/soup-message-io.c:1062
#6 0x00007f1427b0896f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#7 0x00007f1427b5a758 in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0
#8 0x00007f1427b08033 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#9 0x00007f142576d0ff in thread_func () at /lib64/libgupnp-igd-1.0.so.4
#10 0x00007f1427b362b2 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#11 0x00007f142759b3f9 in start_thread () at /lib64/libpthread.so.0
#12 0x00007f14278c0903 in clone () at /lib64/libc.so.6
```
Here is the full output:
```
Connecting to server...
> GET HTTP/1.1
> Soup-Debug-Timestamp: 1612453244
> Soup-Debug: SoupSession 1 (0xae6100), SoupMessage 1 (0xe680c0), SoupSocket 1 (0x8cf5b0)
> Host: webrtc.nirbheek.in:8443
> Upgrade: websocket
> Connection: Upgrade
> Sec-WebSocket-Key: 74N3pRhnpp/aqVXHwwHVjw==
> Sec-WebSocket-Version: 13
> Accept-Encoding: gzip, deflate
< HTTP/1.1 101 Switching Protocols
< Soup-Debug-Timestamp: 1612453244
< Soup-Debug: SoupMessage 1 (0xe680c0)
< Upgrade: websocket
< Connection: Upgrade
< Sec-WebSocket-Accept: 3GcD3A1L0DQZq0JmKHrIFy2kpAk=
< Date: Thu, 04 Feb 2021 15:40:49 GMT
< Server: Python/3.7 websockets/8.1
Connected to signalling server
Registering id 7824 with server
Registered with server
Setting up signalling server call with 1005
Created data channel
Starting pipeline
Sending offer:
v=0
o=- 279134161540322850 0 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
a=group:BUNDLE video0 audio1 application2
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:jrXwzzD+cXBYahvUR6kLpNs95aSe5TWH
a=ice-pwd:vXz8ZefHCYG1aOI/V0F3oX+QhhcwLD3y
a=rtcp-mux
a=rtcp-rsize
a=sendrecv
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack pli
a=framerate:30
a=ssrc:777246736 msid:user2916577097@host-976a1767 webrtctransceiver0
a=ssrc:777246736 cname:user2916577097@host-976a1767
a=mid:video0
a=fingerprint:sha-256 EA:3A:BB:E2:43:F3:9C:96:7C:26:09:F8:A6:88:9B:A6:DE:0B:FD:76:1C:41:2C:EF:44:AC:7E:8D:E8:B3:FD:4B
m=audio 0 UDP/TLS/RTP/SAVPF 97
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:jrXwzzD+cXBYahvUR6kLpNs95aSe5TWH
a=ice-pwd:vXz8ZefHCYG1aOI/V0F3oX+QhhcwLD3y
a=bundle-only
a=rtcp-mux
a=rtcp-rsize
a=sendrecv
a=rtpmap:97 OPUS/48000/2
a=rtcp-fb:97 nack pli
a=fmtp:97 sprop-maxcapturerate=48000;sprop-stereo=0
a=ssrc:166728529 msid:user2916577097@host-976a1767 webrtctransceiver1
a=ssrc:166728529 cname:user2916577097@host-976a1767
a=mid:audio1
a=fingerprint:sha-256 EA:3A:BB:E2:43:F3:9C:96:7C:26:09:F8:A6:88:9B:A6:DE:0B:FD:76:1C:41:2C:EF:44:AC:7E:8D:E8:B3:FD:4B
m=application 0 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:jrXwzzD+cXBYahvUR6kLpNs95aSe5TWH
a=ice-pwd:vXz8ZefHCYG1aOI/V0F3oX+QhhcwLD3y
a=bundle-only
a=mid:application2
a=sctp-port:5000
a=fingerprint:sha-256 EA:3A:BB:E2:43:F3:9C:96:7C:26:09:F8:A6:88:9B:A6:DE:0B:FD:76:1C:41:2C:EF:44:AC:7E:8D:E8:B3:FD:4B
ICE gathering state changed to gathering
(webrtc-sendrecv:376830): libsoup-CRITICAL **: 16:40:45.215: soup_uri_to_string_internal: assertion 'uri != NULL' failed
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/843Video crop is not happening correctly when add imxvideoconvert_g2d2021-02-08T07:10:18ZArunvistVideo crop is not happening correctly when add imxvideoconvert_g2d
Hi,
We are working with IMX8(NXP) platform. We are trying to play video with the below pipeline, And we are getting green patch on top of the video.
gst-launch-1.0 filesrc location=/mnt/sda/SONY_32MX/dump.h264 ! h264parse ! v4l2h264dec...
Hi,
We are working with IMX8(NXP) platform. We are trying to play video with the below pipeline, And we are getting green patch on top of the video.
gst-launch-1.0 filesrc location=/mnt/sda/SONY_32MX/dump.h264 ! h264parse ! v4l2h264dec ! videocrop top=110 left=110 right=0 bottom=0 ! imxvideoconvert_g2d ! multifilesink location=step_%02d.raw &
to fix that issue, we tried below pipeline.
gst-launch-1.0 filesrc location=/mnt/sda/SONY_32MX/dump.h264 ! h264parse ! v4l2h264dec ! imxvideoconvert_g2d ! videocrop top=110 left=110 right=0 bottom=0 ! imxvideoconvert_g2d ! multifilesink location=step_%02d.raw &
Crop is not happening correctly.
We are using gstreamer version 1.14.4
Can you please help me on this?
Thanks,
Arunkumar Rhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/868videoconvert: NV12(bt601) to GRAY8 conversion results in image with limited r...2021-09-24T13:26:14ZMarianna Smidth Buschlevideoconvert: NV12(bt601) to GRAY8 conversion results in image with limited range [16:235] instead of full range [0:255]I believe there is an error in how `videoconvert` is handling the conversion of NV12(bt601) to GRAY8.
The resulting gray image has the limited range from YCrCb [16:235] instead of the expected full range [0:255].
It is missing a scalin...I believe there is an error in how `videoconvert` is handling the conversion of NV12(bt601) to GRAY8.
The resulting gray image has the limited range from YCrCb [16:235] instead of the expected full range [0:255].
It is missing a scaling step which should do the "contrast stretching".
Note that it handles NV12(bt709) to GRAY8 correctly, it produces an image where it is clear the histogram has been streched to cover the full range.
Example:
- This produces very similar videos (color and intensity wise):
```
GST_DEBUG="*:3" gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080,format=RGB,framerate=30/1" ! tee name=t ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt709" ! videoconvert ! ximagesink t. ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt601" ! videoconvert ! ximagesink
```
- This produces videos with difference in the grey intensities: the one from bt601 has limited range [16:235] instead of full range [0:255]
```
GST_DEBUG="*:3" gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080,format=RGB,framerate=30/1" ! tee name=t ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt709" ! videoconvert ! "video/x-raw,format=GRAY8" ! videoconvert ! ximagesink t. ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt601" ! videoconvert ! "video/x-raw,format=GRAY8" ! videoconvert ! ximagesink
```
- This again produces very similar videos
```
GST_DEBUG="*:3" gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080,format=RGB,framerate=30/1" ! tee name=t ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt709" ! videoconvert ! "video/x-raw,format=RGB" ! videoconvert ! "video/x-raw,format=GRAY8" ! videoconvert ! ximagesink t. ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt601" ! videoconvert ! "video/x-raw,format=RGB" ! videoconvert ! "video/x-raw,format=GRAY8" ! videoconvert ! ximagesink
```
Note that the same can be seen if fx saving the gray frames as PNM with `pnmenc` and `filesink` so it has nothing to do with `videoconvert ! ximagesink`.
When inspecting the gstreamer logs with: `GST_DEBUG="*:3,*video-color*:5,*video-converter*:5"` I can see the RGB->NV12 conversions for both cases, but the NV12->GRAY8 conversion is only done for the BT709, it gets bypassed when using BT601.
And I can see in the code that it seems to be because it detects the conversion has the same color matrix, so it thinks it is unnecessary, while BT709 uses a different color matrix so it requires conversion.
But the step that does the matrix conversion is the same as the one that does the scaling/offset correction from limited to full range.
So for me it seems like videoconvert is missing taking the range of the colorimetry into account.
```
0:00:00.037669400 74014 0x5558a695fe30 DEBUG video-converter video-converter.c:1747:chain_convert: matrix 4 -> 4 (1)
```
vs
```
0:00:00.031250922 74044 0x559cca812a30 DEBUG video-converter video-converter.c:1747:chain_convert: matrix 3 -> 4 (0)
0:00:00.031331090 74044 0x559cca812a30 DEBUG video-color video-color.c:247:gst_video_color_range_offsets: scale: 219 224 224 255
0:00:00.031353379 74044 0x559cca812a30 DEBUG video-color video-color.c:248:gst_video_color_range_offsets: offset: 16 128 128 0
0:00:00.031685485 74044 0x559cca812a30 DEBUG video-color video-color.c:247:gst_video_color_range_offsets: scale: 255 255 255 255
0:00:00.031707225 74044 0x559cca812a30 DEBUG video-color video-color.c:248:gst_video_color_range_offsets: offset: 0 128 128 0
```
It seems like it misses calling this: `gst_video_color_range_offsets()` https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-color.c#L204
* this tells that the primaries are the same: https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-converter.c#L1696
* Then because the matrix and bits are also the same we never enter here: https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-converter.c#L1769
* So we dont call this: `compute_matrix_to_RGB()` https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-converter.c#L1777
* Which is the one to call `gst_video_color_range_offsets()` https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-converter.c#L1341https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/80malfunction building android/gstreamer examples on Ubuntu 20.04.2 LTS2021-02-04T19:34:35ZBob Fmalfunction building android/gstreamer examples on Ubuntu 20.04.2 LTSI cloned the git repo (268c325b4e96a010fe05f5e427819b81d369c023) and tried to build in `examples/tutorials/android`
```
$ ./gradlew
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine java version from '11...I cloned the git repo (268c325b4e96a010fe05f5e427819b81d369c023) and tried to build in `examples/tutorials/android`
```
$ ./gradlew
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine java version from '11.0.9.1'.
```
I then installed gradle 6.6.1 on ubuntu and tried
```
$ ANDROID_HOME=~/Android/Sdk/ GSTREAMER_ROOT_ANDROID=~/vendor/gst-android/ gradle
Starting a Gradle Daemon (subsequent builds will be faster)
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':android-tutorial-1'.
> NDK not configured.
Download it with SDK manager.
```
So I added `ndkVersion "22.0.7026061"` to the `android-tutorial-1/build.gradle`
```
$ ANDROID_HOME=~/Android/Sdk/ GSTREAMER_ROOT_ANDROID=~/vendor/gst-android/ gradle
FAILURE: Build failed with an exception.
* Where:
Build file '/home/thoth/vendor/gst-docs/examples/tutorials/android/android-tutorial-1/build.gradle' line: 3
* What went wrong:
A problem occurred evaluating project ':android-tutorial-1'.
> No signature of method: build_6xaskmf8t8xwbod1wdc9e28k6.android() is applicable for argument types: (build_6xaskmf8t8xwbod1wdc9e28k6$_run_closure1) values: [build_6xaskmf8t8xwbod1wdc9e28k6$_run_closure1@7484dbdd]
```
I am unsure how to proceed from here.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/310datetime->ref_count == 0 when using VideoTimeCode2021-02-13T11:36:03ZSimonas Kazlauskasdatetime->ref_count == 0 when using VideoTimeCodeI attempted to attach VideoTimeCode meta to a buffer like in a buffer pad probe:
```
let datetime = glib::DateTime::new_now_utc();
let video_time_code = gst_video::VideoTimeCode::from_date_time(
gst::Fraction::new(30, 1),
&datet...I attempted to attach VideoTimeCode meta to a buffer like in a buffer pad probe:
```
let datetime = glib::DateTime::new_now_utc();
let video_time_code = gst_video::VideoTimeCode::from_date_time(
gst::Fraction::new(30, 1),
&datetime,
gst_video::VideoTimeCodeFlags::empty(),
0,
).expect("vtc");
gst_video::VideoTimeCodeMeta::add(
buffer.make_mut(),
&video_time_code.try_into().expect("video_time_code")
);
```
and found that it was outputting a ton of
```
GLib-CRITICAL **: 21:34:41.068: g_date_time_unref: assertion 'datetime->ref_count > 0' failed
GLib-CRITICAL **: 21:34:41.099: g_date_time_ref: assertion 'datetime->ref_count > 0' failed
```
suggesting something wrong with how references are counted in this code.
Sorry for not providing a self-contained reproducer here, let me know if you end up having a hard time reproducing and I'll see if I can whip one up.https://gitlab.freedesktop.org/gstreamer/gst-devtools/-/issues/57validateflow: Take into account buffer video (and audio?) flags when serializ...2023-05-03T17:14:05ZVivia Nikolaidouvalidateflow: Take into account buffer video (and audio?) flags when serializing buffer flagsThat would also mean we can't check for them in gst-validate, which in turn means all the tests would need to be updated.
See also https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites/-/merge_requests/93#note_788162That would also mean we can't check for them in gst-validate, which in turn means all the tests would need to be updated.
See also https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites/-/merge_requests/93#note_788162https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/867No string representations for video buffer flags2021-02-03T16:12:43ZVivia NikolaidouNo string representations for video buffer flagsThat would also mean we can't check for them in gst-validate, which in turn means all the tests would need to be updated.
See also https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites/-/merge_requests/93#note_788162That would also mean we can't check for them in gst-validate, which in turn means all the tests would need to be updated.
See also https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites/-/merge_requests/93#note_788162