Trying to transcode two streams into one gives me poor/unstable encoding speeds from x0.400 to x0.988, sometimes above x1.
fmpeg \
-thread_queue_size 15 -rtbufsize 100M -i "https://.../stream.m3u8" \
-thread_queue_size 15 -rtbufsize 100M -i "http://.../video.mjpg" \
-filter_complex \
"[0:v]setpts=PTS-STARTPTS [bg]; \
[1:v]scale=200:-1,setpts=PTS-STARTPTS [fg]; \
[bg][fg]overlay=W-w-10:10" \
-c:v mpeg1video \
-b:v 1000k \
-r 25 \
-threads 1 \
-f mjpeg udp://127.0.0.1:1235?pkt_size=1316
Hardware specs:
CPU is Intel Core 2 Duo
Mechanical hard drive
I choose the mpeg1video encoder because of the low CPU usage. It seems that my Core 2 Duo can't keep up with libx264 .
I played with output bitrates, fps and threads, -re but nothing seems to improve and stabilize encoding speed to x1. Which parameters do I need to change/add/remove to achieve a reliable x1 encoding speed?
Input streams are not reliable, download internet connection is slow and unreliable.
Related
At the outset, I will say that I am trying to establish a connection via websocket and rtsp. I use forked node-rtsp-stream.
I have problem with huge latency about 10-15 seconds. I came to the conclusion that ffmpeg is to blame.
My observations:
When I use
ffmpeg -rtsp_transport tcp \
-fflags discardcorrupt \
-f mpeg1video \
-i rtsp://{id-address}
at the start, there is a delay of about 8-6 seconds after which the stream gently accelerates and finally the delay is on the level of 1-2sec. However with the newest version of jsmpeg I get on frontend player only jsmpeg possible garbage data. skipping
When I use
ffmpeg -rtsp_transport tcp \
-fflags discardcorrupt \
-i rtsp://{id-address}\
-f mpegts \
-codec:v mpeg1video \
-b:v 1000k \
-bf 0
I have a latency of about 18-10 seconds at startup and I can't go below that even if I try to speed up the whole stream with startup arguments
What's wrong?
I'm working on a robot (raspberry pi 4 based) that is accessible from anywhere. My robot is currently at a 3-second latency. I also use OvenMediaEngine (RTMP to WebRTC) to transmit my stream to the client (on a website).Here is my command:
raspivid -n -t 0 -w 1280 -h 720 -fps 25 -b 3500000 -g 50 -fl -o - | ffmpeg -thread_queue_size 1024 -i - -itsoffset 6 -f alsa -channels 1 -thread_queue_size 1024 -i hw:2 -preset ultrafast -tune zerolatency -vcodec libx264 -r 25 -b:v 512k -s 1280x720 -acodec aac -ac 2 -ab 32k -ar 44100 -f flv rtmp://xxxxxxxx:1935/app/stream
Does anyone know why it won't stream at subsecond latency?
Thanks in advance!
I am not exactly sure where you are incurring latency, but it usually happens either during transport or encoding.
If possible I would see if you avoid re-encoding to H264. You are going to pay a penalty of decoding (or just parsing?) and then encoding.
I would also see if you can ingest into OME with something other then RTMP. WebRTC and RTSP both will give you better latency.
What are the options in this command that would cause my encoding speed to be 0.999x instead of 1.0x or higher?
ffmpeg -y \
-loop 1 -framerate 30 -re \
-i ./1280x720.jpg \
-stream_loop -1 -re \
-i ./audio.mp3 \
-vcodec libx264 -pix_fmt yuv420p \
-b:v 2500k -maxrate 2500k -bufsize 10000k \
-preset slow -tune stillimage \
-b:a 128k -ar 44100 -ac 2 -acodec aac \
-af "dynaudnorm=f=150:g=15" \
-g 60 \
-f flv tmp.flv
I am trying to figure out why would this only be encoding at 0.999x speed, is there anything that I could do to speed this up? 2 pass encoding? I cannot understand why the encoding speed is so slow?
Also please not i've tried present from slow - ultrafast, the encoding speed stays relatively unchanged.
The -re is the rate-limiting factor. It only feeds input in real-time so the encoder can't progress any faster.
Remove the -re before the inputs. Needed only when trying to simulate a real-time input or streaming to an output that expects its input in real-time.
I am using ffmpeg and mpv, to stream audio/video between two hosts. One of the hosts is sending stream with ffmpeg:
ffmpeg -f pulse \
-thread_queue_size 0 \
-i audioInput \
-f video4linux2 \
-thread_queue_size 0 \
-standard PAL \
-i videoInput \
-vcodec mpeg4 \
-r 10 \
-s 176x144 \
-maxrate 256K \
-acodec pcm_s16le \
-ar 8000 \
-b:a 32k \
-af aresample=async=1000 \
-f rtsp \
-rtsp_transport tcp \
url
and second host is receiving with mpv:
mpv url --rtsp-transport=tcp \
--profile=low-latency \
--demuxer-lavf-o=rtsp_flags=listen \
--no-cache \
--autosync=30 \
--no-demuxer-thread \
--demuxer-lavf-analyzeduration=0 \
--demuxer-lavf-probesize=32
I have tried a lot of options and combinations to reduce latency as much as possible. Above commands works nice, the latency on startup is < 1s. Unfortunately, sometimes, delay appears during streaming and it can even increase in time. My goal is to ensure, that delay will be more or less constant (close to 1s), and if some delay will appear, delayed frames will be dropped (even if it will affect audio or video quality).
How to force ffmpeg/mpv to drop frames, which are delayed e.g. more than 1s?
I am trying to convert a source VBR SPTS MPEG-2 TS file into CBR using ffmpeg. The code I am using is the following:
#!/bin/bash
pkill ffmpeg
ffmpeg \
-re -i source.ts -c copy \
-muxrate 18000K \
-f mpegts \
udp://destination_ip:1234?pkt_size=1316
The source VPID bitrate is ~ 10Mbps and the APID is 296Kbps. So according to my understanding this code should deliver 18Mbps CBR where the difference between the muxrate and the bitrate of all the PIDs is filled with null packets.
The problem is that the output is far from perfect. The overall bitrate is semi-CBR at best. It ranges between 12Mbps and 15Mbps and I see a lot of PCR accuracy and PCR repetition errors along with CC errors both on the VPID and APID.
Some ideas:
make sure you have a recent version of ffmpeg because at some point there was a bug which messed up PCR insertion when stream copying
if you want constant UDP output you must use the bitrate option like:
-flush_packets 0 -f mpegts "udp://destination_ip:1234?pkt_size=1316&bitrate=18000000"
UDP is an unreliable protocol and you might experience packet loss (unfortunately the bitrate option only works for UDP for now AFAIK)
if you have a dedicated connection but still experience CC errors check the destination OS max UDP buffer sizes and make sure it can handle 18 Mbps
specify -minrate and -maxrate too.
use -bufsize bigger than bitrate.
set -muxrate value like bufsize.
The final command:
ffmpeg \
-re -i source.ts \
-b:v 10500k \
-minrate 10500k \
-maxrate 10500k \
-bufsize 18000k \
-muxrate 18000k \
-f mpegts \
udp://destination_ip:1234?pkt_size=1316