You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Starting with BigBlueButton 2.5, generation of video files during recording processing is a fair bit slower than 2.4.
I have done some investigation into the issue, and it looks like the problem is related to how ffmpeg re-initializes the entire filter chain when one of the input files has a change in resolution. When an input has a video resolution change, ffmpeg tears down all of the video filters, and creates new ones with the same options, so it can re-negotiate all of the formats (e.g. scale filter can learn about the new input size and/or aspect ratio). The problem is that some of the filters used in our filter command have state - e.g. the fps filter tracks the current pts, and the color filter will restart from pts=0. The result is that the filter chain ends up re-running a bunch of duplicate frames through the scale and overlay filters all the way from the start of the video - which then get dropped on the output (due to the -r 24 output option). This extra work causes recording processing to be slower.
BigBlueButton 2.4 was not affected, because it used the movie filter within the filter chain to input videos. With the input inside the filter chain, the filters do not get re-initialized on video resolution changes. The problem with that, of course, is that video resolution changes which cause the video aspect ratio cannot be handled.
I believe this issue can be fixed by re-organizing how the filter chains are built to remove the state from the filter chain.
The text was updated successfully, but these errors were encountered:
Starting with BigBlueButton 2.5, generation of video files during recording processing is a fair bit slower than 2.4.
I have done some investigation into the issue, and it looks like the problem is related to how ffmpeg re-initializes the entire filter chain when one of the input files has a change in resolution. When an input has a video resolution change, ffmpeg tears down all of the video filters, and creates new ones with the same options, so it can re-negotiate all of the formats (e.g. scale filter can learn about the new input size and/or aspect ratio). The problem is that some of the filters used in our filter command have state - e.g. the
fps
filter tracks the current pts, and thecolor
filter will restart from pts=0. The result is that the filter chain ends up re-running a bunch of duplicate frames through the scale and overlay filters all the way from the start of the video - which then get dropped on the output (due to the-r 24
output option). This extra work causes recording processing to be slower.BigBlueButton 2.4 was not affected, because it used the
movie
filter within the filter chain to input videos. With the input inside the filter chain, the filters do not get re-initialized on video resolution changes. The problem with that, of course, is that video resolution changes which cause the video aspect ratio cannot be handled.I believe this issue can be fixed by re-organizing how the filter chains are built to remove the state from the filter chain.
The text was updated successfully, but these errors were encountered: