The situation is kind of complex. I was archiving several CCTV camera feeds (rtsp, h264, no audio) through OpenCV, which worked but the CPU utilization was too high and started to lose some frames time by time.
To reduce the CPU utilization, I started to use FFMPEG to skip the decoding and encoding processes, which worked perfectly on my home machine. However, when I connected to my university VPN and tried to deploy it on our lab server, FFmpeg couldn't read any frame, ffplay couldn't get anything either. However, OpenCV, VLC Player and IINA Player could still read and display the feed.
In Summary,
1 FFMPEG/ffplay
1.1 can only read the feed from my home network(Wi-Fi, optimum)
1.2 from other two networks, the error message says: "Could not find codec parameters for stream 0 (Video: h264, none): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options"
2 IINA/VLC Player, OpenCV
These tools can get the video all the time.
I'm wondering whether it's related to some specific port access, that the ffmpeg required but the others don't. I'd appreciate it if anyone can provide any suggestions.
As references, the tested ffplay command is simple:
ffplay 'the rtsp address'
Thanks
Update
More tests have been performed.
By specifying rtsp_transport as TCP, ffplay can play the video, but FFmpeg can't access the video. (In the beginning, when both FFmpeg and ffplay worked through my home network, it was UDP)
The FFmpeg command is as follows:
ffmpeg -i rtsp://the_ip_address/axis-media/media.amp -hide_banner -c:v copy -s 1920x1080 -segment_time 00:30:00 -f segment -strftime 1 -reset_timestamps 1 -rtsp_transport tcp "%Y-%m-%d-%H-%M-%S_Test.mp4"
Please help...
Solved by forcing it to use "-rtsp_transport tcp" right before -i.
ffmpeg -rtsp_transport tcp -i rtsp://the_ip_address/axis-media/media.amp -hide_banner -c:v copy -s 1920x1080 -segment_time 00:30:00 -f segment -strftime 1 -reset_timestamps 1 "%Y-%m-%d-%H-%M-%S_Test.mp4"
Related
Description
I pushed a USB camera stream by ffmpeg to a RTMP stream server which is called SRS.
The SRS had saved a MP4 file for me. The frame rate is not a common value in VLC - it's 14.939948. I've checked it out - It seems to be the 'ntsc' format.
Meanwhile, I had received the stream by OpenCV and saved it as another MP4 file.They're not synchronized.
I have tried to convert the frame rate by ffmpeg but was still not synchronized. The only way to make it is to put it in Adobe Premiere and modify the frame rate. Here is the ffmpeg commands I executed:
ffmpeg -i 1639444871684_copy.mp4 -filter:v fps=15 out.mp4
Aside from the stream server, how can I convert the frame rate to normal and keep synchronized at the same time?
Note: For live streaming, you should never depends on the FPS, because RTMP/FLV always use fixed TBN 1k, so there is always introduce some deviation, when publish stream as RTMP or record to other format like TS/MP4.
Note: For WebRTC, the fps is variant, please read Would WebRTC use a constant frame rate to capture video frame or about the Variable Frame Rate (VFR)
It's not a problem of SRS or FPS, you can also replay it by FFmpeg.
Use FFmpeg to transcode doc/source.flv from 25fps to 15fps, then publish to SRS by RTMP(15fps).
Use FFmpeg to record the RTMP(15fps) as output.mp4(15fps).
Use VLC to play the output.mp4(15fps), it show the fps IS NOT 15fps.
First, please start SRS by bellow config, note that DVR disabled:
# ./objs/srs -c test.conf
listen 1935;
daemon off;
srs_log_tank console;
vhost __defaultVhost__ {
}
Run FFmpeg to transcode and publish to SRS, change the fps to 15:
cd srs/trunk
ffmpeg -re -i doc/source.flv -c:v libx264 -r 15 -c:a copy \
-f flv rtmp://localhost/live/livestream
Record the RTMP stream(in 15fps) to output.mp4, note tat the fps is, in FFmpeg logs, it's 15fps:
ffmpeg -f flv -i rtmp://localhost/live/livestream -c copy -y output.mp4
Use VLC to play the output.mp4 which is 15fps, open the Window -> Media Information, you will find out that the fps is changing around 14.8fps, not 15fps!
It's because the TBN of RTMP/FLV, is fixed 1000(1k tbn, each frame is about 66.66666666666667ms), so the deviation is introduced when publish MP4 to RTMP stream. It's not caused by DVR, it's caused by RTMP/FLV TBN.
Note: However, for SRS, using fixed TBN 1k is not a good choice, because it's not friendly for MP4 duration, I reopen the issue srs#2790.
Ultimately, the framerate/fps is not a fixed stuff, it's just a number that give some tips about the stream. Instead, the player always use the DTS/PTS to decide when and how to render the picture.
Answer myself. Here is my method: Read by OpenCV and write frames to a new file at 15FPS. They're going to be synchronized.
with -r
ffmpeg -i 1639444871684_copy.mp4 -r 15 out.mp4
I am trying to re-stream an MJPEG stream over dash using ffmpeg.
I have an ESP32 camera module that outputs an MJPEG livestream at 192.168.2.128:81/stream (Arduino code here).
I can open this stream directly in the browser and see the video in realtime, but the camera will only allow for a single client at a time while I am in need of a multi client solution.
What doesn't work
A solution I am currently trying to implement is to use a seperate server (Raspberry Pi) running apache and ffmpeg to re-stream the MJPEG content using DASH:
ffmpeg -re -i http://192.168.2.128:81/stream -strict -2 -an -c:v copy -b:v 2000k -f dash -window_size 4 -extra_window_size 0 -min_seg_duration 2000000 -remove_at_exit 1 /var/www/html/out.mpd
I get no errors when executing this command on the server.
I then use this ffmpeg-dash.html to display the video in the browser.
This code unfortunately fails, in Firefox the console reports the error:
[72][Stream] No streams to play.
followed by:
Cannot play media. No decoders for requested formats: video/mp4;codecs="mp4v.6c";width="640";height="480"
What does work
What is puzzling me is that the above code works fine if I replace the MJPEG livestream url with a sample .mkv file, so if I use
ffmpeg -re -i /var/www/html/video.mkv -strict -2 -an -c:v copy -b:v 2000k -f dash -window_size 4 -extra_window_size 0 -min_seg_duration 2000000 -remove_at_exit 1 /var/www/html/out.mpd
I can view the livestreamed sample video (video.mkv) without problems using the previously mentioned ffmpeg-dash.html file.
Furthermore, it seems that ffmpeg can read the MJPEG livestream without problems, since
ffmpeg -t 10 -i http://192.168.2.128:81/stream -filter:v fps=15 -c:v flv test.flv
returns a 10 second clip of the livestream succesfully.
So to me it seems that the problem lies in how I combine the two. What am I missing? Is it even possible to stream MJPEG content over MPEG-DASH?
(I am new to this, sorry in advance for my ignorance)
I'm trying to record from a microphone and webcam on MacOS with the following command:
ffmpeg -f avfoundation -framerate 30 -i "0:0" ~/recorded.mp4
My result has crackling in the audio.
I'm familiar with this problem when you use a DAW: you solve it by increasing the sample buffer. The idea is that audio samples coming from your interface/mic are not coming in a consistent or fast enough rate, so the missing samples being filled with zeroes causes the crackling sound. To avoid missing samples you want the recording software to wait longer for samples accumulating in a buffer before they're processed.
How can you configure such buffer for ffmpeg?
Version 4.3 seems to have this issue. Try with 4.2.
It seems to me that giving the -aq 0 audio quality parameter reduces this issue.
ffmpeg -f avfoundation -i 0:0 -acodec pcm_f32le -ar 48000 -aq 0 output.wav
I'm currently using the streaming plugin as follows
Fancy artchitecture here
OBS--------RTMP--------->NGINX-Server------FFMPEG(input RTMP output RTP)--------->JANUS---------webrtc-------->Client
When using the ffmpeg command (bellow), on the Janus streaming interface, we only see the bitrate that corresponds to that of the ffmpeg output in the console but we don't see any video.
ffmpeg -i rtmp://localhost/live/test -an -c:v copy -flags global_header -bsf dump_extra -f rtp rtp://localhost:8004
(using "-c:v copy" so that no encoding is used and hence reducing the
latency)
The video shows fine if I use "-c:v libx264", the only issue is that it is CPU intensive and adds latency.
Previously I had tried using RTSP as input for FFMPEG and in this case the video show fine with almost no latency even though I use "-c:v copy".
So I don't realy get why for RTSP the copy works fine, but for RTMP I have to use the libx264 codec. If anyone has an idea about this I am all ears :)
I had similar issue and my problem was that the stream / video that I used has large GOP size.
For WebRTC, latency is sub-second, so the input source should have short interval I frames. Better to remove B frames since they referring backward and forward as well.
Here are commands that you could use for small GOP size (4) and remove B frames.
Using RTMP streaming src:
ffmpeg rtmp://<your_src> -c:v libx264 -g 4 -bf 0 -f rtp -an rtp://<your_dst>
Using a mp4 file:
ffmpeg -re -i test.mp4 -c:v libx264 -g 4 -bf 0 -f rtp -an rtp://<your_dst>
-c:v copy does not reduce latency. It merely tells ffmpeg not to transcode.
I am streaming from the ip camera which uses RTSP protocol and ingesting the feed to RTMP(to Azure media server) using the following command
ffmpeg command : ffmpeg -f lavfi -i anullsrc -rtsp_transport tcp -i rtsp://CloudAppUser:admin#192.168.8.145/MediaInput/h264/stream_1 -vcodec libx264 -t 12:00:00 -pix_fmt + -c:v copy -c:a aac -strict experimental -f flv rtmp://channel1-cloudstream-inso.channel.media.azure.net:1934/live/980b582afc12e421b85b4jifd8e8662b/df
I am able to watch the stream but it is buffering once in every 30 seconds , and I want to know the reason behind this buffering
Please any one change this command , so that it should not buffer
I am executing this command from my terminal
I would like to watch my live stream in azure media player without any buffering and latency below 1 minute is not an issue
As documented here, when on-premise encoders are set up to push a contribution feed into a Channel, we recommend that these encoders use fixed 2 second GOPs. If your IP camera is not sending 2 second GOPs, you'd have to modify the ffmpeg commandline to re-encode the input video bitstream, and not just copy it. If that doesn't help, recommend contacting us via amshelp#microsoft.com with the (output) stream URL, and other details like the Media Service account name, region used, and date/time/timezone you attempted to stream the feed.