ffmpeg streaming

source settings: ffmpeg -i /dev/video0 -preset ultrafast -vf "fps=60" -tune zerolatency (-rtbufsize 100M) -s 1080*720 -f mpegts udp://192.168.56.1:8888

ffmpeg -input_format mjpeg -i /dev/video0 -s 640*480 -r 10 -q:v 3 udp://192.168.157.17:8888/test.mjpeg

注：-tune 和 -preset 是针对h264编码器的参数，各种格式的私有参数可以通过 ffmpeg -h encoder=mjpeg 查看。

dst settings: ffplay --fflags nobuffer -sync ext udp://192.168.56.1:8888 

https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=376

Default low-level buffer seems to be 32kb long.

Libav first loads about 5Mb of data and uses them to determine format.

You can change this amount by changing AVFormatContext::max_analyze_duration.

In my code I have

Code:Select all

input->max_analyze_duration = 2 * AV_TIME_BASE; // read 2 seconds of data

These data are stored in the AVFormatContext::AVPacketList field, and libav gives these data in response to calls to av_read_frame(), simultaneously removing them from the packet list.

Then it reads data from a stream, using that low-level buffer.

You can define your own AVIOContext and have finer control of this reading.

See manuals of avio_alloc_context(), AVFormatContext::pb, AVFMT_FLAG_CUSTOM_IO.

You can wait some time before reading, but this is limited to the system TCP buffer size, in case of TCP. In case of UDP, you'll lose all unread UDP packets.

Libav doesn't reconnect after timeouts, so, you should implement this error restoration by yourself.

If you use custom AVIOContext, and your reading function returns error code, you can see this code in the AVIOContext::error field.

If you restore after errors, you should zero this field, and also AVIOContext::eof_reached field.

To detect connection failures and conditions for reconnection, you should check both the result of av_read_frame() and AVIOContext::error.

If av_read_frame()'s result == 0, and AVIOContext::error == some_error_code, then current frame, returned by av_read_frame() is OK, but there are errors, and you should reconnect, and rerequest data right after the current frame.

If you don't reconnect, the next call to av_read_frame() will return the same some_error_code.

1. 使用FFMPEG拿到wifi传来的视频后需要处理解码得到字符流

2. 再通过socket传给另外一个端口由unity获取，转换为字节流

3. 字符流转为opencv的Mat格式用于之后的图像视频处理。

关于fifo_buffer的错误警告：在路径中添加？fifo_size=1000000&overrun_nonfatal=1 得以解决

原因：Poster1: What causes these circular buffer overruns? My assumption is that ffmpeg is reading the input stream into the aforementioned circular buffer, and the code then generates the output stream also reads from that same buffer. The overrun would happen when the code that generates the output doesn't keep up with the rate at which it's being written to the buffer, right? Poster2: Looking at the source code it appears that the buffer gets overflowed either by too fast input or too slow output (slow cpu?). Your assumption is correct.

So theory was that our binary doesnt read pipe fast enough. As a result pipe gets blocked, and ffmpeg cannot write to it, and THAT results in udp fifo buffer overrun (ffmpeg keeps reading udp INTO FIFO, but cannot write FROM it into our pipe) 

https://stackoverflow.com/questions/35338478/buffering-while-converting-stream-to-frames-with-ffmpeg