morgan/UxPlay
1
0
Fork 0
mirror of https://github.com/morgan9e/UxPlay synced 2026-04-14 00:04:13 +09:00
Code Issues Packages Projects Releases Wiki Activity

update README about -vsync, -async options

Browse Source
This commit is contained in:
F. Duncanh
2023-04-19 21:34:41 -04:00
parent 6e11e749cc
commit 8c62dcd24c
3 changed files with 110 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
README.html
View File

@@ -355,14 +355,14 @@ gstreamer1-plugins, gstreamer1-plugins-* (* = core, good, bad, x, gtk,
gl, vulkan, pulse, v4l2, …), (+ gstreamer1-vaapi for Intel
graphics).</p></li>
</ul>
<h3 id="starting-uxplay">Starting UxPlay</h3>
<p><strong>Finally, run uxplay in a terminal window</strong>. On some
systems, you can toggle into and out of fullscreen mode with F11 or
(held-down left Alt)+Enter keys. Use Ctrl-C (or close the window) to
terminate it when done. If the UxPlay server is not seen by the iOS
client’s drop-down “Screen Mirroring” panel, check that your DNS-SD
server (usually avahi-daemon) is running: do this in a terminal window
with <code>systemctl status avahi-daemon</code>. If this shows the
<h3 id="starting-and-running-uxplay">Starting and running UxPlay</h3>
<p><strong>Run uxplay in a terminal window</strong>. On some systems,
you can toggle into and out of fullscreen mode with F11 or (held-down
left Alt)+Enter keys. Use Ctrl-C (or close the window) to terminate it
when done. If the UxPlay server is not seen by the iOS client’s
drop-down “Screen Mirroring” panel, check that your DNS-SD server
(usually avahi-daemon) is running: do this in a terminal window with
<code>systemctl status avahi-daemon</code>. If this shows the
avahi-daemon is not running, control it with
<code>sudo systemctl [start,stop,enable,disable] avahi-daemon</code> (on
non-systemd systems, such as *BSD, use
@@ -375,35 +375,48 @@ mDNS queries) needed by Avahi</strong>. See <a
href="#troubleshooting">Troubleshooting</a> below for help with this or
other problems.</p>
<ul>
<li><p>you may find video is improved by the setting -fps 60 that allows
some video to be played at 60 frames per second. (You can see what
framerate is actually streaming by using -vs fpsdisplaysink, and/or
-FPSdata.)</p></li>
<li><p>By default, UxPlay is locked to its current client until that
client drops the connection; since UxPlay-1.58, the option
<code>-nohold</code> modifies this behavior so that when a new client
requests a connection, it removes the current client and takes
over.</p></li>
<li><p>In its default mode, Uxplay uses a simple GStreamer mode
(“sync=false”) that streams without using audio- and video-timestamps
for synchronization. UxPlay 1.63 also introduces <code>-vsync</code> and
<code>-async</code> as alternatives that use timestamps in Mirror and
Audio-Only modes respectively (GStreamer’s “sync=true” mode). Simple
default streaming in Mirror mode seems to maintain synchronisation of
audio with video on desktop systems, but you may wish to use
<code>-vsync</code>, which becomes essential in low-powered systems like
Raspberry Pi if hardware video decoding is not used (<strong>and is
likely to become the default in future releases of UxPlay</strong>).
These options also allow an optional positive (or negative) audio-delay
adjustment in <em>milliseconds</em> for fine-tuning :
<code>-vsync 20.5</code> delays audio relative to video by 0.0205 secs;
a negative value advances it.)</p></li>
<li><p>The <code>-async</code> option should be used if you want video
on the client to be synchronized with Audio-Only mode audio on the
server (<em>e.g.</em> for viewing song lyrics in Apple music while
listening to ALAC loss-free audio on the server); this introduces a
slight delay for events like pausing audio, changing tracks,
<em>etc.</em>, to be heard.</p></li>
<li><p>In Mirror mode, GStreamer has a choice of <strong>two</strong>
methods to play video with its accompanying audio: the default mode
(“sync=false”) just plays both streams as soon as possible after they
arrive, and the (“sync=true”) mode used by the <code>-vsync</code>
option (first introduced in UxPlay-1.63), uses the timestamps in the
streams sent by the Airplay client to play audio and video frames
together at the correct time. For playing long video sequences on any
UxPlay server, use the -vsync option: this may become the default in
future UxPlay releases.</p></li>
</ul>
<p>Provided the UxPlay host can process the video sufficently fast, the
default “sync=false” mode seems to work well at keeping video and audio
synchronized, but on lower decoding-power systems (e.g. Raspberry Pi 3
Model B+), the -vsync option is definitely needed: this will drop video
frames that do not get decoded in time to match the audio, perhaps
making the video “jerky”, but keeping it synchronized with the
audio.</p>
<ul>
<li>In Audio-only mode the “sync=false” option is also the default, but
if you want to keep the audio playing on the server synchronized with
the video on the client, use the <code>-async</code> option. (An example
might be if you want to follow the Apple Music lyrics on the client
while listening to superior sound on the UxPlay server). This delays the
video on the client to match audio on the server, so leads to a slight
delay before a pause or track-change initiated on the client takes
effect on the audio played by the server.</li>
</ul>
<p>The -vsync and -async options also allow an optional positive (or
negative) audio-delay adjustment in <em>milliseconds</em> for
fine-tuning : <code>-vsync 20.5</code> delays audio relative to video by
0.0205 secs; a negative value advances it.)</p>
<ul>
<li><p>you may find video is improved by the setting -fps 60 that allows
some video to be played at 60 frames per second. (You can see what
framerate is actually streaming by using -vs fpsdisplaysink, and/or
-FPSdata.) When using this, you probably should use the -vsync
option.</p></li>
<li><p>Since UxPlay-1.54, you can display the accompanying “Cover Art”
from sources like Apple Music in Audio-Only (ALAC) mode: run
“<code>uxplay -ca &lt;name&gt; &amp;</code>” in the background, then run

38
README.md
View File

@@ -304,9 +304,9 @@ for Intel graphics).
(\* = core, good, bad, x, gtk, gl, vulkan, pulse, v4l2, ...), (+ gstreamer1-vaapi for Intel graphics).
### Starting UxPlay
### Starting and running UxPlay
**Finally, run uxplay in a terminal window**. On some systems, you can toggle into and out of fullscreen mode
**Run uxplay in a terminal window**. On some systems, you can toggle into and out of fullscreen mode
with F11 or (held-down left Alt)+Enter keys. Use Ctrl-C (or close the window)
to terminate it when done. If the UxPlay server is not seen by the
iOS client's drop-down "Screen Mirroring" panel, check that your DNS-SD
@@ -322,26 +322,34 @@ are opened: **if a firewall is active, also open UDP port 5353 (for mDNS queries
needed by Avahi**. See [Troubleshooting](#troubleshooting) below for
help with this or other problems.
* you may find video is improved by the setting -fps 60 that allows some video to be played at 60 frames
per second. (You can see what framerate is actually streaming by using -vs fpsdisplaysink, and/or -FPSdata.)
* By default, UxPlay is locked to
its current client until that client drops the connection; since UxPlay-1.58, the option `-nohold` modifies this
behavior so that when a new client requests a connection, it removes the current client and takes over.
* In its default mode, Uxplay uses a simple GStreamer mode ("sync=false") that streams without using audio- and
video-timestamps for synchronization. UxPlay 1.63 also introduces `-vsync` and `-async` as alternatives that use timestamps
in Mirror and Audio-Only modes respectively (GStreamer's "sync=true" mode).
Simple default streaming in Mirror mode seems to maintain synchronisation of audio with video on desktop systems,
but you may wish to use `-vsync`, which becomes essential in low-powered systems like Raspberry Pi if hardware
video decoding is not used (**and is likely to become the default in future releases of UxPlay**). These options
* In Mirror mode, GStreamer has a choice of **two** methods to play video with its accompanying audio: the default
mode ("sync=false") just plays both streams as soon as possible after they arrive, and the ("sync=true") mode
used by the `-vsync` option (first introduced in UxPlay-1.63), uses the
timestamps in the streams sent by the Airplay client to play audio and video frames together at the correct time.
For playing long video sequences
on any UxPlay server, use the -vsync option: this may become the default in future UxPlay releases.
Provided the UxPlay host can process the video sufficently fast, the default "sync=false" mode seems to work
well at keeping video and audio synchronized, but on lower decoding-power systems (e.g. Raspberry Pi 3 Model B+),
the -vsync option is definitely needed: this will drop video frames that do not get decoded in
time to match the audio, perhaps making the video "jerky", but keeping it synchronized with the audio.
* In Audio-only mode the "sync=false" option is also the default, but if you want to keep the audio playing on the server synchronized
with the video on the client, use the `-async` option. (An example might be if you want to follow the Apple Music lyrics on the client
while listening to superior sound on the UxPlay server). This delays the video on the client to match audio on the server, so leads to
a slight delay before a pause or track-change initiated on the client takes effect on the audio played by the server.
The -vsync and -async options
also allow an optional positive (or negative) audio-delay adjustment in _milliseconds_ for fine-tuning : `-vsync 20.5`
delays audio relative to video by 0.0205 secs; a negative value advances it.)
* The `-async` option should be used if you want
video on the client to be synchronized with Audio-Only mode audio on the server (_e.g._ for viewing song lyrics in Apple music
while listening to ALAC loss-free audio on the server); this introduces a slight delay for events like pausing audio,
changing tracks, _etc._, to be heard.
* you may find video is improved by the setting -fps 60 that allows some video to be played at 60 frames
per second. (You can see what framerate is actually streaming by using -vs fpsdisplaysink, and/or -FPSdata.)
When using this, you probably should use the -vsync option.
* Since UxPlay-1.54, you can display the accompanying "Cover Art" from sources like Apple Music in Audio-Only (ALAC) mode:
run "`uxplay -ca <name> &`" in the background, then run a image viewer with an autoreload feature: an example

73
README.txt
View File

@@ -352,14 +352,14 @@ installed, depending on how your audio is set up.
gtk, gl, vulkan, pulse, v4l2, ...), (+ gstreamer1-vaapi for Intel
graphics).
### Starting UxPlay
### Starting and running UxPlay
**Finally, run uxplay in a terminal window**. On some systems, you can
toggle into and out of fullscreen mode with F11 or (held-down left
Alt)+Enter keys. Use Ctrl-C (or close the window) to terminate it when
done. If the UxPlay server is not seen by the iOS client's drop-down
"Screen Mirroring" panel, check that your DNS-SD server (usually
avahi-daemon) is running: do this in a terminal window with
**Run uxplay in a terminal window**. On some systems, you can toggle
into and out of fullscreen mode with F11 or (held-down left Alt)+Enter
keys. Use Ctrl-C (or close the window) to terminate it when done. If the
UxPlay server is not seen by the iOS client's drop-down "Screen
Mirroring" panel, check that your DNS-SD server (usually avahi-daemon)
is running: do this in a terminal window with
`systemctl status avahi-daemon`. If this shows the avahi-daemon is not
running, control it with
`sudo systemctl [start,stop,enable,disable] avahi-daemon` (on
@@ -372,36 +372,47 @@ opened: **if a firewall is active, also open UDP port 5353 (for mDNS
queries) needed by Avahi**. See [Troubleshooting](#troubleshooting)
below for help with this or other problems.
- you may find video is improved by the setting -fps 60 that allows
some video to be played at 60 frames per second. (You can see what
framerate is actually streaming by using -vs fpsdisplaysink, and/or
-FPSdata.)
- By default, UxPlay is locked to its current client until that client
drops the connection; since UxPlay-1.58, the option `-nohold`
modifies this behavior so that when a new client requests a
connection, it removes the current client and takes over.
- In its default mode, Uxplay uses a simple GStreamer mode
("sync=false") that streams without using audio- and
video-timestamps for synchronization. UxPlay 1.63 also introduces
`-vsync` and `-async` as alternatives that use timestamps in Mirror
and Audio-Only modes respectively (GStreamer's "sync=true" mode).
Simple default streaming in Mirror mode seems to maintain
synchronisation of audio with video on desktop systems, but you may
wish to use `-vsync`, which becomes essential in low-powered systems
like Raspberry Pi if hardware video decoding is not used (**and is
likely to become the default in future releases of UxPlay**). These
options also allow an optional positive (or negative) audio-delay
adjustment in *milliseconds* for fine-tuning : `-vsync 20.5` delays
audio relative to video by 0.0205 secs; a negative value advances
it.)
- In Mirror mode, GStreamer has a choice of **two** methods to play
video with its accompanying audio: the default mode ("sync=false")
just plays both streams as soon as possible after they arrive, and
the ("sync=true") mode used by the `-vsync` option (first introduced
in UxPlay-1.63), uses the timestamps in the streams sent by the
Airplay client to play audio and video frames together at the
correct time. For playing long video sequences on any UxPlay server,
use the -vsync option: this may become the default in future UxPlay
releases.
- The `-async` option should be used if you want video on the client
to be synchronized with Audio-Only mode audio on the server (*e.g.*
for viewing song lyrics in Apple music while listening to ALAC
loss-free audio on the server); this introduces a slight delay for
events like pausing audio, changing tracks, *etc.*, to be heard.
Provided the UxPlay host can process the video sufficently fast, the
default "sync=false" mode seems to work well at keeping video and audio
synchronized, but on lower decoding-power systems (e.g. Raspberry Pi 3
Model B+), the -vsync option is definitely needed: this will drop video
frames that do not get decoded in time to match the audio, perhaps
making the video "jerky", but keeping it synchronized with the audio.
- In Audio-only mode the "sync=false" option is also the default, but
if you want to keep the audio playing on the server synchronized
with the video on the client, use the `-async` option. (An example
might be if you want to follow the Apple Music lyrics on the client
while listening to superior sound on the UxPlay server). This delays
the video on the client to match audio on the server, so leads to a
slight delay before a pause or track-change initiated on the client
takes effect on the audio played by the server.
The -vsync and -async options also allow an optional positive (or
negative) audio-delay adjustment in *milliseconds* for fine-tuning :
`-vsync 20.5` delays audio relative to video by 0.0205 secs; a negative
value advances it.)
- you may find video is improved by the setting -fps 60 that allows
some video to be played at 60 frames per second. (You can see what
framerate is actually streaming by using -vs fpsdisplaysink, and/or
-FPSdata.) When using this, you probably should use the -vsync
option.
- Since UxPlay-1.54, you can display the accompanying "Cover Art" from
sources like Apple Music in Audio-Only (ALAC) mode: run