stuttering
James
jam at tigger.ws
Sat Feb 19 06:39:45 UTC 2022
> On 4 Feb 2022, at 11:52 pm, James Linder via gstreamer-devel <gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>> wrote:
>
>>
>> On 30 Jan 2022, at 9:50 pm, Nicolas Dufresne <nicolas at ndufresne.ca <mailto:nicolas at ndufresne.ca>> wrote:
>>
>> Le samedi 29 janvier 2022 à 14:45 +0800, James via gstreamer-devel a écrit :
>>>
>>>
>>>> On 23 Jan 2022, at 3:11 pm, James via gstreamer-devel
>>>> <gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>> wrote:
>>>>
>>>> On 22 Jan 2022, at 9:38 pm, Kaj-Michael Lang via gstreamer-devel
>>>> <gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Sat, 2022-01-22 at 12:41 +0800, James Linder via gstreamer-devel
>>>>> wrote:
>>>>>> at. ! queue ! avenc_aac ! hl.audio \
>>>>>> vt. ! queue ! h264parse ! avdec_h264 ! xvimagesink \
>>>>>> vt. ! queue ! h264parse ! avdec_h264 ! xvimagesink \
>>>>>> vt. ! queue ! avdec_h264 ! queue ! x264enc tune=zerolatency
>>>>>> bitrate=1000 ! \
>>>>>
>>>>>
>>>>> You are decoding h264 3 times and also encoding aac audio and h264
>>>>> video at the same time. Perhaps optimizing the 3 decoding to 1 might
>>>>> help here.
>>>>
>>>> I took this and Nicolas' advice and with a bit of trial and error I get a
>>>> pipeline that previews and streams and has say 1 QoS event an hour (which is
>>>> in the no-worries bracket) but I cannot record the stream. Tried to match
>>>> caps etc. In the dump below the commented pipeline does work if I keep the
>>>> bitrate below say 4000Kb/s.
>>>>
>>>> The pipeline without the last 3 (record) lines works. With them I get
>>>>
>>>> Setting pipeline to PAUSED ...
>>>> 0:00:00.056481332 0x564e0e46b0c0 v4l2src
>>>> gstv4l2src.c:694:gst_v4l2src_query:<v4l2src0>Can't give latency since
>>>> framerate isn't fixated !
>>>> 0:00:00.056498225 0x564e0e46b0c0 aggregator
>>>> gstaggregator.c:2050:gst_aggregator_query_latency_unlocked:<mpegtsmux0>Laten
>>>> cy query failed
>>>>
>>>> <snip>
>>>>
>>>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal
>>>> data stream error.
>>>> Additional debug info:
>>>> ../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop ():
>>>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
>>>> streaming stopped, reason not-negotiated (-4)
>>>>
>>>> From the dot graph I can see framerate is NOT propegated, and my attempt to
>>>> set the the output caps of h264parse results in a syntax error.
>>>>
>>>> Can anyone teach me please.
>>>> James
>>>>
>>>> #! /bin/bash
>>>>
>>>> IP=192.168.5.150
>>>>
>>>> gst-launch-1.0 -e -v v4l2src device=/dev/video2 ! video/x-
>>>> h264,width=1920,height=1080,framerate=30/1 ! \
>>>> h264parse ! tee name=vt1 \
>>
>> I would give a try with a queue after v4l2src here, so pictures don't stay as
>> long in the driver queue, and reduce the risk of overrun.
>>
>>>> vt1. ! queue ! avdec_h264 ! tee name = vt2 \
>>>> vt2. ! queue ! xvimagesink \
>>>> vt2. ! queue ! xvimagesink \
>>>> at. ! queue ! avenc_aac ! hl.audio \
>>>> vt1. ! queue ! hlssink2 max-files=15 name=hl \
>>>> playlist-root=http://$IP <http://$ip/> playlist-location=/dev/shm/ch1.m3u8
>>>> location=/dev/shm/ch1_%05d.ts \
>>>> pulsesrc device=0 ! queue ! audioconvert ! \
>>>> tee name=at \
>>>> vt1. ! queue ! \
>>>> mp4mux name=mux ! \
>>>> filesink location=try7.mp4
>>>
>>> OK lots of trying. I'm using a 16 thread ryson. htop shows threads unused.
>>> nmon shows the cores NOT ever being bumped to max-clock-rate. Yet I stutter
>>> still. Frames are dropped but eg using vlc on windows the buffering allows the
>>> effect to be masked
>>> Did he sing "stopping" or "stping". I must be doing something but I know not
>>> what or where to look.
>>> If anyone had a comment or suggestion I'd appreciate it lots
>>>
>>> If it is helpful here is a pipeline I'm using
>>>
>>> gst-launch-1.0 -e -v v4l2src device=/dev/video2 ! \
>>> video/x-h264,width=1920,height=1080,framerate=30/1 ! \
>>> tee name=vt \
>>> vt. ! queue ! h264parse ! avdec_h264 ! \
>>> tee name=dt \
>>> at. ! queue ! avenc_aac ! hl.audio \
>>> dt. ! queue ! xvimagesink \
>>> dt. ! queue ! xvimagesink \
>>> vt. ! queue ! h264parse ! hlssink2 max-files=15 name=hl \
>>> playlist-root=http://$IP <http://$ip/> playlist-location=/dev/shm/ch1.m3u8
>>> location=/dev/shm/ch1_%05d.ts \
>>> vt. ! queue max-size-buffers=0 max-size-bytes=0 max-size-
>>> time=1000000000 ! h264parse ! \
>>> mux. \
>>> pulsesrc device=0 ! queue ! audioconvert ! \
>>> tee name=at \
>>> at. ! queue ! audioresample ! audio/x-raw, rate=48000 ! \
>>> queue ! avenc_aac ! queue ! \
>>> mux. mp4mux name=mux ! \
>>> filesink location=try4.mp4
>>>
>>> Try to eliminate the 2nd h264parse is harder than I can do. One would think
>>> matching caps would be easy.
>
>> I just read Tin-Philipp’s announcement and I will try it
>>
>> But I condense my problem down to
>>
>> v4l2src pulsesrc ! mp4mux | filesink
>>
>> I’ve tried with a 2 core i3, a 4 core i5, a 4 core i7, an 8 core rysan.
>>
>> On linux vlc plays with hardly any problem (sometime an audio is truncated ie instead of saying “stopped” it may say “stpped”
>> On windows vlc is similar.
>> On mac vlc you can hear the stutter (no matter how you set latency.)
>> Using ffmpeg to spelunk you can see dropped frames
>>
>> All hardware is similar WRT recorded file result; htop on the i3 shows threads at 60% ish. On the rysan some threads are idle, the rest 20% ish.
>> Ive heeded advice about queues.
>>
>> Using audiotestsrc the results are perfect!
>>
>> Surely this points to a problem with pulsesrc.
>> Various distros are different but at end of day 16 is unusable 18 is fraught maybe 20 will be ok
>>
>> I *need* multiple audio streams, but worst case I could have 2 audi cards and will try alsa for gstreamer
>>
>> Any comments, critiqe or opinions are welcome especially if someone has a working v4l2 pulse filesink pipeline (for x86_64, it looks like jenson do https://www.youtube.com/watch?v=Ml5giyTDi0Y <https://www.youtube.com/watch?v=Ml5giyTDi0Y>
>
> It's had to express without using AustralianWords, but I just built 1.20 from git and all trace of stutter is gone.
I'd really appeciate a nudge thanks:
I have built 18 and in response to Nicolas' post I did build 20 as per above.
I tried to build again today and got tied up in the monorepo quagmire.
Using one of the rstp examples (which I've done before) I get fail as x264enc is missing. A quick look and indeed it is not there.
AFAICT I've built plugins-ugly
meson lists libav: YES
The current build is 1.21
Documentation says "if you want to build 1.16, 1.18" then does not mention the subject after git clone ...
1) how do I build a specific release eg 1.20
2) how do I get the x264 plugins
Thanks
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220219/e60f2ace/attachment-0001.htm>
More information about the gstreamer-devel
mailing list