Pick the right sharing method
This guide covers a presenter’s media workflow. For a failed capture prompt, missing screen button, black screen or permission error, use the existing screen-sharing troubleshooting guide.
The controls below were checked against released Jitsi Meet 11248 source on 28 October 2026. Deployments can hide controls or configure different policies. No live meeting, media playback, audio capture or phone test was performed. [S1][S2][S3]
| Your content | Starting point | What to verify |
|---|---|---|
| A suitable YouTube or direct video link | Share video | Other clients load the player and hear the intended media. [S1] |
| An application, local presentation or a browser tab | Start screen sharing | Correct surface selected; an offered audio option enabled if sound is needed. [S3][S4] |
| Browser audio without displaying the captured video | Share audio, when supported | Correct source, audible output at the receiver and no feedback. [S3] |
Use a short clip you are permitted to present and ask a consenting attendee to help check it. Prefer headphones and one active audio device per physical room. Hearing your own speakers is not a receiver test; microphone pickup can also disguise a missing media-audio track. See the echo and feedback checklist.
Share a YouTube or direct video link
- Open the meeting’s available Share video action, commonly in the additional toolbar actions. The reviewed dialog is titled Share video and asks for a Video link. [S1]
- Paste a suitable YouTube link or a direct, playable video URL and select Share. The reviewed parser recognizes specified YouTube URL forms; it does not establish that every playlist, Shorts page or redirect is supported. [S1]
- Check the shared player with another attendee. The reviewed web client uses a YouTube player for a recognized video ID and an HTML video player for a direct URL. Each viewer must be able to load the relevant media; the sender’s access alone is insufficient. [S1][S2]
- Use the sharing owner’s available player controls to rehearse play, pause and seeking. Playback state and time are exchanged with the meeting; do not promise perfect synchronization or successful delivery from the existence of a control. [S1][S2]
- When finished, use Stop video and confirm that sharing has ended for the attendee. The reviewed toolbar disables another participant’s sharing action while an existing owner’s video is active. Coordinate with that owner rather than starting a competing share. [S1]
A private local file path is not an upload to the meeting. A cloud-drive preview page or an ordinary website is also not necessarily a media URL. The reviewed direct player uses the supplied URL as its video source. Do not make a private file public just to work around playback: use your organization’s approved access method or an appropriate screen-capture workflow. [S2]
An external-video confirmation may appear for attendees. The source combines default/configured trusted domains with a confirmation path for other links. Treat the prompt as a real choice about contacting that external service. Do not change sharedVideoAllowedURLDomains to a wildcard as a generic fix. A deployment’s disableThirdPartyRequests setting can also disable shared-video functionality. Ask the operator about the intended policy. [S1][S2]
Share a browser tab with its sound
- Open the intended video or audio content in a separate browser tab.
- Start screen sharing in the meeting and select that content tab in the browser’s picker.
- Enable the picker’s offered audio option, often labeled Share tab audio or Share audio, before confirming. Available choices depend on the browser, OS, selected surface and site configuration. A tab, application window and entire screen are not interchangeable audio sources. [S3][S4]
- Play a short section and ask the attendee to confirm both image and sound. Keep your microphone test separate from the media test.
- Stop capture when finished and check your microphone state before resuming conversation.
If no audio option appears for that surface, do not assume microphone permission will add it. Try an available audio-capable tab workflow or the linked-video path when appropriate. The browser controls and Screen Capture specification describe optional audio choices; they do not establish support across every current browser and OS combination. [S4]
Avoid capturing the meeting tab itself or all computer sound unless that is intentional and rehearsed. Returning the call’s own audio to participants can create feedback. Sharing a narrow content surface also reduces the chance of showing unrelated notifications or windows. [S4]
Share audio without showing the video
The reviewed web Share audio button checks desktop-sharing capability and a specific audio-support test: a non-mobile Chromium-based browser, or Electron on Windows. This is a source availability rule, not an independently tested support matrix. [S3]
When available, choose Share audio. If the helper appears, select Continue, choose the intended browser content and enable its audio option in the picker. Use Stop audio sharing when finished. [S3]
If ordinary screen sharing is already active, the reviewed flow shows a warning instead of starting a second audio-only capture. Decide whether you need audio alone or video plus audio, stop the previous share, then start the intended path. For video plus sound, restart screen sharing with its audio option when available. [S3]
The native app and mobile browser are separate clients. Use the mobile guide for the app’s screen-sharing entry point, then test internal media audio separately. A phone screen appearing at the receiver does not prove its application audio is included. [S3]
If it is silent, blocked or out of sync
| Symptom | Safe first check |
|---|---|
| Picture arrives through capture, but sound does not | Check the chosen surface and the audio option in the picker. Compare media sound separately from microphone sound. [S3][S4] |
| Sender’s linked video plays, another attendee’s does not | Check that attendee’s media access, external-video consent, player error and actual URL type. A sender-only login or local file is insufficient. [S1][S2] |
| YouTube says the video is unavailable | Check the player error. Private/missing content and owner restrictions can prevent embedded playback; choose permitted content rather than bypassing restrictions. [S5] |
| Playback does not start automatically | Browser autoplay policy can affect audible playback. Use the controls offered by the actual client and record the error; do not disable browser protections globally. [S4][S5] |
| Another person’s Share video is unavailable | Ask the current sharing owner to stop their video. The reviewed button prevents competing owners during active sharing. [S1] |
| Voice remains muted after a clip | Check the actual microphone control and ask the attendee to confirm speech. The reviewed shared player can mute local audio when its media sound is on. [S2] |
| Second display shows video but has no sound | Check the main meeting window first. The reviewed second-screen follower player deliberately stays muted. See multiple monitors. [S2] |
For developers embedding Jitsi, keep IFrame sharing events and noise-suppression behavior separate from this presenter workflow. Do not infer a public API command from an internal action name. For self-hosted Docker or Debian/Ubuntu deployments, inspect the installed release and served configuration before changing anything; this guide adds no server patch or capture-policy bypass.
Finish with a receiver check
Rehearse the path you will use with the actual browser/app and attendee device: start, picture, media sound, pause/seek where supported, stop, then microphone speech. If one receiver fails, compare another before treating it as a meeting-wide capture failure. Record versions and sanitized error text, without publishing private links or access tokens.
These are recommended checks, not completed media tests. New upstream audio reports do not make every sharing path defective or establish a released fix. Recheck this guide when player controls, browser capture options or the deployed Jitsi version changes.
Sources and limits
- [S1] Meet 11248 shared-video actions, URL/availability functions, dialog and owner-aware button.
- [S2] Same release: player selection, direct media source, playback/microphone/follower behavior and external-link confirmation/state.
- [S3] Audio availability, capture-flow guards, audio helper and English labels.
- [S4] Chrome capture controls, updated 29 September 2022, and Screen Capture Working Draft, 27 August 2026. Used for selection/audio principles, not an exhaustive support claim. Checked 28 October.
- [S5] YouTube player errors and Chrome autoplay policy, checked 28 October 2026. No provider, codec, browser, app, device or live meeting compatibility test claimed.