stuttering

Fri Feb 4 15:52:27 UTC 2022

> 
> On 30 Jan 2022, at 9:50 pm, Nicolas Dufresne <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> wrote:
>>> 
>>> On 22 Jan 2022, at 9:38 pm, Kaj-Michael Lang via gstreamer-devel
>>> <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 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 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.
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220204/b2616976/attachment-0001.htm>