I think I may have hijacked the issue. My issue here was not the segfault, but I had the same GTask errors mentioned here.
The GTask errors had been addressed here: !5395 (merged)
And back-ported into 1.22 here: !5414 (merged)
So it has been resolved with 1.22.8 (or even an earlier minor version of 1.22).
I did some more experiments.
By default I believe for the audio output pulsesink
is being used.
I tried with --audiosink=alsasink
but ended up with a similar behavior.
But I also tried with --audiosink=openalsink
and it seems that the behavior is no longer observable. A little difficult to be sure because of the unpredictability nature of the issue, but I haven't experienced the issue in my real application since I switched from pulsesink
to openalsink
.
But now I wonder what may the reason for this.
pulsesink
and alsasink
doing something wrong?openalsink
increase some buffers that otherwise may result in the observed freeze?openalsink
's behavior so different that perhaps some race condition in other parts are no longer happening?Edit: I think I got the stall with openalsink
once too now. But it is way less frequent compared to other audio sinks. Which leans me towards the last option?
Output when it happens:
Redistribute latency...
Redistribute latency...
0:00:18.1 / 99:99:99.
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...aused
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
0:00:02.0 / 99:99:99.
Seems like the running time jumps back the fragment duration?
But sometimes it just stays the same:
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
0:01:42.4 / 99:99:99.
A uridecodebin3 HLS stream stalls occasionally after a state change from PAUSED to PLAYING.
Continued playback of stream after state change from PAUSE to PLAYING.
State change to PLAYING succeeds but streams stays paused. No audio or video being played. I have the feeling that the audio pipeline is not sending any more data starving the pipeline.
command
Using this script (requires streamlink
and jq
to get a URL which otherwise expires) to the HLS url
#!/bin/sh
JSON=$(streamlink --json --stream-url twitch.tv/gronkhtv best)
URL=$(echo $JSON | jq .master)
echo gst-play-1.0 --use-playbin3 "$URL"
Copy paste the command (I'm too bash illiterate to make it being called correctly directly in the script apparently..)
Start playing around with the space bar to PAUSE/PLAY the stream. Eventually the pipeline will starve and block.
Hard to tell. It may work perfectly fine a couple of dozen times. For me I usually do not need for than a dozen times to make it happen. It feels different streams from that platform have a different behavior. (twitch.tv/alf seemed fine for example)
Florian Zwoch (4a9a9ed9) at 27 Sep 17:11
Fair enough. I removed the comment as with this patch "Somehow" does not really apply anymore.
Found it at https://docs.gtk.org/gio/class.Task.html
I guess it is relatively new since it mentions GLib 2.76. Perhaps people kept ignoring it as it was not explicitly mentioned :-)
Gio/Task states the following:
If a GTask has been constructed and its callback set, it is an error to not call g_task_return_*() on it. GLib will warn at runtime if this happens (since 2.76).
Not quite sure why these were purposely left out for blocking requests? Running on GLib 2.78, Glib spit out a warning for each downloaded segment. Have not experienced any of them with this patch applied, also no other issues encountered so far.
Florian Zwoch (a9ddd92f) at 26 Sep 16:48
adaptivedemux2: Call GTasks's return functions for blocking tasks
Florian Zwoch (0e6cd642) at 26 Sep 11:52
rtspsrc: Property for adding custom http request headers
... and 3028 more commits
I see the same(?) GIO critical.
It seems to come from here:
#0 0x00007ffff732fc09 in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff732fe93 in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff74c98b3 in () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#3 0x00007ffff7e5fa8c in g_object_unref () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4 0x00007fffa5bea35c in downloadhelper_submit_request
(dh=dh@entry=0x7fffdc034330, referer=referer@entry=0x0, flags=flags@entry=(DOWNLOAD_FLAG_COMPRESS | DOWNLOAD_FLAG_FORCE_REFRESH | DOWNLOAD_FLAG_BLOCKING), request=request@entry=0x555555c7f730, err=err@entry=0x7fffef7fd440) at ../ext/adaptivedemux2/downloadhelper.c:947
#5 0x00007fffa5bea765 in downloadhelper_fetch_uri_range (err=0x7fffef7fd440,
err@entry=0xffffffffffffffff, range_end=-1, range_start=0, flags=(DOWNLOAD_FLAG_COMPRESS | DOWNLOAD_FLAG_FORCE_REFRESH | DOWNLOAD_FLAG_BLOCKING), flags@entry=(DOWNLOAD_FLAG_COMPRESS | DOWNLOAD_FLAG_FORCE_REFRESH), referer=referer@entry=0x0, uri=uri@entry=0x0, dh=0x7fffdc034330)
at ../ext/adaptivedemux2/downloadhelper.c:1005
#6 downloadhelper_fetch_uri
(dh=0x7fffdc034330, uri=uri@entry=0x7fffdc037b30 "https://video-weaver.fra05.hls.ttvnw.net/v1/playlist/Cs4E2c61LUi7kbK2HXDo7Ln9xMKFz43IgGUXzAhtkmCkOyDRnLkXgirgdNK82jfbfJQKStKbG-V4lSS-g-rx9d21wliit49FLuSTHuKKahCMZhdmoBqujypt9ujvs6LSWAEWjbR0UJw63FxacYL"..., referer=referer@entry=0x0, flags=flags@entry=(DOWNLOAD_FLAG_COMPRESS | DOWNLOAD_FLAG_FORCE_REFRESH), err=err@entry=0x7fffef7fd440)
at ../ext/adaptivedemux2/downloadhelper.c:1017
#7 0x00007fffa5c11b95 in download_media_playlist
(current=0x0, err=0x7fffef7fd440, uri=0x7fffdc037b30 "https://video-weaver.fra05.hls.ttvnw.net/v1/playlist/Cs4E2c61LUi7kbK2HXDo7Ln9xMKFz43IgGUXzAhtkmCkOyDRnLkXgirgdNK82jfbfJQKStKbG-V4lSS-g-rx9d21wliit49FLuSTHuKKahCMZhdmoBqujypt9ujvs6LSWAEWjbR0UJw63FxacYL"..., demux=0x7fffdc032410)
at ../ext/adaptivedemux2/hls/gsthlsdemux.c:1877
#8 gst_hls_demux_stream_update_media_playlist
(demux=demux@entry=0x7fffdc032410, stream=stream@entry=0x7fffdc03a8a0, uri=0x7fffdc003e28, err=err@entry=0x7fffef7fd440)
at ../ext/adaptivedemux2/hls/gsthlsdemux.c:2166
#9 0x00007fffa5c1608b in gst_hls_demux_stream_update_variant_playlist (err=0x7fffef7fd440, stream=0x7fffdc03a8a0, demux=0x7fffdc032410)
at ../ext/adaptivedemux2/hls/gsthlsdemux.c:2330
#10 gst_hls_demux_update_playlist (demux=demux@entry=0x7fffdc032410, update=update@entry=0, err=err@entry=0x7fffef7fd440)
at ../ext/adaptivedemux2/hls/gsthlsdemux.c:2651
#11 0x00007fffa5c17878 in gst_hls_demux_process_manifest (demux=<optimized out>, buf=<optimized out>)
at ../ext/adaptivedemux2/hls/gsthlsdemux.c:956
#12 0x00007fffa5bd388a in handle_incoming_manifest (demux=0x7fffdc032410) at ../ext/adaptivedemux2/gstadaptivedemux.c:980
#13 gst_adaptive_demux_sink_event (pad=0x7fffdc034d30, parent=0x7fffdc032410, event=0x7fffdc007170)
at ../ext/adaptivedemux2/gstadaptivedemux.c:1201
#14 0x00007ffff7202e0d in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#15 0x00007ffff720349c in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#16 0x00007ffff7203bd0 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#17 0x00007ffff7200fdc in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#18 0x00007ffff720cfe4 in gst_pad_push_event () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#19 0x00007ffff7202e0d in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
Closing.
This is a Mesa bug, when a user's locale represents floats with ,
instead of .
(e.g. German).
Fixed here: mesa/mesa!22699 (merged)
Not sure if it is an actual Mesa
issue, but I'm not sure how to confirm.
Using vapostproc
(vaapipostproc
too) as color convert from YUV to RGB formats seem to result in interlaced images.
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 22.3.5 for AMD Radeon RX 6600 (navi23, LLVM 15.0.7, DRM 3.49, 6.1.0-5-amd64)
Tested with (GStreamer 1.22.0):
gst-launch-1.0 videotestsrc pattern=spokes ! video/x-raw,format=NV12,width=960,height=540 ! vapostproc ! gtkwaylandsink
But also happens with:
gst-launch-1.0 videotestsrc pattern=spokes ! video/x-raw,format=NV12,width=960,height=540 ! vapostproc ! video/x-raw,format=RGBA ! videoconvert ! autovideosink
Switching vapostproc
with videoconvert
results in a much nicer image:
I found mesa/mesa#5760 in Mesa issues list, which sounds/looks alike, but it is surprisingly inactive.
I was quite lazy, so I only used the Mesa versions that are build within Debian. Main tests are now with the 3700X / RX 6600 combo. That uses mesa 22.3.6-1
(Debian unstable/testing, not experimental)
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=
Using LC_NUMERIC=C
is enough to get a decent result.
Hey, do you guys use the locale for some printf()s and doing calculations on these results?
Using LC_ALL=C
actually will give me a good result.
LC_ALL=C gst-launch-1.0 videotestsrc num-buffers=1 pattern=spokes ! video/x-raw,format=NV12,width=960,height=540 ! vaapipostproc ! video/x-raw,format=RGBA ! filesink location="out1.rgb"
Possibly some LC_NUMERIC or similar, which may be set to German on my end is the culprit. Some locales do like to use ,
instead of .
for floating point representation.
I have to correct myself. I updated the 5600G to latest packages and there the output is actually fine.
Yeah, that looks much nicer than mine. Questions is, what is it that i can make it look bad so consistently on different systems?!
disp_config.txt! Screenshot_from_2023-04-24_22-49-13
Here is the state.
And yes, I can see it on the 1080p monitor as well (see screenshot).
Here you go.