Ms 274 live queueing video frames #60
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This patch makes use of Membrane timers to allow live operation of the compositor. A timer with interval equal to seconds / frames is started when the element starts operating. Whenever a frame is composed naturally (when all vidoes have frames ready for composition) the timer is restarted. When the timer ticks, a frame is forcibly rendered, using previous frames as fallback in cases where we don't have a frame ready. To protect against stale frames clogging the front of the queue, whenever a frame is rendered stale frames are removed from the front of the queue.
A new element, `BadConnectionEmulator`, was added to simulate delays and packet loss. The `ComposeMultipleInputs` pipeline was altered to allow introducing an additional filter between the decoder and the compositor. A new test was added (`packet_loss.ex`). It is completely analogous to the h264 pipeline test, but uses the `BadConnectionEmulator` and sets the compositor to live mode. This test doesn't verify much unfortunately. Since some frames are randomly dropped or delayed, there is no reference result to compare to.
Janix4000
reviewed
Nov 15, 2022
Janix4000
suggested changes
Nov 15, 2022
DominikWolek
suggested changes
Nov 16, 2022
DominikWolek
approved these changes
Nov 17, 2022
The documentation now precisely describes what happens when frames are dropped
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch makes use of Membrane timers to allow live operation of the
compositor:
A timer with interval equal to seconds / frames is started when the element starts operating.
Whenever a frame is composed naturally (when all vidoes have frames ready for composition) the timer is restarted.
When the timer ticks, a frame is forcibly rendered, using previous frames as fallback in cases where we don't have a frame ready.
To protect against stale frames clogging the front of the queue, whenever a frame is rendered stale frames are removed from the front of the queue.
It also adds tests:
A new element,
BadConnectionEmulator, was added to simulate delays andpacket loss.
The
ComposeMultipleInputspipeline was altered to allow introducing anadditional filter between the decoder and the compositor.
A new test was added (
packet_loss.ex). It is completely analogous tothe h264 pipeline test, but uses the
BadConnectionEmulatorand setsthe compositor to live mode.
These tests don't verify much unfortunately. Since some frames are
randomly dropped or delayed, there is no reference result to compare to.