<div dir="ltr"><div>This is the first I am seeing of this and I am in no way a GStreamer expert. I have some familiarity as I have been looking into it as a replacement for the manual system I have that is using modified live555.</div><div><br></div><div>I assume since this is all open source, you have built it your self and done a CPU sampling kind of profiling.</div><div><br></div><div>Am I seeing the encoding of H264 and AAC. Do we know if the GPU is being used? <br></div><div>You may find encoding H264 with fast CPU better than waiting to move raw frames across the bus to the GPU and then the compressed data back to main memory.  <br></div><div>( Encoding is of course a LOT more bus traffic than Decoding which only has to move compressed data to the card which decodes and displays.  can be a 25 to 1 difference!)<br></div><div><br></div><div></div><div>I also do not see any buffers. Moving that keyframe is going to cause a pause. <br></div><div>There is probably some default, and someone else can chime in, but I think you must consider that video must come in at one rate and audio another,</div><div>You must operate with some latency by using buffers because you cannot predict the future for packets you have not gotten. <br></div><div>A tiny amount of buffers lets you operate just behind enough to imperceivable have what you need at the correct time.</div><div><br></div><div>Now the hls stuf is going to have a built in latency of it's own of course.</div><div><br></div><div>Profile, Profile, Profile :-)<br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 2, 2022 at 6:16 PM James via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">gstreamer seems very nice in concept. The fact that I've been trying for 3 months and can get no help is a big deterent.<br>
<br>
I've got a 4 core i7 NUC clocked to 4.8G and I get a stream of QoS messages telling me the computer is too slow.<br>
(GST_DEBUG=2,pulsesrc:6)<br>
<br>
The machine is idle running a single pipeline.<br>
The stream stutters. ffmpeg shows dup and often a 100 dropped frames on each segment.<br>
<br>
Using audiotestsrc renders perfectly.<br>
<br>
#! /bin/bash<br>
<br>
IP=`hostname -I`<br>
<br>
gst-launch-1.0 -e -v v4l2src device=/dev/video2 ! \<br>
        video/x-h264,width=1920,height=1080,framerate=30/1 ! \<br>
        h264parse ! \<br>
        tee name=vt \<br>
        vt. ! queue ! hlssink2 max-files=5 name=hl \<br>
        playlist-root=http://$IP playlist-location=/dev/shm/channel1.m3u8 location=/dev/shm/segment_%05d.ts \<br>
        pulsesrc device=0 ! audioconvert ! avenc_aac ! \<br>
        tee name=at \<br>
        at. ! queue ! aacparse ! hl.audio<br>
<br>
The redundant tee's are for use later.<br>
unless I see a euroka moment I'll have to try somethink else<br>
James<br>
<br>
</blockquote></div>