Windows11 部署 LiveTalking 项目过程以及坑点

文章阅读前提条件以及背景需求告知
作者环境:
	1. 使用 conda 环境管理工具来配置 Python 相关环境
		- Python 版本为 Python 3.10.15
		- Pytorch 等需求版本请参考后续内容
		- CUDA 版本参考后续内容
	2. 电脑系统为 Windows11（无双系统）
项目作者环境
	1. 电脑系统 Ubuntu 20.04
	2. Python 版本 3.10, Pytorch 1.12 and CUDA 11.3

一、项目以及配置环境

提示：一定要仔细阅读作者在项目中的 README.md 文件；以及项目发布的 FQA 网址; 真的非常有用！！

1.1 拉取项目

不讲如何安装 git , 以及 git 的使用

直接使用命令 git clone https://github.com/lipku/LiveTalking.git 完成项目的拉取；

1.2 配置环境

提示:项目作者在环境部署的时候，采用的是 以下命令:
conda create -n nerfstream python=3.10
conda activate nerfstream
conda install pytorch==1.12.1 torchvision==0.13.1 cudatoolkit=11.3 -c pytorch
pip install -r requirements.txt

作者建议仅采用 conda 完成环境的创建, Pytorch 以及相关配置命令采用 pip 进行;
conda create -n nerfstream python=3.10
conda activate nerfstream

Python 环境部署完毕后，需要进行项目需求库的安装以及部署，此项目安装难点库在于 Pytorch、Numpy；
其中 Pytorch 的安装建议采用官方网站（魔法上网会快很多） https://pytorch.org/，本人使用的 Windows 版本使用如图，采用命令 pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124，此命令一般不会遇到什么问题，C编译失败的问题可以参考其他文章作者的处理方式，非常很详细，这篇文章就不赘述；

重点： 一定不要去盲目跟着项目作者完成项目的安装，除非你与项目作者一模一样的配置条件！
坑1： 另外我选择的是 CUDA 12.4 ，那么我就去下载 CUDA12.4 就行，Windows 中想要下载 CUDA11.3（即与作者配置相同的 CUDA版本），需要强行去修改 Pytorch 、Torch 以及 cudatoolkit 的版本，因为 CUDA 11.3 根本就不支持 Windows；

二、项目运行

此处是重点！！

在项目 README.md 中 2. Quick Start 部分提及到 默认采用ernerf模型，webrtc推流到srs 所以后续我们需要接入的其实是 webrtc；

2.1运行 SRS

根据项目作者的步骤，咱一步步来

export CANDIDATE='<服务器外网ip>'  #如果srs与浏览器访问在同一层级内网，不需要执行这步

docker run --rm --env CANDIDATE=$CANDIDATE \
  -p 1935:1935 -p 8080:8080 -p 1985:1985 -p 8000:8000/udp \
  registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5 \
  objs/srs -c conf/rtc.conf

这一步基本上没什么问题，正常都可以运行起来，进入下一步即可；

这里提一句，Windows 运行 docker 需要运用到 deocker-desktop 这个应用，这期间会遇到一些问题导致 docker 根本起不来，下面俩问题仅供参考
问题一：
docker-desktop 出现：Please try shutting WSL down (wsl --shutdown) and/or rebooting your computer … 错误
解决方案：

1. 管理员身份打开命令行工具
   1.1 可以此期间使用的命令：
   1.1.1 关闭 docker Help-v：bcdedit /set hypervisorlaunchtype off
   1.1.2 开启 docker Help-v：bcdedit /set hypervisorlaunchtype auto
2. 输入命令：netsh winsock reset
3. 重启电脑

问题二：
docker-desktop 出现： Docker Desktop-WSL distro terminated abruptly … an external entity terminating WSL (e.g. running wsl–shutdown) 错误
解决方案：

1. 列出已安装的 WSL 发行版 wsl --list
2. 注销 Docker 相关的发行版 wsl --unregister <distro_name>
   2.1 注意：注销发行版会删除所有相关的数据，所以在执行此命令之前，确认你已经备份了重要的数据或容器。
3. 重新启动计算机
4. 重启 docker

2.2 启动数字人

python app.py 如果访问不了huggingface（需要全局魔法上网），在运行前export HF_ENDPOINT=https://hf-mirror.com

到这一步其实就是完整的运行；但作者在运行到这一步的时候，发现 app.py 程序堆栈中显示 start http server; http://<serverip>:8010/rtcpushapi.html 但是此 html 的内容怎么点击都没反应！然后去检查 docker 输出！发现了一大堆乱七八糟的东西，简单的分析了一下，发现主要分为以下几个部分：

• RS 启动信息：
  • SRS/5.0.213(Bee) 表示正在运行的 SRS 版本。
  • MIT 表示 SRS 是一个开源软件，采用 MIT 许可证。
  • authors 列出了 SRS 的主要开发者和贡献者。
• 配置与环境信息：
  • build: 2024-06-15 和 configure: --sanitizer=off --gb28181=on 等详细配置项说明了 SRS 是如何构建和配置的。
  • uname: Linux buildkitsandbox 表示容器内运行的是 Linux 系统，具体是 Ubuntu 20.04。
• 网络与设备配置：
  • eth0 ipv4 0x11043 172.17.0.2：显示容器内的网络接口（eth0）的 IP 地址为 172.17.0.2。
  • stats network use index=0, ip=172.17.0.2 和 stats disk not configed, disk iops disabled 分别是网络和磁盘的状态。
  • 功能开启信息：
  • rch:on, dash:on, hls:on, srt:on 等显示 SRS 启用了多种流媒体功能，如 HLS（HTTP Live Streaming）和 SRT（Secure Reliable Transport）。
• 服务监听端口：
  • RTMP listen at tcp://0.0.0.0:1935 表示 RTMP 流媒体协议正在监听 1935 端口。
  • HTTP-API listen at tcp://0.0.0.0:1985 和 HTTP-Server listen at tcp://0.0.0.0:8080 表示 HTTP API 和 HTTP 服务器分别监听 1985 和 8080 端口。
  • rtc listen at udp://0.0.0.0:8000：RTC（Web Real-Time Communication）服务监听 8000 端口。
• 日志和连接管理：
  • Thread #2: run with tid=7, entry=0x55da7cb8a620 表示正在启动不同的线程来处理流媒体的工作。
  • CircuitBreaker: enabled=1, high=2x90, critical=1x95, dying=5x99 这是用于监控流媒体服务的断路器设置，帮助系统在负载过高时进行保护。
• RTC 会话信息：
  • 日志中显示了 RTC 会话的初始化过程，如音视频流的设置和 DTLS 加密。
  • RTC username=81093469:17UW 等显示了 RTC 流的基本信息，记录了会话和流媒体的相关参数。

总结：所有的网络监听都是正常的，但是为什么会访问不了呢？其实就是因为防火墙…关了就好了

然后继续排查代码，这块回顾本文章 二、项目运行 开头提到的重点，项目作者默认采用ernerf模型，webrtc推流到srs ，那为什么采用的是 rtcpushapi.html 呢，这块发现代码 app.py 中有段默认代码 parser.add_argument('--transport', type=str, default='rtcpush') # rtmp webrtc rtcpush ，此处是配置 app.py 启动时需要的相关参数，既然主要使用 webrtc 推送到 srs 那么我们就继续完成跟栈，步骤如下

1. 根据当前输出内容完成跟栈，发现当前输出是由 opt.transport 完成 ，而且只有当值为 rtmp 以及 rtcpush 才会切入到其他流，这样看来我们只需要找到 rtcpush 传输值的位置，并进行修改即可；
   2. 修改代码 parser.add_argument('--transport', type=str, default='rtcpush') # rtmp webrtc rtcpush 将默认流修改为 None，或者其他非 rtmp 以及 rtcpush 的值；再次运行 app.py 可以发现结果产生变化
   

接着在运行代码 app.py 就好了~
就到这里啦，感谢阅读~