Fix 2 bugs in an FFmpeg based encoder

We’re looking for someone with FFmpeg development expertise who can help us solve 2 problems. Our company has created an RTMP encoder/streamer application using FFmpeg. The application muxes audio and video from multiple sources, and produces output that it then streams via RTMP, using FFmpeg. The application runs on macOS, currently on Sierra (10.12.6). The problems are as follows: Issue 1. Our FFmpeg based RTMP encoder produces VERY large frames after changing from a static image input. The problem evolves as follows: a. The encoder encodes and streams a still image for 30 or more seconds. During this time, output frames are of a normal size, and the output bitrate is at or under the specified target bit rate. b. The content changes to a different, and moving picture.. At this time, the encoder’s output frames are VERY large, and the output bitrate is far above the specified target bit rate. c. After approximately 30 seconds, the frames sizes return to normal, and the output bitrate of the motion video is roughly equal to the specified target bit rate. There is a proportional relationship between the duration the static image is encoded in step (a) and the frame size and duration of impact. Our encoder settings: Video: - Codec: H.264 - AVC Level: 4.1 - Data Rate: 1000kbps - Resolution: 1280x720p - Keyframe Interval: 2 seconds - Frames per Second: 30 - Profile: High Audio: - Codec: AAC - Sample Rate: 48kHz - Channels: 2 - Data Rate 96kbps FFmpeg command line does not exhibit the same problem. FFmpeg produces consistent frame sizes & the output bitrate remains consistent for the duration of the encode. The following command line is used to in our testing: ffmpeg -re -i [login to view URL] -b:v 1000k -vcodec h264_videotoolbox -ar 48000 -ab 96k -acodec aac -profile:v high -level:v 4.1 -f flv rtmp://hostname/appname/live/ffmpeg-test1 We have also examined the recordings of both the FFmpeg output and of our encoder’s output with FFprobe. We have converted the FFprobe output to CSV format, so it is easier to read. Our encoder's recorded video output ([login to view URL]), and the FFprobe output ([login to view URL]) are attached to this posting. You will notice that our command line uses h264_videotoolbox rather than libx264. Our encoder users h264_videotoolbox also. We have also tested our encoder when using libx264 and it shows exactly the same problem. We would like to resolve this issue with our encoder, so that it will not inflate the frame size, forcing the bit rate over the target bit rate. Our encoder should perform as well as FFmpeg command line does. Issue 2. The RTMP @setDataFrame’s onMetaData payload for our implementation differs from what FFmpeg produces from the command line. The primary concern is that the framerate is not specified. We would like to make sure the framerate is included. Secondarily, We would like to understand why our implementation specifies 'duration' and 'filesize'. This is a live stream so those values seem invalid. Our implementation sends the following values in the onMetaData message: duration: 0.0 width: 1280.0 height: 720.0 videodatarate: 1000.0 videocodecid: 7.0 audiodatarate: 96.0 audiosamplerate: 48000.0 audiosamplesize: 16.0 stereo: true audiocodecid: 10.0 encoder: Lavf57.66.102 filesize: 0.0 Our FFmpeg command line is set as follows, to match the values configured in my implementation as closely as possible. ffmpeg -re -i [login to view URL] -b:v 1000k -vcodec h264_videotoolbox -ar 48000 -ab 96k -acodec aac -profile:v high -level:v 4.1 -f flv rtmp://[login to view URL] FFmpeg sends the following values in the onMetaData message. width: 1280.0 height: 720.0 videodatarate: 976.5625 framerate: 30.0 videocodecid: 7.0 audiodatarate: 93.75 audiosamplerate>48000.0 audiosamplesize: 16.0 stereo: true audiocodecid: 10.0 major_brand: qt minor_version: 0 compatible_brands: qt encoder: Lavf57.56.101