GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:38:51Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1434AMC: fail to switch audio track when using AAC audio decoder2021-09-24T14:38:51ZXavier Claessensxclaesse@gmail.comAMC: fail to switch audio track when using AAC audio decoderI wrote a small Android app using GstPlayer. When playing an mp4 file with h264 video and 2 AAC audio tracks, it plays fine until I select the 2nd audio track. I see those errors:
```
10-21 10:42:58.072 4732 4807 E GStreamer+amcaudiod...I wrote a small Android app using GstPlayer. When playing an mp4 file with h264 video and 2 AAC audio tracks, it plays fine until I select the 2nd audio track. I see those errors:
```
10-21 10:42:58.072 4732 4807 E GStreamer+amcaudiodec: 0:00:13.585458281 0x7363f11f60 ../subprojects/gst-plugins-bad/sys/androidmedia/gstamcaudiodec.c:478:gst_amc_audio_dec_loop:<amcaudiodec-omxgoogleaacdecoder1> Failure dequeueing output buffer
10-21 10:42:58.072 4732 4807 W GStreamer+amcaudiodec: 0:00:13.585567239 0x7363f11f60 ../subprojects/gst-plugins-bad/sys/androidmedia/gstamcaudiodec.c:620:gst_amc_audio_dec_loop:<amcaudiodec-omxgoogleaacdecoder1> error: Failed to call Java method: java.lang.IllegalStateException
10-21 10:42:58.072 4732 4807 W GStreamer+amcaudiodec: java.lang.IllegalStateException
10-21 10:42:58.072 4732 4807 W GStreamer+amcaudiodec: at android.media.MediaCodec.native_dequeueOutputBuffer(Native Method)
10-21 10:42:58.072 4732 4807 W GStreamer+amcaudiodec: at android.media.MediaCodec.dequeueOutputBuffer(MediaCodec.java:3452)
10-21 10:42:58.072 4732 4807 W GStreamer+amcaudiodec:
```
If I rank google audio decoder SECONDARY then it picks libav decoder and it works.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1438decklink: Add support for HDR capture/output2021-09-24T14:38:52ZSebastian Drögedecklink: Add support for HDR capture/outputCan be done now with the latest SDK that we updated to.
There can be static metadata that we can signal via caps, or dynamic which can be signalled via the `GstVideoMasteringDisplayInfo` and `GstVideoContentLightLevel`.Can be done now with the latest SDK that we updated to.
There can be static metadata that we can signal via caps, or dynamic which can be signalled via the `GstVideoMasteringDisplayInfo` and `GstVideoContentLightLevel`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1440Capturing the screen on an extended dual/triple monitor2021-09-24T14:38:52ZDavide PeriniCapturing the screen on an extended dual/triple monitorHi all,
is it possible to capture the screen using gstreamer on a dual/triple extended monitor like if it is a single monitor?
I'm using this command:
> /gst-launch-1.0 dxgiscreencapsrc ! videoscale method=0 ! videoconvert ! autovideosi...Hi all,
is it possible to capture the screen using gstreamer on a dual/triple extended monitor like if it is a single monitor?
I'm using this command:
> /gst-launch-1.0 dxgiscreencapsrc ! videoscale method=0 ! videoconvert ! autovideosink sync=false
but it captures only one screen.
Any way to fix?
Thanks,
Davidehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1444msdk: should not share surface between different context2021-09-24T14:38:53ZRandy Limsdk: should not share surface between different contextin `gst_msdk_is_msdk_buffer()`, it would just check whether the memory inside a buffer is from msdk allocator, when it is true, it would extract the msdk surface from it.
But that is not correct for the element with a different context(...in `gst_msdk_is_msdk_buffer()`, it would just check whether the memory inside a buffer is from msdk allocator, when it is true, it would extract the msdk surface from it.
But that is not correct for the element with a different context(also vaapi doesn't work like this)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1446Follow-up from "codecs: h265: Fix dependent slice header"2021-09-24T14:38:53ZNicolas DufresneFollow-up from "codecs: h265: Fix dependent slice header"The following discussion from !1750 should be addressed:
- [ ] @seungha.yang started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1750#note_680137):
> maybe we want to do minimal validat...The following discussion from !1750 should be addressed:
- [ ] @seungha.yang started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1750#note_680137):
> maybe we want to do minimal validation check here? for example
> - clear `prev_independent_slice` per picture and check whether it's empty or not before `memcpy`
> - ensure dependent slice is not the first slice of this picturehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1456msdk: encode vp9 with psnr decline2021-09-24T14:38:55Zyefeng xumsdk: encode vp9 with psnr declinee.g.
cmd-line:
> gst-launch-1.0 -vf filesrc location=input num-buffers=300 ! rawvideoparse format=i420 width=352 height=288 framerate=30 ! videoconvert dither=0 ! video/x-raw,format=NV12 ! msdkvp9enc rate-control=cbr hardware=true gop-s...e.g.
cmd-line:
> gst-launch-1.0 -vf filesrc location=input num-buffers=300 ! rawvideoparse format=i420 width=352 height=288 framerate=30 ! videoconvert dither=0 ! video/x-raw,format=NV12 ! msdkvp9enc rate-control=cbr hardware=true gop-size=30 num-slices=1 bitrate=1000 ! video/x-vp9 ! matroskamux ! filesink location=output
result:
> DETAIL:psnr:expect=[27.0217,32.1303,31.5115,29.6865,34.2209,33.5887]
>
> DETAIL:psnr:expect=[27.0217,32.0074,31.3324,29.6865,33.8021,33.0498]https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1457adaptivedemux: Passes non-GObject GstAdaptiveDemuxStream to GST_DEBUG etc.2021-09-24T14:38:56ZSebastian Drögeadaptivedemux: Passes non-GObject GstAdaptiveDemuxStream to GST_DEBUG etc.Only GObjects are allowed there.Only GObjects are allowed there.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1464Test elements_camerabin fails on AArch642021-09-24T14:38:57ZMarius BakkeTest elements_camerabin fails on AArch64Hello,
When running `meson test` on aarch64-linux, the tests `check_file_validity` and `test_multiple_video_recordings` fails:
```
The output from the failed tests: ...Hello,
When running `meson test` on aarch64-linux, the tests `check_file_validity` and `test_multiple_video_recordings` fails:
```
The output from the failed tests:
6/61 elements_camerabin FAIL 56.94 s (exit status 1)
--- command ---
12:57:30 GST_REGISTRY='/tmp/guix-build-gst-plugins-bad-1.18.1.drv-0/build/tests/check/elements_camerabin.registry' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-ugly:gst-libav:libnice:gst-plugins-bad@/tmp/guix-build-gst-plugins-bad-1.18.1.drv-0/build' GST_STATE_IGNORE_ELEMENTS='' GST_PLUGIN_PATH_1_0='/tmp/guix-build-gst-plugins-bad-1.18.1.drv-0/build:/gnu/store/6w25bkmk5s9vgnk96hi821y5sr275c4d-gstreamer-1.18.1/lib/gstreamer-1.0:/gnu/store/lhvzfrr0filfn3y7lll2zw98hp58s9lm-gst-plugins-base-1.18.1/lib/gstreamer-1.0' GST_PLUGIN_SYSTEM_PATH_1_0='/gnu/store/lnky7vh6jf2a7gcvy6z6bisc2gwxj9ma-gst-plugins-good-1.18.1/lib/gstreamer-1.0' GST_PLUGIN_SCANNER_1_0='/gnu/store/6w25bkmk5s9vgnk96hi821y5sr275c4d-gstreamer-1.18.1/libexec/gstreamer-1.0/gst-plugin-scanner' CK_DEFAULT_TIMEOUT='60' /tmp/guix-build-gst-plugins-bad-1.18.1.drv-0/build/tests/check/elements_camerabin
--- stdout ---
Running suite(s): camerabin
Bail out! ERROR:../gst-plugins-bad-1.18.1/tests/check/elements/camerabin.c:865:check_file_validity: assertion failed: (pad != NULL)
94%: Checks: 17, Failures: 0, Errors: 1
../gst-plugins-bad-1.18.1/tests/check/elements/camerabin.c:990:E:wrappercamerabinsrc:test_multiple_video_recordings:0: (after this point) Received signal 6 (Aborted)
Check suite camerabin ran in 56.416s (tests failed: 1)
--- stderr ---
**
ERROR:../gst-plugins-bad-1.18.1/tests/check/elements/camerabin.c:865:check_file_validity: assertion failed: (pad != NULL)
-------
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1467waylandsink: release all the buffers when the surface is gone2021-09-24T14:38:57ZRandy Liwaylandsink: release all the buffers when the surface is goneI am not sure whether I analyze this issue right
In the previous commit, I fix the wayland frame callback accessing the freed object.
But actually there would be a buffer in that surface, unless surface call buffer.release() it should n...I am not sure whether I analyze this issue right
In the previous commit, I fix the wayland frame callback accessing the freed object.
But actually there would be a buffer in that surface, unless surface call buffer.release() it should not be released.
It is ok to handle that work to reference count, but for MSDK plugins, neither msdk session nor VA-API context would be referenced by the buffer, when this buffer would be released its associated VA-API context is gone.
I wonder if I change a GstBin state to STATE_NULL, it happens from the last sink or just the order which is added to that GstBin.
Then we can see this backstack
P.S. the new msdk plugin use the fd allocator wrongly, so change it back in my test
```
#0 0x00007fffe402f7a5 in vaReleaseBufferHandle (dpy=dpy@entry=0x555556bb6420, buf_id=21) at ../../git/va/va.c:1532
#1 0x00007fffe4073435 in gst_msdk_frame_free (resp=0x7fffa4e613c0, pthis=<optimized out>) at ../git/sys/msdk/gstmsdkallocator_libva.c:276
#2 gst_msdk_frame_free (pthis=<optimized out>, resp=0x7fffa4e613c0) at ../git/sys/msdk/gstmsdkallocator_libva.c:245
#3 0x00007fffe406b407 in gst_msdk_dmabuf_allocator_finalize (object=0x7fffa4e61250) at ../git/sys/msdk/gstmsdkvideomemory.c:535
#4 0x00007ffff740ee12 in g_object_unref (_object=<optimized out>) at ../glib-2.58.3/gobject/gobject.c:3346
#5 g_object_unref (_object=0x7fffa4e61250) at ../glib-2.58.3/gobject/gobject.c:3238
#6 0x00007ffff748ba9e in gst_object_unref (object=<optimized out>) at ../git/gst/gstobject.c:267
#7 0x00007ffff749de59 in gst_buffer_pool_finalize (object=0x7fff546409c0) at ../git/gst/gstbufferpool.c:200
#8 0x00007ffff740ee12 in g_object_unref (_object=<optimized out>) at ../glib-2.58.3/gobject/gobject.c:3346
#9 g_object_unref (_object=0x7fff546409c0) at ../glib-2.58.3/gobject/gobject.c:3238
#10 0x00007ffff748ba9e in gst_object_unref (object=<optimized out>) at ../git/gst/gstobject.c:267
#11 0x00007ffff749ee4a in gst_buffer_pool_release_buffer (pool=<optimized out>, buffer=<optimized out>) at ../git/gst/gstbufferpool.c:1382
#12 0x00007ffff7497a13 in _gst_buffer_dispose (buffer=0x7fff5c46dc60) at ../git/gst/gstbuffer.c:761
#13 0x00007ffff74ce837 in gst_mini_object_unref (mini_object=0x7fff5c46dc60) at ../git/gst/gstminiobject.c:656
#14 0x00007fffdc02efeb in gst_buffer_unref (buf=<optimized out>) at /usr/include/gstreamer-1.0/gst/gstbuffer.h:446
#15 gst_wl_buffer_force_release_and_unref (buf=<optimized out>, self=0x7fff4c323080) at ../git/ext/wayland/wlbuffer.c:206
#16 0x00007ffff7316b80 in g_hash_table_foreach (hash_table=0x7fff980055e0, func=0x7fffdc02ef80 <gst_wl_buffer_force_release_and_unref>, user_data=user_data@entry=0x0) at ../glib-2.58.3/glib/ghash.c:1687
#17 0x00007fffdc02f2b6 in gst_wl_display_finalize (gobject=0x7fff8c318490) at ../git/ext/wayland/wldisplay.c:77
#18 0x00007ffff740ee12 in g_object_unref (_object=<optimized out>) at ../glib-2.58.3/gobject/gobject.c:3346
#19 g_object_unref (_object=0x7fff8c318490) at ../glib-2.58.3/gobject/gobject.c:3238
#20 0x00007fffdc030039 in gst_wl_window_finalize (gobject=0x555555b94da0) at ../git/ext/wayland/wlwindow.c:187
#21 0x00007ffff740ee12 in g_object_unref (_object=<optimized out>) at ../glib-2.58.3/gobject/gobject.c:3346
#22 g_object_unref (_object=0x555555b94da0) at ../glib-2.58.3/gobject/gobject.c:3238
#23 0x00007fffdc02dabb in gst_wayland_sink_finalize (object=0x555555b33140) at ../git/ext/wayland/gstwaylandsink.c:339
#24 0x00007ffff740ee12 in g_object_unref (_object=<optimized out>) at ../glib-2.58.3/gobject/gobject.c:3346
#25 g_object_unref (_object=0x555555b33140) at ../glib-2.58.3/gobject/gobject.c:3238
#26 0x00007ffff748ba9e in gst_object_unref (object=<optimized out>) at ../git/gst/gstobject.c:267
#27 0x00007ffff7494b57 in gst_bin_remove_func (bin=0x555555a8cd20, element=<optimized out>) at ../git/gst/gstbin.c:1823
#28 0x00007ffff7493e43 in gst_bin_dispose (object=0x555555a8cd20) at ../git/gst/gstbin.c:524
#29 0x00007ffff740eda3 in g_object_unref (_object=<optimized out>) at ../glib-2.58.3/gobject/gobject.c:3309
#30 g_object_unref (_object=0x555555a8cd20) at ../glib-2.58.3/gobject/gobject.c:3238
#31 0x00007ffff748ba9e in gst_object_unref (object=<optimized out>) at ../git/gst/gstobject.c:267
#32 0x00007ffff74c8b1a in _gst_message_free (message=0x555559225990) at ../git/gst/gstmessage.c:213
#33 0x00007ffff7323e8d in g_list_foreach (list=<optimized out>, list@entry=0x7fffd41cc240, func=0x7ffff749f1f0 <gst_message_unref>, user_data=user_data@entry=0x0) at ../glib-2.58.3/glib/glist.c:1013
#34 0x00007ffff7323ebb in g_list_free_full (list=0x7fffd41cc240, free_func=<optimized out>) at ../glib-2.58.3/glib/glist.c:223
#35 0x00007ffff74a045f in gst_bus_set_flushing (bus=<optimized out>, flushing=<optimized out>) at ../git/gst/gstbus.c:504
#36 0x00007ffff74e059d in gst_pipeline_change_state (element=0x555555a6a610, transition=<optimized out>) at ../git/gst/gstpipeline.c:572
#37 0x00007ffff74b8362 in gst_element_change_state (element=element@entry=0x555555a6a610, transition=<optimized out>) at ../git/gst/gstelement.c:3046
#38 0x00007ffff74b8bde in gst_element_continue_state (element=element@entry=0x555555a6a610, ret=ret@entry=GST_STATE_CHANGE_SUCCESS) at ../git/gst/gstelement.c:2754
#39 0x00007ffff74b859d in gst_element_change_state (element=element@entry=0x555555a6a610, transition=<optimized out>) at ../git/gst/gstelement.c:3085
#40 0x00007ffff74b8bde in gst_element_continue_state (element=element@entry=0x555555a6a610, ret=ret@entry=GST_STATE_CHANGE_SUCCESS) at ../git/gst/gstelement.c:2754
#41 0x00007ffff74b859d in gst_element_change_state (element=element@entry=0x555555a6a610, transition=transition@entry=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at ../git/gst/gstelement.c:3085
#42 0x00007ffff74b88fe in gst_element_set_state_func (element=0x555555a6a610, state=GST_STATE_NULL) at ../git/gst/gstelement.c:3000
```
I asked jadahl something about this, it looks like we can fix this issue with drain query for the subsurface case but not for the case that this plugin created a top window surface, committing a null buffer would make the top window surface unmap and disconnecthttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1472decklinkvideosrc: incompatibility with mxfmux2021-09-24T14:38:58ZHugo Klokdecklinkvideosrc: incompatibility with mxfmuxHey there,
When using the decklinkvideosrc combined with the mxfmux, a SIGSEGV fault is always thrown after exactly 3:59 minutes.
I've tried it with an audio source which doesn't work:
`GST_DEBUG=*decklink*:5 gst-launch-1.0 decklinkvi...Hey there,
When using the decklinkvideosrc combined with the mxfmux, a SIGSEGV fault is always thrown after exactly 3:59 minutes.
I've tried it with an audio source which doesn't work:
`GST_DEBUG=*decklink*:5 gst-launch-1.0 decklinkvideosrc num-buffers=50000 mode=1080i50 ! videoconvert ! queue ! avenc_mpeg2video ! mxfmux name=m ! filesink location=~/decklink-and-audio.mxf filesrc location=~/Downloads/sample4.mp3 ! decodebin ! queue ! m.` ![used audio file here](/uploads/bc85c47352c6b57bb9939e1d5e208eb6/sample4.mp3)
And I've tried it with just the decklinkviedosrc which also doesn't work:
`GST_DEBUG=*decklink*:5 gst-launch-1.0 decklinkvideosrc num-buffers=50000 mode=1080i50 ! videoconvert ! queue ! avenc_mpeg2video ! mxfmux ! filesink location=~/only-decklink.mxf`
Lastly, I've also just tried recording with the decklinkvideosrc plugin without the mxfmux to see if its because of my decklink hardware, but that runs without any problems so that can't be it:
`GST_DEBUG=5 gst-launch-1.0 decklinkvideosrc num-buffers=50000 mode=1080i50 ! videoconvert ! queue ! avenc_mpeg2video ! filesink location=~/test.mxf
`
[Output (the segmentation fault is on line 1044)](/uploads/a97f5bd438296f86039f3781453d5384/output)
- Tried versions: 1.16 and 1.18
- OS: Ubuntu 20.04
- Build system: gst-build
Hope anyone has an idea why this incompatibility and/or memory leak happens.
Thanks in advance!
-Hugohttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1473hlsdemux/adaptivedemux - stops after changing bitrate2021-09-24T14:38:59ZMaximilian Senftlebenhlsdemux/adaptivedemux - stops after changing bitrateGStreamer 1.18.1
Pipeline:
`GST_DEBUG=3,adaptive*:5,hls*:5 gst-launch-1.0 souphttpsrc location=http://mcdn.daserste.de/daserste/de/master.m3u8 ! queue ! hlsdemux bitrate-limit=0.5 ! multiqueue ! decodebin name=d !
autovideosink d. ! a...GStreamer 1.18.1
Pipeline:
`GST_DEBUG=3,adaptive*:5,hls*:5 gst-launch-1.0 souphttpsrc location=http://mcdn.daserste.de/daserste/de/master.m3u8 ! queue ! hlsdemux bitrate-limit=0.5 ! multiqueue ! decodebin name=d !
autovideosink d. ! audioresample ! audioconvert ! autoaudiosink`
(tested with souphttpsrc is-live true/false)
Log (with some part inbetween truncated): https://pastebin.com/xjsqhDjx
Last logs:
> 0:01:03.820608364 1648 0xb4d6b800 INFO hlsdemux gsthlsdemux.c:1622:gst_hls_demux_change_playlist:<hlsdemux0> Client was on 4118400bps, max allowed is 1643926bps, switching to bitrate 1302400bps
[...]
0:01:04.110554624 1648 0xb4d6b800 DEBUG adaptivedemux gstadaptivedemux.c:2744:gst_adaptive_demux_stream_fragment_download_finish:<hlsdemux0:src_0> Download finish: -3 eos - err: (nil)
[...]
0:01:04.120604265 1648 0xb4308c88 DEBUG adaptivedemux gstadaptivedemux.c:3290:gst_adaptive_demux_stream_download_uri:<hlsdemux0:src_0> fragment download finished: http://mcdn.daserste.de/daserste/de/master_3744/01927/master_3744_00780.ts -3 eos
[...]
0:01:04.124876254 1648 0xb4308c88 DEBUG adaptivedemux gstadaptivedemux.c:3504:gst_adaptive_demux_stream_download_fragment:<hlsdemux0:src_0> Fragment download result: -3 (200) eos
0:01:04.125021587 1648 0xb4308c88 DEBUG adaptivedemux gstadaptivedemux.c:3840:gst_adaptive_demux_stream_download_loop:<hlsdemux0:src_0> EOS, checking to stop download loop
0:01:04.125113920 1648 0xb4308c88 DEBUG adaptivedemux gstadaptivedemux.c:4498:gst_adaptive_demux_has_next_period:<hlsdemux0> Has next period: 0
0:01:04.125567585 1648 0xb4308c88 DEBUG adaptivedemux gstadaptivedemux.c:2909:gst_adaptive_demux_stream_wait_manifest_update:<hlsdemux0> No fragment left but live playlist, wait a bit
[...]
0:01:04.203006054 1648 0xb4d6bf30 DEBUG hlsdemux gsthlsdemux-util.c:173:handle_pat: program 0001: pmt_pid : 01e0
0:01:04.203178054 1648 0xb4d6bf30 DEBUG hlsdemux gsthlsdemux-util.c:139:handle_pmt: pcr_pid now: 01e1
0:01:04.203267720 1648 0xb4d6bf30 DEBUG adaptivedemux gstadaptivedemux.c:2423:gst_adaptive_demux_stream_push_buffer:<'':src_1> Marking fragment as discontinuous
[...]
0:01:04.203629386 1648 0xb4d6bf30 DEBUG adaptivedemux gstadaptivedemux.c:1255:gst_adaptive_demux_expose_streams:<hlsdemux0:src_0> Pushing EOS
[...]
0:01:04.228764322 1648 0x6fd938 DEBUG adaptivedemux gstadaptivedemux.c:3504:gst_adaptive_demux_stream_download_fragment:<hlsdemux0:src_1> Fragment download result: -1 (200) not-linked
0:01:04.229040654 1648 0x6fd938 WARN adaptivedemux gstadaptivedemux.c:3886:gst_adaptive_demux_stream_download_loop:<hlsdemux0> error: Internal data stream error.
0:01:04.229133987 1648 0x6fd938 WARN adaptivedemux gstadaptivedemux.c:3886:gst_adaptive_demux_stream_download_loop:<hlsdemux0> error: streaming stopped, reason not-linked (-1)
[...]
0:01:04.298528144 1648 0xb4308c88 DEBUG adaptivedemux gstadaptivedemux.c:2953:gst_adaptive_demux_stream_wait_manifest_update:<hlsdemux0> Retrying now
[...]
0:01:04.369190630 1648 0x67fe40 DEBUG hlsdemux gsthlsdemux.c:1184:gst_hls_demux_reset:<hlsdemux0> resetting
0:01:04.370746959 1648 0x67fe40 DEBUG adaptivedemux gstadaptivedemux.c:533:gst_adaptive_demux_finalize:<hlsdemux0> finalizehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1483RFC: create a dmabufupload2021-09-24T14:39:00ZVíctor Manuel Jáquez LealRFC: create a dmabufuploadThis a request for comments for a possible dmabufupload
The spirit is similar to glupload but instead of uploading images into a gltexture based buffers, raw images would be uploaded to dmabuf based buffers.
The dmabuf buffers can be a...This a request for comments for a possible dmabufupload
The spirit is similar to glupload but instead of uploading images into a gltexture based buffers, raw images would be uploaded to dmabuf based buffers.
The dmabuf buffers can be allocated using libdrm or mesa's gbm.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1497hlssink/hlssink2: configurable playlist types, write EXT-X-PLAYLIST-TYPE to p...2021-09-24T14:39:03ZMatt Harkerhlssink/hlssink2: configurable playlist types, write EXT-X-PLAYLIST-TYPE to playlists`gstm3u8playlist.c` has support for playlist types `EVENT` and `VOD`, but it doesn't do anything with them.
It would be very advantageous to write that event type into the rendered playlist, plus also expose the playlist type as an opti...`gstm3u8playlist.c` has support for playlist types `EVENT` and `VOD`, but it doesn't do anything with them.
It would be very advantageous to write that event type into the rendered playlist, plus also expose the playlist type as an option.
The lack of this playlist type being written means that some browsers with built-in HLS support (read: iOS Safari) don't allow for seeking through the playlist as without the type explicitly being set to EVENT or VOD, they don't assume that the segments will never change.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1511hlssink2: Index playlist file is written after each TS segment, unnecessary d...2021-09-24T14:39:05ZDavid Inghlssink2: Index playlist file is written after each TS segment, unnecessary disk i/o## Description
The index playlist is completely re-written with each new `*.ts` file. This is an inefficient usage pattern for disk i/o, particularly with long streams (the index file can get rather large).
There are some scenarios whe...## Description
The index playlist is completely re-written with each new `*.ts` file. This is an inefficient usage pattern for disk i/o, particularly with long streams (the index file can get rather large).
There are some scenarios where the file only needs to be written once (presumably after the final `*.ts` file has been finished).
## Possible fix 1
When each `*.ts` file is written, the playlist only needs to get a couple lines appended (corresponding to the latest `*.ts` chunk).
## Possible fix 2
I propose a boolean property on the `hlssink2` element, maybe call it "write-intermittent-playlist", with a default value of true.
* If true, the current behavior is maintained.
* If false, the playlist is only written once (after the final `*.ts` chunk).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1512hlssink2: In 1.18.3, pipeline just hangs during basic remux operations. Thi...2021-09-24T14:39:05ZDavid Inghlssink2: In 1.18.3, pipeline just hangs during basic remux operations. This didn't happen under 1.16.1.I recently moved from gstreamer 1.16.1 to 1.18.3, at which time the `hlssink2` element stopped behaving. I have reproduced a couple of scenarios to demonstrate this.
* `launch-audio.sh` does a basic HLS remux of an `audio.m4a` file.
* ...I recently moved from gstreamer 1.16.1 to 1.18.3, at which time the `hlssink2` element stopped behaving. I have reproduced a couple of scenarios to demonstrate this.
* `launch-audio.sh` does a basic HLS remux of an `audio.m4a` file.
* `launch-video.sh` does a basic HLS remux of an `video.m4v` file.
[launch-audio.sh](/uploads/ebf1dcae24636fcb591870608ab2a74e/launch-audio.sh)
[audio.m4a](/uploads/bd6a5292f4db4950467af549010275f2/audio.m4a)
[launch-video.sh](/uploads/19e7274d7eca780626b0687c29472263/launch-video.sh)
[video.m4v](/uploads/e5ca169dc53b82feddb71dd37d3fd894/video.m4v)
The scripts (above) can be executed on Linux (obviously) and also Windows (via GitBash).
If you want a full-blown docker-based repro, I am proving that (image based on https://gitlab.freedesktop.org/gstreamer/gst-ci/-/tree/1.18/docker/fedora). Just unzip and then move the 4 files (shown above) into the `data_volume` sub-folder.
[docker_based_repro.zip](/uploads/8f3a40ca2151aa2636509557656f9dd9/docker_based_repro.zip)
## audio remux scenario (see launch-audio.sh)
This command hangs on Windows and Fedora 31.
```bash
gst-launch-1.0 --gst-debug-level=3 hlssink2 name=sink max-files=0 playlist-length=0 target-duration=9 hlssink2 location="$output_folder/%05d.ts" playlist-location="$output_folder/index.m3u8" \
filesrc location="$this_folder/audio.m4a" ! qtdemux name=a a.audio_0 ! queue ! aacparse ! queue ! sink.audio
```
Output:
```
Setting pipeline to PAUSED ...
0:00:00.189621000 1712 000001D001BF9F90 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
0:00:00.194193000 1712 000001D001BF8180 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type sgpd
0:00:00.194344000 1712 000001D001BF8180 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type sbgp
0:00:00.196327000 1712 000001D001BF8180 WARN qtdemux qtdemux.c:3067:qtdemux_parse_trex:<a> failed to find fragment defaults for stream 1
0:00:00.199445000 1712 000001D001BF8280 WARN splitmuxsink gstsplitmuxsink.c:2756:handle_mq_input:<splitmuxsink0> Could not request a keyframe. Files may not split at the exact location they should
0:00:00.208262000 1712 000001D001BF80C0 FIXME basesink gstbasesink.c:3386:gst_base_sink_default_event:<giostreamsink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:00.208356000 1712 000001D001BF80C0 WARN gio_base_sink gstgiobasesink.c:219:gst_gio_base_sink_event:<giostreamsink0> ignored SEGMENT event in time format
```
## video remux scenario (see launch-video.sh)
This command hangs on Windows and Fedora 31.
```bash
gst-launch-1.0 --gst-debug-level=3 hlssink2 name=sink max-files=0 playlist-length=0 target-duration=9 hlssink2 location="$output_folder/%05d.ts" playlist-location="$output_folder/index.m3u8" \
filesrc location="$this_folder/video.m4v" ! qtdemux name=a a.video_0 ! queue ! h264parse ! queue ! sink.video
```
Output:
```
Setting pipeline to PAUSED ...
0:00:00.231561000 18596 00000212DE2CB000 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
0:00:00.232425000 18596 00000212DE2C8180 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type uuid
0:00:00.232579000 18596 00000212DE2C8180 WARN qtdemux qtdemux.c:3067:qtdemux_parse_trex:<a> failed to find fragment defaults for stream 1
0:00:00.233529000 18596 00000212DE2C8280 WARN splitmuxsink gstsplitmuxsink.c:2756:handle_mq_input:<splitmuxsink0> Could not request a keyframe. Files may not split at the exact location they should
0:00:00.241579000 18596 00000212DE2BDF80 FIXME basesink gstbasesink.c:3386:gst_base_sink_default_event:<giostreamsink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:00.241764000 18596 00000212DE2BDF80 WARN gio_base_sink gstgiobasesink.c:219:gst_gio_base_sink_event:<giostreamsink0> ignored SEGMENT event in time format
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1515transcoder: ignore unsupport encode profile when list target.2021-09-24T14:39:06ZKevin Songtranscoder: ignore unsupport encode profile when list target.Below command line will ignore mp4.gep profile if video encoder can't support "preset=Profile YouTube". We should fall back to use normal video encoder.
gst-transcoder-1.0 -lBelow command line will ignore mp4.gep profile if video encoder can't support "preset=Profile YouTube". We should fall back to use normal video encoder.
gst-transcoder-1.0 -lhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1516msdk: Got NULL mfx surface in "intervideosink + intervideosrc" pipeline with ...2021-09-24T14:39:06ZAustin-Humsdk: Got NULL mfx surface in "intervideosink + intervideosrc" pipeline with msdkvpp elementWhen running the GStreamer command line:
```
gst-launch-1.0 -v videotestsrc ! msdkvpp ! video/x-raw, width=1280, height=800, format=BGRA ! \
intervideosink channel=frontvideosink sync=true async=false render-delay=5000000 max-lateness=50...When running the GStreamer command line:
```
gst-launch-1.0 -v videotestsrc ! msdkvpp ! video/x-raw, width=1280, height=800, format=BGRA ! \
intervideosink channel=frontvideosink sync=true async=false render-delay=5000000 max-lateness=5000000 \
intervideosrc channel=frontvideosink ! msdkvpp ! video/x-raw, width=640, height=480, format=NV12 ! \
msdkh264enc name=main_enc bitrate=1500 rate-control=2 ! video/x-h264, stream-format=byte-stream ! \
queue ! h264parse ! msdkh264dec ! vaapisink sync=false
```
I got the error:
```
0:00:00.092319589 5840 0x559b3f5369e0 ERROR msdkvpp gstmsdkvpp.c:861:gst_msdkvpp_transform:<msdkvpp1> mfx surface is NULL for the current input buffer
```
But I can see video playback without any error, by replacing `msdkvpp` with `mfxvpp`:
```
gst-launch-1.0 -v videotestsrc ! mfxvpp ! video/x-raw, width=1280, height=800, format=BGRA ! \
intervideosink channel=frontvideosink sync=true async=false render-delay=5000000 max-lateness=5000000 \
intervideosrc channel=frontvideosink ! mfxvpp ! video/x-raw, width=640, height=480, format=NV12 ! \
msdkh264enc name=main_enc bitrate=1500 rate-control=2 ! video/x-h264, stream-format=byte-stream ! \
queue ! h264parse ! msdkh264dec ! vaapisink sync=false
```
or by replacing the 1st `msdkvpp` before `intervideosink`, with `vaapipostproc`:
```
gst-launch-1.0 -v videotestsrc ! vaapipostproc ! video/x-raw, width=1280, height=800, format=BGRA ! \
intervideosink channel=frontvideosink sync=true async=false render-delay=5000000 max-lateness=5000000 \
intervideosrc channel=frontvideosink ! msdkvpp ! video/x-raw, width=640, height=480, format=NV12 ! \
msdkh264enc name=main_enc bitrate=1500 rate-control=2 ! video/x-h264, stream-format=byte-stream ! \
queue ! h264parse ! msdkh264dec ! vaapisink sync=false
```
Issue reproducing configuration:
- **Platform**: Intel Tiger Lake (11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz)
- **Software Configuration**:
- Ubuntu 18.04
- Linux kernel 5.8.1-050801-generic
- Latest master branch of "libva, gmmlib, media-driver (iHD), gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, MediaSDK, gst-plugins-bad, gstreamer-media-SDK, gstreamer-vaapi"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/gst-plugins-bad/-/issues/1530va: investigate a way to dismiss unused memories after reverse playback2021-09-24T14:39:08ZVíctor Manuel Jáquez Lealva: investigate a way to dismiss unused memories after reverse playbackWhile reverse playback the number of buffer has to increase since the whole GOP has to be allocated before rendering. This might bring a lot of memory pressure, mainly in hardware accelerated decoding.
For example, in order to make more...While reverse playback the number of buffer has to increase since the whole GOP has to be allocated before rendering. This might bring a lot of memory pressure, mainly in hardware accelerated decoding.
For example, in order to make more efficient the dmabuf-based memory allocation, va has an allocator's pool that stores all the created and released memories. But, after reverse playback (returning to normal playback) a lot of memories aren't required any more. It should be nice to find a mechanism to invalidate that memory cache.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1533rsvgoverlay: very slow with complex SVGs2021-09-24T14:39:08ZNazar Mokrynskyirsvgoverlay: very slow with complex SVGsI was experimenting with https://goldvoice.club/@privateer/svg-test/ and found that it is very slow an gst-launch uses more than 2 cores to render 1000x1000 output with this pipeline:
```
GST_DEBUG=3 gst-launch-1.0 \
curlhttpsrc loca...I was experimenting with https://goldvoice.club/@privateer/svg-test/ and found that it is very slow an gst-launch uses more than 2 cores to render 1000x1000 output with this pipeline:
```
GST_DEBUG=3 gst-launch-1.0 \
curlhttpsrc location=https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/gallardo.svg ! image/svg ! \
rsvgoverlay fit-to-frame=true name=o ! videoconvert ! video/x-raw,width=1000,height=1000 ! \
queue ! autovideosink \
videotestsrc is-live=true ! videoconvert ! o.
```
I think it just renders SVG on each frame instead of caching it somewhere and reusing for subsequent frames