Fix the documentation image attachments
Fixes https://github.com/bigbluebutton/bigbluebutton/issues/20297
@ -126,11 +126,11 @@ The conversion process sends progress messages to the client through the Redis p
|
|||||||
|
|
||||||
The diagram below describes the flow of the presentation conversion. We take in consideration the configuration for enabling and disabling SWF, SVG and PNG conversion.
|
The diagram below describes the flow of the presentation conversion. We take in consideration the configuration for enabling and disabling SWF, SVG and PNG conversion.
|
||||||
|
|
||||||
![General Conversion Flow](/img/diagrams/Presentation Conversion Diagram-General Conversion Flow.png)
|
![General Conversion Flow](/img/diagrams/presentation-conversion-diagram-general-conversion-flow.png)
|
||||||
|
|
||||||
Then below the SVG conversion flow. It covers the conversion fallback. Sometimes we detect that the generated SVG file is heavy to load by the browser, we use the fallback to put a rasterized image inside the SVG file and make its loading light for the browser.
|
Then below the SVG conversion flow. It covers the conversion fallback. Sometimes we detect that the generated SVG file is heavy to load by the browser, we use the fallback to put a rasterized image inside the SVG file and make its loading light for the browser.
|
||||||
|
|
||||||
![SVG Conversion Flow](/img/diagrams/Presentation Conversion Diagram-SVG Conversion Flow.png)
|
![SVG Conversion Flow](/img/diagrams/presentation-conversion-diagram-svg-conversion-flow.png)
|
||||||
|
|
||||||
### Internal network connections
|
### Internal network connections
|
||||||
|
|
||||||
|
@ -27,7 +27,7 @@ After the session finishes, the BigBlueButton server will run an archive script
|
|||||||
|
|
||||||
After the recording is archived, BigBlueButton will run one (or more) ingest and processing scripts, named workflows, that will _process_ and _publish_ the captured data into a format for _playback_.
|
After the recording is archived, BigBlueButton will run one (or more) ingest and processing scripts, named workflows, that will _process_ and _publish_ the captured data into a format for _playback_.
|
||||||
|
|
||||||
![Record and Playback - Overview](/img/diagrams/Record and Playback Service Diagram-RAP - Overview.png)
|
![Record and Playback - Overview](/img/diagrams/record-and-playback-service-diagram-rap-overview.png)
|
||||||
|
|
||||||
## Record and Playback Phases
|
## Record and Playback Phases
|
||||||
|
|
||||||
@ -50,26 +50,26 @@ Whiteboard, cursor, chat and other events are stored on Redis. Webcam videos (.f
|
|||||||
|
|
||||||
The Archive phase involves placing the captured media and events into a **raw** directory. That directory contains ALL the necessary media and files to work with.
|
The Archive phase involves placing the captured media and events into a **raw** directory. That directory contains ALL the necessary media and files to work with.
|
||||||
|
|
||||||
![Record and Playback - Archive](/img/diagrams/Record and Playback Service Diagram-RAP - Archive.png)
|
![Record and Playback - Archive](/img/diagrams/record-and-playback-service-diagram-rap-archive.png)
|
||||||
|
|
||||||
### Sanity
|
### Sanity
|
||||||
|
|
||||||
The Sanity phase involves checking that all the archived files are _valid_ for processing. For example
|
The Sanity phase involves checking that all the archived files are _valid_ for processing. For example
|
||||||
that media files have not zero length and events were archived.
|
that media files have not zero length and events were archived.
|
||||||
|
|
||||||
![Record and Playback - Sanity](/img/diagrams/Record and Playback Service Diagram-RAP - Sanity.png)
|
![Record and Playback - Sanity](/img/diagrams/record-and-playback-service-diagram-rap-sanity.png)
|
||||||
|
|
||||||
### Process
|
### Process
|
||||||
|
|
||||||
The Process phase involves processing the valid archived files of the recording according to the workflow (e.g., presentation). Usually, it involves parsing the archived events, converting media files to other formats or concatenating them, etc.
|
The Process phase involves processing the valid archived files of the recording according to the workflow (e.g., presentation). Usually, it involves parsing the archived events, converting media files to other formats or concatenating them, etc.
|
||||||
|
|
||||||
![Record and Playback - Process](/img/diagrams/Record and Playback Service Diagram-RAP - Process.png)
|
![Record and Playback - Process](/img/diagrams/record-and-playback-service-diagram-rap-process.png)
|
||||||
|
|
||||||
### Publish
|
### Publish
|
||||||
|
|
||||||
The Publish phase involves generating metadata and taking many or all the processed files and placing them in a directory exposed publicly for later playback.
|
The Publish phase involves generating metadata and taking many or all the processed files and placing them in a directory exposed publicly for later playback.
|
||||||
|
|
||||||
![Record and Playback - Publish](/img/diagrams/Record and Playback Service Diagram-RAP - Publish.png)
|
![Record and Playback - Publish](/img/diagrams/record-and-playback-service-diagram-rap-publish.png)
|
||||||
|
|
||||||
### Post-Scripts
|
### Post-Scripts
|
||||||
|
|
||||||
|
Before Width: | Height: | Size: 55 KiB After Width: | Height: | Size: 55 KiB |
Before Width: | Height: | Size: 92 KiB After Width: | Height: | Size: 92 KiB |
Before Width: | Height: | Size: 107 KiB After Width: | Height: | Size: 107 KiB |
Before Width: | Height: | Size: 130 KiB After Width: | Height: | Size: 130 KiB |
Before Width: | Height: | Size: 52 KiB After Width: | Height: | Size: 52 KiB |
Before Width: | Height: | Size: 130 KiB After Width: | Height: | Size: 130 KiB |
Before Width: | Height: | Size: 109 KiB After Width: | Height: | Size: 109 KiB |
Before Width: | Height: | Size: 94 KiB After Width: | Height: | Size: 94 KiB |