<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[ThinPikachu的博客]]></title><description><![CDATA[]]></description><link>https://blog.csdn.net/ThinPikachu</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; ThinPikachu]]></copyright><item><title><![CDATA[YUV数据大小与码率的关系解析]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/163497665</link><guid>https://blog.csdn.net/ThinPikachu/article/details/163497665</guid><author>ThinPikachu</author><pubDate>Wed, 05 Aug 2026 10:56:32 +0800</pubDate><description><![CDATA[一帧 1920×1080 的 YUV 数据大小并不是一个固定值，它完全取决于具体的（如 YUV420、YUV422、YUV444）以及（通常是 8-bit，也有 10-bit）。在最常见的这是视频压缩和流媒体中最常用的格式。Y 分量占满全分辨率，而 U、V 分量在水平和垂直方向上都减半。常用于广播电视和部分专业视频采集。Y 分量占满，U、V 分量在水平方向减半，垂直方向不变。无色彩降采样，常用于专业后期制作或高质量图像。Y、U、V 三个分量都是全分辨率。]]></description><category></category></item><item><title><![CDATA[对话式AI赋能智能设备的关键能力指标与技术演进]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/149253296</link><guid>https://blog.csdn.net/ThinPikachu/article/details/149253296</guid><author>ThinPikachu</author><pubDate>Thu, 10 Jul 2025 16:33:55 +0800</pubDate><description><![CDATA[近年来，随着生成式AI和实时交互技术的发展，基于语音交互的智能硬件应用迅速兴起。从最初的“听得到”（QoS时代），到“听得清、听得懂”（QoE时代），再到如今追求“听得心”（AI QoE时代）的跨模态、拟人化体验。QoS（Quality of Service）关注网络带宽、延迟、丢包、抖动等技术指标；而QoE（Quality of Experience）则关注用户的主观体验，如响应速度、易用性和满意度。]]></description><category></category></item><item><title><![CDATA[长参考帧LTR]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/148434003</link><guid>https://blog.csdn.net/ThinPikachu/article/details/148434003</guid><author>ThinPikachu</author><pubDate>Wed, 04 Jun 2025 20:10:02 +0800</pubDate><description><![CDATA[上图所示是引入 LTR 技术后的丢帧恢复策略，未发生弱网时仍然是正常的 I P P P 帧编码，只是会将其中的某些 P 帧标记为 LTR 帧（如图中的绿色 P 帧，以下称为 LTR 标记帧）。如果发生弱网中间的某个 P 帧（✖️ 标记）丢失，无法恢复，则接收端会请求发送端（编码器）利用 LTR 恢复，此时编码器会利用之前的已经确认收到的 LTR 标记帧做为参考编出一个 P 帧（图中红色 P 帧，以下被称为 LTR 恢复帧）。再者，在一个稳定的视频场景中，高质量的参考帧可以提高后续帧的图像质量。]]></description><category></category></item><item><title><![CDATA[为什么现在的视频会议或者低延迟直播都选择使用rtc而不是quic？]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/148340036</link><guid>https://blog.csdn.net/ThinPikachu/article/details/148340036</guid><author>ThinPikachu</author><pubDate>Fri, 30 May 2025 16:10:01 +0800</pubDate><description><![CDATA[QUIC 设计目标是“可靠传输”，即所有数据包都要送到，丢了就重传，顺序打乱要排序，这和 TCP 类似，如果频繁丢包，因为重传导致的延迟也会随之增加。而rtc，准确来说他是一个技术栈，包含了srtp/srtcp，ice, stun, sdp, opus, fec, nack, svc, 3a等多重协议，通过这些协议来实现端到端的实时媒体处理能力。本质上来说，定位不同。quic虽然集成了多路复用、0-RTT建连、TLS加密、拥塞控制，可靠传输等特性，但归根结底他是一个传输层的协议，是为了实现可靠传输的。]]></description><category></category></item><item><title><![CDATA[quic为什么没有被大规模应用？]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/148337858</link><guid>https://blog.csdn.net/ThinPikachu/article/details/148337858</guid><author>ThinPikachu</author><pubDate>Fri, 30 May 2025 14:52:24 +0800</pubDate><description><![CDATA[协议可识别内容DPI/防火墙/QOS能力明文HTTP所有内容完全识别、过滤、调度SNI、证书、部分元数据能识别域名、部分分类调度QUIC/HTTP3仅IP、端口、极少元数据只能粗略区分，无法精细识别4.]]></description><category></category></item><item><title><![CDATA[pip使用国内源下载]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/148171812</link><guid>https://blog.csdn.net/ThinPikachu/article/details/148171812</guid><author>ThinPikachu</author><pubDate>Fri, 23 May 2025 16:48:38 +0800</pubDate><description><![CDATA[无论是升级pip还是通过pip安装包，都可以通过制定国内源的方式加速下载。]]></description><category></category></item><item><title><![CDATA[MCP是什么？]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/147403279</link><guid>https://blog.csdn.net/ThinPikachu/article/details/147403279</guid><author>ThinPikachu</author><pubDate>Mon, 21 Apr 2025 21:53:53 +0800</pubDate><description><![CDATA[两片非常好的文章，值得学习。]]></description><category></category></item><item><title><![CDATA[centos安装libheif]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/147282800</link><guid>https://blog.csdn.net/ThinPikachu/article/details/147282800</guid><author>ThinPikachu</author><pubDate>Wed, 16 Apr 2025 17:34:03 +0800</pubDate><description><![CDATA[【代码】centos安装libheif。]]></description><category></category></item><item><title><![CDATA[HEIF、HEIC、JPG 和 PNG是什么？]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/147282294</link><guid>https://blog.csdn.net/ThinPikachu/article/details/147282294</guid><author>ThinPikachu</author><pubDate>Wed, 16 Apr 2025 17:31:37 +0800</pubDate><description><![CDATA[HEIF容器可支持其他编码方式（如AV1），但HEIC是当前主流实现。：HEIC 是 HEIF 的一种具体实现，专门使用 HEVC 编码。需要存储动态照片（Live Photos）或深度信息（人像模式）：HEIC特指使用HEVC（H.265）编码的HEIF文件。苹果设备的默认照片格式（节省存储空间）专业设计中的无损编辑（如PSD导出）专业摄影中的高效存储（如连拍序列）对文件大小敏感的场景（如网页加载）图表、文字截图（避免压缩伪影）需要透明背景的图标、Logo。通用照片存储（兼容性优先）]]></description><category></category></item><item><title><![CDATA[h265为什么没有大范围应用]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/147127492</link><guid>https://blog.csdn.net/ThinPikachu/article/details/147127492</guid><author>ThinPikachu</author><pubDate>Thu, 10 Apr 2025 21:11:00 +0800</pubDate><description><![CDATA[尽管 H.265 在技术上具有许多优势，如更高的压缩效率和更好的视频质量，但其大范围应用受到专利和许可费用、硬件支持、编码复杂度、竞争标准和生态系统兼容性等因素的限制。随着技术的发展和市场的变化，H.265 的应用可能会逐渐增加，但目前这些因素仍然是其广泛应用的主要障碍。虽然现代设备（如智能手机、平板电脑、电视和流媒体设备）逐渐增加了对 H.265 的硬件支持，但仍有许多旧设备不支持 H.265。此外，新的视频编码标准如 AV1 也在崛起，提供了与 H.265 相媲美的压缩效率，但没有专利费用问题。]]></description><category></category></item><item><title><![CDATA[python使用pip下载包文件]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/146396387</link><guid>https://blog.csdn.net/ThinPikachu/article/details/146396387</guid><author>ThinPikachu</author><pubDate>Thu, 20 Mar 2025 14:31:59 +0800</pubDate><description><![CDATA[会根据依赖关系的顺序安装这些文件，所以你不需要担心安装顺序的问题。文件，确保所有依赖项都正确安装。命令来下载包文件到指定目录。这将安装当前目录下所有的。]]></description><category></category></item><item><title><![CDATA[cmake和make的区别]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/146182282</link><guid>https://blog.csdn.net/ThinPikachu/article/details/146182282</guid><author>ThinPikachu</author><pubDate>Tue, 11 Mar 2025 16:23:06 +0800</pubDate><description><![CDATA[但如果源文件太多，一个一个编译时就会特别麻烦，于是人们想到，为什么不设计一种类似批处理的程序，来批处理编译源文件呢，于是就有了make工具，它是一个自动化编译工具，你可以使用一条命令实现完全编译。对于一个大工程，编写makefile实在是件复杂的事，于是人们又想，为什么不设计一个工具，读入所有源文件之后，自动生成makefile呢，于是就出现了cmake工具，它能够输出各种各样的makefile或者project文件,从而帮助程序员减轻负担。1.用编辑器编写源代码，如.c文件。可执行文件，如.exe。]]></description><category></category></item><item><title><![CDATA[configure make和make install]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/146182205</link><guid>https://blog.csdn.net/ThinPikachu/article/details/146182205</guid><author>ThinPikachu</author><pubDate>Tue, 11 Mar 2025 16:21:02 +0800</pubDate><description><![CDATA[make 的作用是开始进行源代码编译，以及一些功能的提供，这些功能由他的 Makefile 设置文件提供相关的功能，比如 make install 一般表示进行安装，make uninstall 是卸载，不加参数就是默认的进行源代码编译。make 是 Linux 开发套件里面自动化编译的一个控制程序，他通过借助 Makefile 里面编写的编译规范进行自动化的调用 gcc 、ld 以及运行某些需要的程序进行编译的程序。make是用来编译的，它从Makefile中读取指令，然后编译。（因为要向系统写入文件）]]></description><category></category></item><item><title><![CDATA[如何预防DDOS攻击]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/145652770</link><guid>https://blog.csdn.net/ThinPikachu/article/details/145652770</guid><author>ThinPikachu</author><pubDate>Sat, 15 Feb 2025 17:08:39 +0800</pubDate><description><![CDATA[其核心思想是将攻击流量引导到一个“黑洞”中，使其无法到达目标服务器，从而保护服务器和网络资源。]]></description><category></category></item><item><title><![CDATA[DNS劫持和HTTPDNS]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/145522558</link><guid>https://blog.csdn.net/ThinPikachu/article/details/145522558</guid><author>ThinPikachu</author><pubDate>Sat, 08 Feb 2025 20:39:49 +0800</pubDate><description><![CDATA[DNS 劫持是一种网络攻击手段，攻击者通过篡改域名系统（DNS）解析过程，将用户请求的域名重定向到恶意网站或其他不正确的地址。这种攻击可以用于多种目的，例如窃取用户数据、传播恶意软件或进行钓鱼攻击。]]></description><category></category></item><item><title><![CDATA[如何避免NACK重传风暴]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/145522437</link><guid>https://blog.csdn.net/ThinPikachu/article/details/145522437</guid><author>ThinPikachu</author><pubDate>Sat, 08 Feb 2025 20:29:55 +0800</pubDate><description><![CDATA[所以，如果没有 1、4 这两条 nack 保护策略，那么，当拉流用户很多的时候，上述两种场景会给服务器和端带来巨大的 cpu 性能损耗，并会引起 nack 网络风暴。其实，nack 的发送保护策略还有一条：收到一组连续且完整的帧之后，会立即对 nack_list 执行部分清空操作，避免无必要的再次重传请求，接下来的源码分析部分会进一步介绍这个策略。NACK 模块对同一包号的最大请求次数，超过这个最大次数限制，会把该包号移出 nack_list，放弃对该包的重传请求。]]></description><category></category></item><item><title><![CDATA[网络质量评估]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/145472248</link><guid>https://blog.csdn.net/ThinPikachu/article/details/145472248</guid><author>ThinPikachu</author><pubDate>Thu, 06 Feb 2025 14:04:22 +0800</pubDate><description><![CDATA[上述文章的弱网优化大多是基于HTTP请求即request和response角度来进行的，是否可以将这些优化经验或者模型应用到关于实时音视频传输的弱网优化中呢？我认为是可以的，因为在RTC中不仅仅可以通过音视频的传输指标来评估网络质量，还可以从信令角度来评估，而从信令的角度进行网络质量评估时，上述文章中的优化点就可以被参考了。关于google nqe代码分析的文章我几乎没找到，所以等自己后续有时间了，打算具体剖析一下nqe，看一下其网络质量评估和rtc中的网络质量评估有何不同？]]></description><category></category></item><item><title><![CDATA[srs和nginx的区别]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/145015291</link><guid>https://blog.csdn.net/ThinPikachu/article/details/145015291</guid><author>ThinPikachu</author><pubDate>Wed, 08 Jan 2025 19:12:40 +0800</pubDate><description><![CDATA[1. 功能不同：SRS 是专注于流媒体的应用服务器，提供了丰富的流媒体服务功能，例如录制、转码、推流、拉流、RTMP 推送和拉取、HLS/DASH/FLV 视频直播等。2. 架构不同：SRS 的架构是基于单进程多线程，采用了异步事件驱动的方式处理网络 IO，可以高效地处理大量的并发连接。SRS 使用 st (state-threads) 作为其核心事件驱动模型，st 是一个基于状态机的协程库，提供类似于线程的编程接口，但实际是协程实现，底层使用 epoll/kqueue 等事件驱动机制。]]></description><category></category></item><item><title><![CDATA[Adobe Flash，Flash Player和RTMP之间的关系]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/145015103</link><guid>https://blog.csdn.net/ThinPikachu/article/details/145015103</guid><author>ThinPikachu</author><pubDate>Wed, 08 Jan 2025 18:36:27 +0800</pubDate><description><![CDATA[Flash player是一款浏览网页上嵌入的Flash动画、视频的播放插件，而Adobe Flash是制作动画的软件，这两个的职能是不一样的，所以即使是废除了Flash Player以后也不影响Adobe Flash的使用。RTMP是Flash Player默认支持的流媒体传输协议，Flash Player内置了RTMP协议栈，可以直接播放RTMP流媒体，Flash开发的应用可以方便地使用RTMP进行实时音视频传输。总的来说，RTMP是为Flash开发的核心协议，两者在流媒体领域长期密切配合。]]></description><category></category></item><item><title><![CDATA[声音是如何产生的]]></title><link>https://blog.csdn.net/ThinPikachu/article/details/144908387</link><guid>https://blog.csdn.net/ThinPikachu/article/details/144908387</guid><author>ThinPikachu</author><pubDate>Fri, 03 Jan 2025 20:07:39 +0800</pubDate><description><![CDATA[RTMP中一般音频采用aac编码，采样率为44100HZ, 每帧1024采样，帧率43，23.2ms一帧RTC中一般音频采用opus编码，采样率为48000HZ，每帧480采样，帧率100，10ms一帧。]]></description><category></category></item></channel></rss>