diff --git a/plans/onvif-reolink.md b/plans/onvif-reolink.md
index f4573960..78d14df6 100644
--- a/plans/onvif-reolink.md
+++ b/plans/onvif-reolink.md
@@ -146,4 +146,6 @@ Input/control implementation:
 ## NEW UI STUFF
 - desktop:
   - sidebar like there is now
-  - 
\ No newline at end of file
+  - replay panel in sidebar
+  - better indicators of light and OR modes
+  - list of controls using keybind things
\ No newline at end of file
diff --git a/server/src/services/ptzCameraService/index.js b/server/src/services/ptzCameraService/index.js
index cd0ab3ef..cc26a682 100644
--- a/server/src/services/ptzCameraService/index.js
+++ b/server/src/services/ptzCameraService/index.js
@@ -276,11 +276,10 @@ function startPublisher() {
     driven live. Sliced threads allow x264 to keep some parallelism without
     waiting on future frames the way normal frame-threading can.
 
-    The RTSP and muxer flags below bias the whole pipeline toward "latest frame
-    wins". If the server falls behind, ffmpeg should discard stale video frames
-    instead of spending CPU to render a delayed backlog. That matters more for
-    PTZ control than perfect frame delivery because delayed motion feedback makes
-    the camera hard to aim.
+    Keep RTSP demuxing conservative here. More aggressive "drop stale frames"
+    flags caused this camera stream to freeze after running for a while, so the
+    safer latency knob is to keep the encoder light and avoid building delay
+    inside x264 itself.
   */
   const proc = spawn('ffmpeg', [
     '-hide_banner',
@@ -289,26 +288,12 @@ function startPublisher() {
     '-nostdin',
     '-fflags',
     'nobuffer',
-    '-avioflags',
-    'direct',
     '-flags',
     'low_delay',
-    '-use_wallclock_as_timestamps',
-    '1',
-    '-max_delay',
-    '0',
-    '-probesize',
-    '32768',
-    '-analyzeduration',
-    '0',
     '-rtsp_transport',
     'tcp',
     '-i',
     input,
-    '-frame_drop_threshold',
-    '1',
-    '-fps_mode',
-    'drop',
     '-map',
     '0:v:0',
     '-map',