I created a macvlan network as shown below.
docker network create -d macvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eno1 \
macvlan_network
And the container was created as shown below.
The plan was to create a mistserver inside the container to send and receive video via IP.
docker run -d --name mistserver1 --restart=always -v mistserver_config:/config -v /home/ketivrar/detr2:/home/shared_folder --net=macvlan_network --ip 192.168.1.16 r0gger/mistserver
There is no problem when transmitting video in the directory using the Mist server.
An error occurs when transmitting video using ffmpeg as shown below.
ffmpeg -re -i test7_10.mp4 -c:v libx264 -preset medium -b:v 8000k -f flv rtmp://192.168.1.16/live/cam1
If you run the above command, the following error will occur and it will stop.
av_interleaved_write_frame(): Connection reset by peer58.73 bitrate=8053.7kbits/s dup=0 drop=4 speed=0.948x
[flv @ 0x5582ab9e6e00] Failed to update header with correct duration.
[flv @ 0x5582ab9e6e00] Failed to update header with correct filesize.
Error writing trailer of rtmp://192.168.1.2/live/cam1: Connection reset by peer
frame= 1845 fps= 29 q=33.0 Lsize= 57806kB time=00:00:58.86 bitrate=8044.2kbits/s dup=0 drop=4 speed=0.94x
I wonder what the reason is...
I created two streams on the Mist server and sent video to each stream simultaneously.
ffmpeg -re -i test7_10.mp4 -c:v libx264 -preset medium -b:v 8000k -f flv rtmp://192.168.1.16/live/cam1
ffmpeg -re -i test7_10.mp4 -c:v libx264 -preset medium -b:v 8000k -f flv rtmp://192.168.1.16/live/cam2
av_interleaved_write_frame(): Connection reset by peer29.46 bitrate=8135.7kbits/s dup=0 drop=2 speed=0.343x
[flv @ 0x55975fb05e00] Failed to update header with correct duration.
[flv @ 0x55975fb05e00] Failed to update header with correct filesize.
Error writing trailer of rtmp://192.168.1.16/live/cam1: Connection reset by peer
frame= 971 fps= 11 q=33.0 Lsize= 29395kB time=00:00:29.66 bitrate=8116.6kbits/s dup=0 drop=2 speed=0.34x
####
av_interleaved_write_frame(): Connection reset by peer25.06 bitrate=8313.0kbits/s dup=0 drop=1 speed=0.292x
[flv @ 0x55ce4a7ce340] Failed to update header with correct duration.
[flv @ 0x55ce4a7ce340] Failed to update header with correct filesize.
Error writing trailer of rtmp://192.168.1.16/live/rtsp: Connection reset by peer
frame= 853 fps=9.8 q=33.0 Lsize= 25857kB time=00:00:25.76 bitrate=8220.2kbits/s dup=0 drop=2 speed=0.297x
It seems to stop before the total size of the two reaches 60000.
This time, I sent the video using OBS.
I confirmed that the connection was disconnected and reconnected at a similar time as ffmpeg.
I think there is a size limit somewhere. Could you please tell me a solution or the exact problem?
+++++
ffmpeg -re -i test7_10.mp4 -c:v libx264 -preset medium -b:v 4000k -f flv rtmp://192.168.1.16/live/cam1
->
[flv @ 0x56547e6f1e00] Failed to update header with correct duration.019.0kbits/s dup=0 drop=12 speed=0.982x
[flv @ 0x56547e6f1e00] Failed to update header with correct filesize.
frame= 5328 fps= 30 q=-1.0 Lsize= 87550kB time=00:02:57.93 bitrate=4030.8kbits/s dup=0 drop=12 speed=0.996x
success!
ffmpeg -re -i test7_10.mp4 -c:v libx264 -preset medium -b:v 5000k -f flv rtmp://192.168.1.16/live/cam1
->
av_interleaved_write_frame(): Connection reset by peer30.63 bitrate=5039.7kbits/s dup=0 drop=6 speed=0.965x
[flv @ 0x555ad97f7e00] Failed to update header with correct duration.
[flv @ 0x555ad97f7e00] Failed to update header with correct filesize.
Error writing trailer of rtmp://192.168.1.16/live/cam1: Connection reset by peer
frame= 2802 fps= 30 q=37.0 Lsize= 55876kB time=00:01:30.83 bitrate=5039.3kbits/s dup=0 drop=6 speed=0.962x
fail...
I only adjusted -b:v 5000k, but the results were mixed.
Are there any resource limits for each container?
I didn't set it up separately.
I see you're using a MistServer Docker image here for streaming. MistServer stores stream data inside shared memory, and Docker by default assigns only 64 MiB of shared memory to each container. This means MistServer will run out of memory after your buffers contain ~64 megabytes of stream data, which at 8mbps is in under a minute (considering there's some storage overhead and other data than just the stream data in memory as well).
To fix, simply make sure you start your container with the --shm-size=x option, where you replace x with about 90% of the host machine's RAM. (This is the maximum memory used, it's not actually reserved/used unless needed, so going slightly under your maximum RAM amount is generally recommended).
For example, if your host machine has 32GB of RAM installed, you could use --shm-size=30000m (though any value around ~200m-300m or higher would likely support a single stream in most configurations without any issues already, there is no harm in setting it higher).