RTSP Stream Jumpy/Stutters

[chevyman142000]

Hello! Myself and it looks like a few other users are seeing jumpy/stuttery video from docker-wyze-bridge. When I view the video in the web interface, it is totally fine. When I watch the RTSP stream via VLC or in Homekit via Scrypted it is jumpy. However, recorded video in Homekit is smooth. I have 4 cameras total, 3 V3 and 1 V2. Wondering if this is an issue you are aware of and working on and if there are any settings I could potentially change to help this. I have it running in Docker on my Synology NAS, same with Scrypted. Let me know what other information I can provide. Thank you for the help!

[mrlt8]

Hmm. I wonder if this could be a potential issue with the raw h264 frames from the camera? To minimize overhead the bridge will copy the raw h264 frames from the camera and pipe them into the rtsp stream. Does forcing the bridge to re-encode the stream make any difference:

- H264_ENC=libx264

[chevyman142000]

I have added this variable and will see if I notice any improvement. Thanks!

[anderfrank]

I checked the feed via VLC before and after adding this setting and it did not seem to make a difference.

[mrlt8]

My bad. H264_ENC only works if you have rotation enabled. Added a new FORCE_ENCODE option that should re-encode the video. Please let me know if this helps.

[anderfrank]

Seems to be better with FORCE_ENCODE=True enabled. I only see it stutter maybe once every 15-20 seconds or so, but that could just be my wifi. Thanks!

[cturra]

i was experiencing a similar issue and adding FORCE_ENCODE=true resolved it for me! the only downside to this, as would be expected, is the amount of CPU cycles required for ffmpeg to do re-encoding of the video. in my case this isn't an issue, i have loads of spare system resources, but if you're going to run this on a smaller machine, like a pi, this could be an issue.

[mrlt8]

@cturra you can change the encoder to use hardware acceleration: https://github.com/mrlt8/docker-wyze-bridge/wiki/Hardware-Acceleration

[cturra]

💥 that's awesome! i hadn't caught the hardware acceleration capability. updating my docker-compose file to the following got me sorted, at least from a resource usage perspective. what might be the best way to verify all the hw encoding is in fact working correctly?

  wyze-bridge-hw:
    container_name: wyze-bridge-hw
    restart: unless-stopped
    image: mrlt8/wyze-bridge:latest-hw
    ports:
      - 1935:1935 # RTMP
      - 8554:8554 # RTSP
      - 8888:8888 # HLS
      - 8889:8889 #WebRTC
      - 8189:8189/udp # WebRTC/ICE
      - 5000:5000 # WEB-UIi
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=compute,video,utility
      - H264_ENC=h264_nvenc
      - WYZE_EMAIL=<REDACTED>
      - WYZE_PASSWORD=<REDACTED>

here is an example of one of my ffmpeg processes:

ffmpeg -loglevel error -fflags +genpts+flush_packets+nobuffer+bitexact -flags +low_delay -thread_queue_size 64 -threads 1 -analyzeduration 50 -probesize 50 -f H264 -i pipe: -flags +global_header -c:v copy -movflags +empty_moov+default_base_moof+frag_keyframe -muxdelay 0 -muxpreload 0 -map 0:v -f tee [f=rtsp:rtsp_transport=tcp:bsfs/v=dump_extra=freq=keyframe]rtsp://0.0.0.0:8554/spare-cam

nvidia-smi is not reporting any running processes, which has me suspicious, so i want to be certain.

[mrlt8]

I think you'll also need to set FORCE_ENCODE=True.

[cturra]

you were right! and i also needed to update my nvidia drivers to be using CUDA version: 12.0. now i see each camera stream in nvidia-smi.

final docker-compose, for anyone following along:

  wyze-bridge-hw:
    container_name: wyze-bridge-hw
    restart: unless-stopped
    image: mrlt8/wyze-bridge:latest-hw
    ports:
      - 1935:1935 # RTMP
      - 8554:8554 # RTSP
      - 8888:8888 # HLS
      - 8889:8889 # WebRTC
      - 8189:8189/udp # WebRTC/ICE
      - 5000:5000 # WEB-UI
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=compute,video,utility
      - H264_ENC=h264_nvenc
      - FORCE_ENCODE=True
      - WYZE_EMAIL=<REDACTED>
      - WYZW_PASSWORD=<REDACTED>

... in my case i have a EVGA GeForce GTX 1060 SC and each stream uses 109MiB of GPU memory and about 1% GPU utilization.

[chevyman142000]

I never thought of using hardware acceleration for this. Any chance I could do this on my Synology NAS? This is what I had to use to enable hardware transcoding for Plex on it, do you think this would work for docker-wyze-bridge as well?

devices:

• /dev/dri:/dev/dri

[mrlt8]

Intel? Any chance H264_ENC=h264_qsv works? You may need to try a custom ffmpeg command until we can figure out something that works:

- FFMPEG_CMD=ffmpeg -loglevel verbose -f h264 -hwaccel qsv -hwaccel_output_format qsv -i - -c:v h264_qsv -rtsp_transport tcp -f rtsp rtsp://0.0.0.0:8554/{cam_name}

[exiva]

I assume to get gpu acceleration on a macOS host you'd have to not use docker and run bridge natively?

[mrlt8]

Hmm I believe h264_videotoolbox would work on macOS but I don't think any of the ffmpeg encoders we're using have videotoolbox enabled.

[exiva]

Did more digging, it seems that wouldn't work anyway. Can't pass the iGPU to docker's VM on macOS. Will start a new ticket about a native install option for mac hosts and stop hijacking this one.