Update Oryx.

i18n/en-us/docusaurus-plugin-content-blog/2022-05-16-Load-Balancing-Streaming-Servers.md

@@ -68,7 +68,7 @@ Network bandwidth, whether it is overloaded, is considered over the following cr
 
 Disk, related to video recording, log splitting and STW problems caused by a slow disk :
 
-* When there are multiple streams that require recording, disk will become the most critical bottleneck since it’s the slowest device. When designing a system, consideration must be given to address such problems. For example, a server has 64GB RAM. 32GB of RAM can be allocated to streaming service as temporary storage for media files. Another solution when having a small disk, is to use external  services such as nodejs,   with multithreading enabled, and then copy or store the files to the cloud storage. Please refer to [oryx](https://github.com/ossrs/oryx) for the best practices.
+* When there are multiple streams that require recording, disk will become the most critical bottleneck since it’s the slowest device. When designing a system, consideration must be given to address such problems. For example, a server has 64GB RAM. 32GB of RAM can be allocated to streaming service as temporary storage for media files. Another solution when having a small disk, is to use external  services such as nodejs,   with multithreading enabled, and then copy or store the files to the cloud storage. Please refer to [Oryx](https://github.com/ossrs/oryx) for the best practices.
 * Server logs, abnormal situations might lead to large quantities of writing operations to log files. If not being divided and rotated properly, the size of log files will gradually increase, and eventually take up the entire disk space. SRS supports log-rotate, and docker allows setup with log-rotate too. The logs are usually extracted (the entire raw log can be extracted if there is not much), and sent to cloud-hosted log service for analysis. Local logs are only kept for a short period, e.g. 15 days.
 * STW (Stop The World) issue. The write operations cause congestion and other disk operations are queued until the write operation completes. Especially when a network disk, such as a NAS, is mounted as a local drive. Then when the server performs data write operations, there are in fact many operations happening at the network layer,  which consequently causes more delay. SRS servers should avoid using network disks completely, because each congestion will lead to a STW situation on a server and all other requests will be queued.
 
@@ -94,7 +94,7 @@ Let's talk about the load and overload conditions in SRS:
 
 * SRS’s process. When the CPU usage exceeds 100%, overload happens. SRS has a single-process design, hence it cannot take advantage of multiple CPUs (which will be elaborated in the later section).
 * Network bandwidth. It is usually the first resource that reaches overload. For example, CPU may still have a lot of free source, when the bandwidth throughput reaches 1Gbps in live streaming. RTC is slightly different, as it is computationally intensive too.
-* Disk. Except when recording is only needed for very few streams, it is generally necessary to avoid disk usage so as to avoid consequent problems. Instead we could mount RAM-drives, or reduce the number of streams processed by each SRS. Please refer to [oryx](https://github.com/ossrs/oryx) for best practices.
+* Disk. Except when recording is only needed for very few streams, it is generally necessary to avoid disk usage so as to avoid consequent problems. Instead we could mount RAM-drives, or reduce the number of streams processed by each SRS. Please refer to [Oryx](https://github.com/ossrs/oryx) for best practices.
 * Memory. It is generally less used, but we still care about the number of streams for some specific cases. For example, in case of CCTV monitoring when constant pushing and disconnecting happens, it is necessary to pay continuous attention to the increasing memory consumption by SRS. This issue can be circumvented by [Gracefully Quit](https://github.com/ossrs/srs/issues/413#issuecomment-917771521).
 
 Special note for SRS single-process design. This is actually a choice. It is a trade-off for performance optimization. On one hand, multiprocessing can improve the processing capability. On the other hand, it is at the expense of increasing complexity of the system. Moreover it is hard to evaluate the overall load. For instance,  what is an 8-core multiprocessing streaming server’s CPU overload threshold? Is it 640%? No, because the processes are not evenly consuming CPU resources.  To even the process-consumption, we must implement process load balancing scheme, which is a more complicated problem.

i18n/en-us/docusaurus-plugin-content-blog/2023-03-07-Lets-Do-H265-Live-Streaming.md

@@ -79,7 +79,7 @@ Part 5, other features for H.265.
 * [x] Black box test support HEVC.
 * [x] Patch FFmpeg in SRS dev-docker.
 * [x] Support HEVC for [WordPress plugin SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer).
-* [ ] Not supported: Update [oryx](https://github.com/ossrs/oryx) for HEVC.
+* [ ] Not supported: Update [Oryx](https://github.com/ossrs/oryx) for HEVC.
 * [ ] Not supported: Edge server supports publish HEVC stream to origin.
 * [ ] Not supported: Edge server supprots play HEVC stream from origin.
 * [ ] Not supported: HTTP Callback takes HEVC metadata.

i18n/en-us/docusaurus-plugin-content-docs/current/doc/introduction.md

@@ -133,7 +133,7 @@ FFmpeg, OBS, VLC, and WebRTC. SRS collaborates with these communities and uses t
 In addition to the SRS server, they also work on Oryx and WordPress plugins, with the main goal of creating 
 simpler application methods for different industries, including:
 
-* [oryx](https://github.com/ossrs/oryx): Oryx(SRS Stack) is an out-of-the-box, single-machine video cloud solution that includes FFmpeg and SRS. It's designed for users who aren't familiar with command lines and allows them to set up audio and video applications through Tencent Cloud images or BaoTa with mouse operations.
+* [Oryx](https://github.com/ossrs/oryx): Oryx(SRS Stack) is an out-of-the-box, single-machine video cloud solution that includes FFmpeg and SRS. It's designed for users who aren't familiar with command lines and allows them to set up audio and video applications through Tencent Cloud images or BaoTa with mouse operations.
 * [WordPress-Plugin-SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer): This plugin is for the publishing industry, such as personal blogs and media websites, making it easy for users to utilize audio and video capabilities.
 * [srs-unity](https://github.com/ossrs/srs-unity): This project is for the gaming industry, integrating Unity's WebRTC SDK to use audio and video capabilities.
 

i18n/zh-cn/docusaurus-plugin-content-blog/2022-05-16-Load-Balancing-Streaming-Servers.md

@@ -67,7 +67,7 @@ custom_edit_url: null
 
 磁盘，主要涉及的是流的录制，日志切割，以及慢磁盘导致的STW问题：
 
-* 若需要录制的流较多，磁盘作为最慢的设备，会明显成为瓶颈。一般在系统设计时，就需要避免这种情况，比如64GB内存的服务器，可以分32GB的内存盘，给流媒体服务器写临时文件。或者使用较小的内存盘，用外部的程序比如nodejs，开启多线程后，将文件拷贝到存储或发送到云存储，可以参考[oryx](https://github.com/ossrs/oryx)的最佳实践。
+* 若需要录制的流较多，磁盘作为最慢的设备，会明显成为瓶颈。一般在系统设计时，就需要避免这种情况，比如64GB内存的服务器，可以分32GB的内存盘，给流媒体服务器写临时文件。或者使用较小的内存盘，用外部的程序比如nodejs，开启多线程后，将文件拷贝到存储或发送到云存储，可以参考[Oryx](https://github.com/ossrs/oryx)的最佳实践。
 * 服务器的日志，在一些异常情况下，可能会造成大量写入，另外如果持续累计不切割和清理，会导致日志文件越来越大，最终写满磁盘。SRS支持logrotate，另外docker一般也可以配置logrotate，一般会将日志做提取后（日志少可以直接采集原始日志），传输到云的日志服务做分析，本地只需要存储短时间比如15天日志。
 * STW问题，写磁盘是阻塞操作，特别是挂的网络磁盘比如NAS，挂载到本地文件系统，而服务器在调用write写入数据时，实际上可能有非常多的网络操作，那么这种其实会更消耗时间。SRS目前应该完全避免挂载网络磁盘，每次阻塞都会导致整个服务器STW（世界暂停）不能处理其他请求。
 
@@ -93,7 +93,7 @@ custom_edit_url: null
 
 * SRS的进程，若CPU若超过100%，则过载。SRS是单线程设计，无法使用多个CPU的能力（这个后面我详细展开讲讲）。
 * 网络带宽，一般是最快达到过载的资源，比如直播中达到1Gbps吞吐带宽时可能CPU还很空闲，RTC由于同时是计算密集型，稍微有些差异。
-* 磁盘，除了非常少的路数的流的录制，一般需要规避磁盘问题，挂载内存盘，或者降低每个SRS处理的流的路数。参考[oryx](https://github.com/ossrs/oryx)的最佳实践。
+* 磁盘，除了非常少的路数的流的录制，一般需要规避磁盘问题，挂载内存盘，或者降低每个SRS处理的流的路数。参考[Oryx](https://github.com/ossrs/oryx)的最佳实践。
 * 内存，一般是使用较少的资源，在流路数特别特别，比如监控场景不断推流和断开的场景，需要持续关注SRS的内存上涨。这个问题可以通过[Gracefully Quit](https://github.com/ossrs/srs/issues/413#issuecomment-917771521)规避。
 
 特别说明下SRS单线程的问题，这其实是个选择，没有免费的性能优化，多线程当然能提升处理能力，同时是以牺牲系统的复杂度为代价，同时也很难评估系统的过载，比如8核的多线程的流媒体服务器CPU多少算是过载？640%？不对，因为可能每个线程是不均匀的，要实现线程均匀要做线程的负载调度，这又是更复杂的问题。

i18n/zh-cn/docusaurus-plugin-content-blog/2023-03-07-Lets-Do-H265-Live-Streaming.md

@@ -86,7 +86,7 @@ H.265的收益就不用说了，可以用更少的带宽，传输同样的质量
 * [x] 原生支持：黑盒测试支持HEVC。
 * [x] 原生支持：SRS镜像支持补丁的FFmpeg。可以不用自己编译FFmpeg，使用SRS镜像提供的FFmpeg即可。
 * [x] 原生支持：[WordPress plugin SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer)插件支持HEVC。由于Oryx使用的是4.0稳定版本，还需要几年才能切换到6.0。
-* [ ] 不支持：Update [oryx](https://github.com/ossrs/oryx) for HEVC.
+* [ ] 不支持：Update [Oryx](https://github.com/ossrs/oryx) for HEVC.
 * [ ] 不支持：Edge server supports publish HEVC stream to origin.
 * [ ] 不支持：Edge server supprots play HEVC stream from origin.
 * [ ] 不支持：HTTP Callback takes HEVC metadata.

i18n/zh-cn/docusaurus-plugin-content-docs/current/doc/introduction.md

@@ -109,7 +109,7 @@ SRS不做客户端，因为无论是FFmpeg，还是OBS，还是VLC，还是WebRT
 
 除了SRS服务器，我们还在做Oryx，还有WordPress插件等等，主要的目标还是根据不同行业，做出更简单的应用方式，包括：
 
-* [oryx](https://github.com/ossrs/oryx) Oryx或Oryx，是一个开箱即用的单机的视频云，里面有FFmpeg和SRS等，主要是方便不会命令行的用户，直接通过腾讯云镜像或者宝塔，鼠标操作，就可以把音视频的应用搭起来。
+* [Oryx](https://github.com/ossrs/oryx) Oryx或SRS Stack，是一个开箱即用的单机的视频云，里面有FFmpeg和SRS等，主要是方便不会命令行的用户，直接通过腾讯云镜像或者宝塔，鼠标操作，就可以把音视频的应用搭起来。
 * [WordPress-Plugin-SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer) 出版领域，比如个人博客、网站传媒等，方便用户可以使用音视频的能力。
 * [srs-unity](https://github.com/ossrs/srs-unity) 游戏领域，对接Unity的WebRTC SDK，使用音视频的能力。
 

i18n/zh-cn/docusaurus-plugin-content-docs/version-5.0/doc/introduction.md

@@ -120,7 +120,7 @@ SRS不做客户端，因为无论是FFmpeg，还是OBS，还是VLC，还是WebRT
 
 除了SRS服务器，我们还在做Oryx，还有WordPress插件等等，主要的目标还是根据不同行业，做出更简单的应用方式，包括：
 
-* [oryx](https://github.com/ossrs/oryx) Oryx或Oryx，是一个开箱即用的单机的视频云，里面有FFmpeg和SRS等，主要是方便不会命令行的用户，直接通过腾讯云镜像或者宝塔，鼠标操作，就可以把音视频的应用搭起来。
+* [Oryx](https://github.com/ossrs/oryx) Oryx或SRS Stack，是一个开箱即用的单机的视频云，里面有FFmpeg和SRS等，主要是方便不会命令行的用户，直接通过腾讯云镜像或者宝塔，鼠标操作，就可以把音视频的应用搭起来。
 * [WordPress-Plugin-SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer) 出版领域，比如个人博客、网站传媒等，方便用户可以使用音视频的能力。
 * [srs-unity](https://github.com/ossrs/srs-unity) 游戏领域，对接Unity的WebRTC SDK，使用音视频的能力。
 

i18n/zh-cn/docusaurus-plugin-content-pages/faq.md

@@ -350,7 +350,7 @@ will be removed without any response.
 ```
 
 ```
-Oryx的问题，请提交到[oryx](https://github.com/ossrs/oryx)，该Issue会被删除，请先阅读FAQ：#2716
+Oryx的问题，请提交到[Oryx](https://github.com/ossrs/oryx)，该Issue会被删除，请先阅读FAQ：#2716
 ```
 
 ![](https://ossrs.net/gif/v1/sls.gif?site=ossrs.net&path=/lts/pages/faq-zh)

versioned_docs/version-5.0/doc/introduction.md

@@ -126,7 +126,7 @@ FFmpeg, OBS, VLC, and WebRTC. SRS collaborates with these communities and uses t
 In addition to the SRS server, they also work on Oryx and WordPress plugins, with the main goal of creating
 simpler application methods for different industries, including:
 
-* [oryx](https://github.com/ossrs/oryx): Oryx(SRS Stack) is an out-of-the-box, single-machine video cloud solution that includes FFmpeg and SRS. It's designed for users who aren't familiar with command lines and allows them to set up audio and video applications through Tencent Cloud images or BaoTa with mouse operations.
+* [Oryx](https://github.com/ossrs/oryx): Oryx(SRS Stack) is an out-of-the-box, single-machine video cloud solution that includes FFmpeg and SRS. It's designed for users who aren't familiar with command lines and allows them to set up audio and video applications through Tencent Cloud images or BaoTa with mouse operations.
 * [WordPress-Plugin-SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer): This plugin is for the publishing industry, such as personal blogs and media websites, making it easy for users to utilize audio and video capabilities.
 * [srs-unity](https://github.com/ossrs/srs-unity): This project is for the gaming industry, integrating Unity's WebRTC SDK to use audio and video capabilities.