stuttering
James
jam at tigger.ws
Tue Feb 15 23:30:35 UTC 2022
> On 4 Feb 2022, at 11:52 pm, James Linder via gstreamer-devel <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.
> Nicolas apologies for the off-list reply. This mailer keps biting me.
Nearly! gone.
Lots more fiddling shows alsasrc has no stuttering while pulsesrc does.
Is there an inherit defect with pulsesrc?
Not using pulse makes other things very messy (forwarding audio, vumeters etc) I'm about to try pulse->alsa and use that source, but is opinion (from those who know) that pulsesrc will continue to improve?
It is quite conceivable that pulsesrc has not changed but that something else affects it.
In any event 16 was unsable, 18 was modestly bad, 20 is mostly ok. I'm peddling so hard Ive not had time to spelunk the src
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220216/767c9c7b/attachment-0001.htm>
More information about the gstreamer-devel
mailing list