- 博客(166)
- 收藏
- 关注
原创 从零写一个ALSA声卡驱动学习(1)
不过,至少 ALSA 的内核 API 是一致的,因此本文档在编写这些驱动时仍然具有一定的参考价值。“card” 记录是声卡的核心管理结构,它负责管理该声卡上的所有设备(组件),例如 PCM、混音器(Mixer)、MIDI、合成器等。虽然 Linux 系统本身有标准的 i2c 层,但某些声卡只需要简单的操作,而标准的 i2c API 过于复杂,因此 ALSA 对某些声卡实现了自己的 i2c 代码。在 snd_mychip_probe() 函数中的注释行里标注的数字,对应的是下一节中将详细解释的内容。
2025-06-08 00:01:07
872
原创 RTMP协议基本介绍
当与可靠的传输协议如[TCP]一起使用时,RTMP块流提供了所有消息的保证有序端到端传递,这些消息跨越多个流,并且按照时间戳排序。例如,一个直播视频服务器可能会选择丢弃慢速客户端的视频消息,以确保音频消息能够及时接收,这基于发送每个消息所需的时间或确认每个消息所需的时间。除此之外,就RTMP块流而言,这是一个不透明的值。这篇备忘录描述了实时消息传输协议块流(RTMP块流),这是一种为多路复用和打包多媒体传输流(如音频、视频和交互式内容)而设计的应用程序级协议,它通过合适的传输协议(如TCP)进行传输。
2025-06-07 20:11:27
480
原创 rtp接收端,怎么解包rtp数据包?
如果检测到 DPA 丢失(在考虑了可能的重传和前向纠错(FEC)后),网关可以决定不发送对应的编码片段数据分区 B 和 C,因为对于 H.264 解码器来说,这些分区在没有 DPA 的情况下已经没有意义。如果发现某个 FU 丢失,网关可以决定不发送同一被片段化的 NAL 单元的后续 FU,因为在前面部分丢失的情况下,后续部分对 H.264 解码器已经无意义。对于所有包含同一个 NAL 单元片段的FU-A 包,去封装时,需要按照发送顺序将这些片段拼接起来,恢复成完整的 NAL 单元,再将其传递给解码器。
2025-04-20 11:29:47
360
原创 rtp三种模式传输打包规则:single nalu、non-interleaved、non-interleaved
禁止使用 STAP(单时间聚合包)、MTAP(多时间聚合包)和 FU(分片单元)。● 对于属于同一编码图像(coded picture)的编码切片 NAL 单元(coded slice NAL units)或编码切片数据分区 NAL 单元(coded slice data partition NAL units)(即它们共享相同的 RTP 时间戳), 可以(MAY)以任意顺序发送;序列参数集和图像参数集的 NAL 单元可以被复制,以提高其正确接收的概率,但是,这种复制绝不能改变任何活动参数集的内容。
2025-04-19 16:19:11
750
原创 rtp载荷结构类型:单一NAL单元包、聚合包、分片单元
对于聚合包(Aggregation packets,如 STAP 和 MTAP),RTP 头部中的标记位必须设定为:如果聚合包中最后一个 NAL 单元单独传输时所应具有的标记位的值。例如,在视频编码 profile 允许任意片段顺序(arbitrary slice order)的情况下,同一编码图像的所有编码片段的 NAL 单元可以使用相同的 DON 值。发送端不应发送这些类型的NAL单元(无论是直接作为载荷,还是作为聚合包中的聚合单元,亦或是FU分片包中的分片单元),接收端必须忽略这些类型的NAL单元。
2025-04-12 23:58:25
616
原创 RTP Payload Format for H.264 Vide(1)
● 编码视频序列(coded video sequence):按解码顺序排列的访问单元序列,由一个瞬时解码刷新(IDR)访问单元开始,后面跟着零个或多个非IDR访问单元,直到下一个IDR访问单元(不包括该IDR单元)为止。但在存在错误或丢包的码流中,冗余编码图像的内容可用于解码处理。● 默认子配置(default sub-profile):编码工具的子集,可以是一个profile的全部编码工具,也可以是多个profile共有的编码工具子集,由 profile-level-id 参数指示。
2025-04-09 22:07:17
833
1
原创 rnn的音频降噪背后技术原理
这是一个传统噪声抑制算法的概念图示。2、避免“音乐噪声(musical noise)”伪影: 所谓音乐噪声,是指噪声抑制时只让一个频点通过,而旁边的频点被强烈压制,从而产生类似“哒哒哒”或“嗡嗡嗡”的金属感杂音。如果使用较宽的频带,我们要么让整段频带通过,要么整体压制,这样就不会留下孤立的频点,从而避免这种伪影。此外,我们的目标也和很多使用深度学习做语音降噪的研究不同: 我们关注的是实时通信,而不是语音识别。顾名思义,它的核心思想是:从一个带噪声的信号中尽可能去除噪声,同时对其中的语音内容造成最小的失真。
2025-04-02 19:59:32
672
原创 opus编码控制参数
opus介绍:本文档定义了Opus交互式语音与音频编解码器。Opus专为广泛的实时音频应用场景设计,包括IP语音(VoIP, Voice over IP)、视频会议、游戏内语音聊天,甚至实时分布式音乐演出。其支持的码率范围从6 kbit/s的低比特率窄带语音到510 kbit/s的高质量立体声音乐。Opus结合线性预测(Linear Prediction, LP)与改进的离散余弦变换(Modifi...
2025-02-16 16:02:06
882
原创 v4l2 controls底层控制功能到底怎么实现?
一、v4l2 controls介绍:V4L2 控制 API 看起来足够简单,但在驱动程序中正确实现时会变得非常困难。然而,处理控制所需的大部分代码实际上并非特定于驱动程序,可以移到 V4L2 核心框架中 。毕竟,驱动开发者关心的唯一部分是:● 1、我如何添加一个控制?● 2、我如何设置控制的值?(即 s_ctrl)偶尔还会有:● 1、我如何获取控制的值?(即 g_volatile_ctrl)● 2...
2025-01-24 12:15:41
721
原创 2024的大变局之年!
前言:大家好,转眼间就到了2025,真的是越长大,时间过得越来越快,快的让人无法喘息呀!回顾2024,不管是个人还是整个社会来说,都是一个新的大变局,那就是ai的横空出世,这里的"横空出世"更加具有影响力,包括学习、生活等各方面都产生了颠覆性的改变,再次让生产力得到了极大提高,但是也会加快对"低端、机械重复"很多产业的淘汰,这也会带来一些问题!但是这都改变不了2024-ai的大浪潮来袭,以及未来的...
2025-01-04 13:23:39
600
原创 rk3568之mpp开发笔记记录之摄像头实时码流获取的神秘面纱
前言:大家好,在上一篇文章里面,我给大家解读了怎么获取imx415-sensor的实时码流的细节,今天开始会解析里面到底是怎么实现的?提前透露一点,整个摄像头驱动框架和上层调用,都会涉及到v4l2的开发使用,所以对于v4l2的掌握非常重要。mpp编码器框架执行流程:整个mpp单路码流测试源码,我们从下面这个接口mpi_enc_test开始解读,一步一步来学习里面的原理和实现:下面是整个代码的执行流...
2024-12-29 13:35:39
1085
原创 rk3568之mpp开发笔记怎么实现mpp编码摄像头实时码流?
前言:大家好,今天给大家分享的内容是在rk3568上,通过mpp来进行实时对摄像头imx415采集的码流数据进行编码成h264或者h265,后期文章,会开发测试一下通过rtsp推流出去,然后电脑端拉流,看一下整个环路的延迟多大,会采用slice的方式去进行编码,mpp编码器有类似的配置。ok,我们开始今天的内容!怎么找到摄像头视频节点?首先要明白为啥要找到摄像头的视频节点,毫无疑问,上层要能够访问...
2024-12-22 00:08:57
1345
原创 rk3568之mpp开发笔记mpp移植到开发板
前言:大家好,今天给大家介绍的内容是rk平台的mpp编解码这块的内容,在rk目前看到有三套框架涉及到编解码内容:1、rkmedia2、rockit3、mpp这三种不同形式的编解码方式,后面再做详细的框架对比,今天我们主要是怎么移植mpp源码到开发板里面去。这里主要是记录一下学习过程!开始移植mpp源码mpp源码一般在对应的sdk里面的external里面也有,我这里不用sdk里面的mpp源码,而是...
2024-12-08 00:20:33
1288
5
原创 到底什么是DRM?
前言:直接渲染管理器(Direct Rendering Manager,DRM)是 Linux 内核的一个子系统,负责与现代显卡的 GPU 进行接口。DRM 提供了一个 API,用户空间程序可以通过这个 API 向 GPU 发送命令和数据,执行如配置显示模式设置等操作。DRM 最初是作为 X 服务器直接渲染基础设施(Direct Rendering Infrastructure,DRI)的内核空间...
2024-12-06 22:54:35
2269
原创 读完曾国藩自传,我泪目了!
前言:大家好,趁着2024还有一个月,记录一下非技术方面的学习:最近看的曾公的自传,里面有很多关于为人处事、子女教育、自身成长相关的很多内容!感想总结:之所以截取这段话出来,自己以前也是这种经历,自己很用功,但是就是拿不到结果,内心很沮丧,感觉自己咋那么笨;不过后面也是由于有前面的积累,找到了适合自己的方法,后面做事情就稍微顺了很多,也就是说:"悬牌批责",从失败中总结,去归纳,找到问题点,然后去...
2024-12-01 00:45:01
220
原创 怎么解决码流多slice场景下的马赛克、绿屏问题?
前言:大家好,在我们平时做视频解码过程中,会经常遇到如下这些问题:花屏、绿屏、抖动、卡顿等问题,应该说这些问题,是很容易遇到的,而且有时候很难解决,同时大部分原因可能是在弱网环境下,导致传输过程中丢数据,进而在解码器拿到码流数据进行解码的时候,就会出现上述描述的问题!而今天我要给大家分享的主题是:没有丢数据的情况,在解码器上进行解码,呈现出花屏或者绿屏的现象,如下下面图片所示:那这种情况到底是什么...
2024-11-09 20:19:31
670
1
原创 rtp协议:rtcp包发送和接收规则和报告!
RTCP Packet Send and Receive Rules:发送和接收 RTCP 包的规则在此列出。允许在多播环境或多点单播环境中运行的实现必须满足第 6.2 节中的要求。这样的实现可以使用本节定义的算法来满足这些要求,或者可以使用其他算法,只要其性能等同或更优即可。在受限于两方单播操作的实现中,仍然应使用 RTCP 传输间隔的随机化,以避免在相同环境中运行的多个实例产生意外的同步,但可...
2024-10-28 00:00:20
936
原创 rtp协议:rtcp包格式和传输间隔
RTP Control Protocol -- RTCP-rtp控制协议实时传输控制协议(RTCP)基于对会话中的所有参与者定期传输控制包,使用与数据包相同的分发机制。底层协议必须提供数据包和控制包的多路复用,例如使用UDP时使用不同的端口号。RTCP执行四种功能:1、其主要功能是提供对数据分发质量的反馈。这是RTP作为传输协议角色的一个不可分割的部分,并且与其它传输协议的流量和拥塞控制功能相关(...
2024-10-27 00:02:46
1232
原创 rtsp协议:响应状态码和请求方法大总结
RTSP 消息 :RTSP 是一种基于文本的协议,使用 UTF-8 编码的 ISO 10646 字符集(RFC 2279 [21])。行以 CRLF 作为结束符,但接收方也应该准备好将 CR 和 LF 单独作为行结束符进行解释。基于文本的协议使得以自描述的方式添加可选参数变得更加容易。由于参数的数量和命令的频率较低,处理效率不是一个问题。基于文本的协议,如果设计得当,还可以轻松地使用诸如 Tcl、...
2024-10-26 10:49:37
1233
原创 rtsp协议:rtsp协议参数介绍
目的:实时流协议(RTSP)用于建立和控制单个或多个时间同步的连续媒体流,例如音频和视频。RTSP 通常不负责实际传输这些连续的媒体流,但可以将连续媒体流与控制流进行交错传输(参见第 10.12 节)。换句话说,RTSP 就像是多媒体服务器的“网络遥控器”。要控制的流集合由呈现描述(presentation description)来定义。本备忘录未定义呈现描述的格式。RTSP 中没有连接的概念;...
2024-10-12 20:16:09
1530
原创 rtp协议:rtp固定头部介绍
前言:大家好,今天开始给大家分享rtp协议的相关详细介绍,关于rtsp的介绍,大家可以暂时看官方的文档:https://datatracker.ietf.org/doc/html/rfc2326本文主要是介绍rtp协议,也就是在开发rtsp过程进行传输实际数据的部分,这部分内容也是参考官方的资料:https://www.rfc-editor.org/rfc/rfc3550介绍:该备忘录指定了实时传...
2024-09-28 19:46:20
1799
原创 深度理解srt协议中的ACK和NAK、丢包重传机制!
SRT Sockets , Send List & Channel:考虑套接字1和套接字2,每个都有自己的发送缓冲区。SndQ包含一个待发送的数据包列表。有一个线程持续检查发送缓冲区。当一个数据包准备好发送时,会创建一个CSnode来标识该数据包所属的套接字,并在SndQ中创建一个对应的对象,该对象将指向发送缓冲区。每个数据包都有一个时间戳,指示何时发送它。SndQ列表按照待处理的时间戳排...
2024-09-22 21:18:33
1405
原创 mipi协议:延迟减少和传输效率(LRTE)
Latency Reduction and Transport Efficiency(LRTE)(延迟减少和传输效率(LRTE)):延迟降低和传输效率(LRTE)是一个可选的CSI-2特性,它有助于最佳传输,以支持一些新兴的成像应用。LRTE有两个部分,将在本节中进一步详细说明:1、包间延迟减少(ILR)2、增强的传输效率。interpacket Latency Reduction (ILR):根...
2024-09-21 10:03:03
1599
原创 嵌入式流媒体SRT协议:send buffer和窗口延迟机制
Handshake Packets:握手控制包(“包类型”位 = 1)用于在点对点的 SRT 会话中建立两个对等体之间的连接。早期版本的 SRT 依赖于握手扩展来在连接建立后立即交换某些参数,但自 1.3 版本起,集成机制确保所有参数作为握手的一部分进行交换。有关详细信息,请参阅本文档后面的握手部分。KM Error Response Packets(key message 错误响应包):密钥消息...
2024-09-16 12:19:33
1360
原创 嵌入式流媒体SRT协议:Packet Structure
SRT协议介绍:SRT(Secure Reliable Transport Protocol)基于UDP数据传输协议派生出的SRT协议,是一个用户级协议,它保留了大部分核心概念和机制,同时引入了一些改进和增强,包括控制包的修改、改进的流控制以处理实时流媒体、增强的拥塞控制,以及加密数据包的机制。他的源码仓库:https://github.com/Haivision/srtSRT是一种传输协议,它能...
2024-09-15 10:09:41
1508
原创 mipi协议:多通道分配和合并
Multi-Lane Distribution and Merging:CSI-2 是一个通道可扩展的规范。对于需要比单个数据通道提供更多带宽的应用,或者那些希望避免高时钟频率的应用,可以通过增加数据通道的数量来扩展数据路径,从而近似线性地提高总线的峰值带宽。为了确保使用多个数据通道的主机处理器和外设之间的兼容性,在更高层数据与串行比特或符号流之间的映射被明确定义。概念上,在物理层和更高功能层之间...
2024-09-07 20:46:28
1448
原创 mipi协议:Camera Control Interface(I3C-SDR)
CCI(I3C SDR) Data Transfer Protocol:CCI(I3C)数据传输协议遵循I3C规范。启动条件(START)、重复启动条件(Repeated START)和停止条件(STOP),以及数据传输协议,都在[MIPI03]中进行了规定。如果支持CCI(I3C),那么必须支持CCI(I3C SDR),而CCI(I3C DDR)则可以选择支持。在进行CCI(I3C)数据传输之前...
2024-09-01 19:17:37
1241
原创 mipi协议:Camera Control Interface(CCI (I2C))
Camera Control Interface(CCI)CCI 是一种用于控制发射器的双线、双向、半双工串行接口。CCI 兼容 I2C 快速模式(Fm)或快速模式增强型(Fm+)[NXP01] 变体,以及 I3C [MIPI03] 接口的单数据速率(SDR)或双数据速率(DDR)协议。CCI 应支持高达 400kbps 的(Fm)操作和 7 位从机地址。此外,CCI 可以选择性地支持高达 1Mb...
2024-08-31 12:09:56
2102
原创 mipi协议:CSI-2总体描述
定义:CCI(I2C):支持I2C的CCI。CCI(I3C):支持I3C的CCI。CCI(I3C SDR)**表示支持I3C SDR的CCI。CCI(I3C DDR)**表示支持I3C DDR的CCI。通道(Lane):一种单向、点对点的2线或3线接口,用于高速串行时钟或数据传输;使用的线数由所用的物理层(PHY)规范决定(即D-PHY或C-PHY)。使用D-PHY物理层的CSI-2摄像头接口由一...
2024-08-28 22:38:19
1230
原创 mipi协议:RGB和RAW数据格式
RGB Image Data:表32定义了本节中描述的RGB数据格式的数据类型代码。RGB888:RGB888数据传输是通过传输BGR字节序列来完成的。该序列如图116所示:RGB888帧格式如图118所示 :表33规定了RGB888数据包的大小约束。每个数据包的长度必须是表中值的倍数 :传输中的位顺序遵循通用的CSI-2规则,即最低有效位(LSB)优先。像素到字节的映射如图117所示 :RGB6...
2024-08-25 20:27:42
3096
原创 mipi协议:yuv数据格式
数据格式:本节的目的是为CSI-2应用中通常使用的数据格式提供一个权威的参考。表24总结了这些格式,并随后对每种格式进行了单独定义。未在表中列出的通用数据类型在第11.1节中进行了描述。为简化起见,所有示例均为单通道配置。在CSI-2应用中最广泛使用的格式在表24中以“主要”标识区分。CSI-2的发送器实现应至少支持其中一种主要格式。CSI-2的接收器实现应支持所有主要格式。数据包有效负载的数据格...
2024-08-24 12:15:10
1749
原创 mipi协议:Low Level Protocol(2)
前言:今天继续给大家分享mipi协议中的Low Level Protocol部分内容翻译!Packet Header Error Correction code for D-PHY Physical Layer Option:数据标识符、字数计数和虚拟通道扩展字段的正确解释对于数据包结构至关重要。6位的数据包头错误校正码(ECC)允许在后者字段中纠正单个位错误,并在D-PHY物理层选项中检测到两...
2024-08-17 21:02:47
1337
原创 mipi协议:Low Level Protocol(1)
前言:大家好,由于之前不是有讲解sensor底层驱动的内容不,但是对mipi传输数据是如何进行的,不太清楚,所以,今天这篇文章来开始翻译的官方mipi_CSI-2_specification_v2-1-2018版本内容来学习!今天的文章是从low level protocol层来讲解:Low Level Protocol:低级协议(LLP)是一个面向字节的、基于数据包的协议,它支持使用短数据包和长...
2024-08-10 20:22:24
1299
1
原创 揭开音视频编解码超低延迟的神秘"面纱"!
前言:大家好,在上一期文章rtsp端到端到底可以做到多大的延迟?文章发布出去之后,很多朋友下方留言交流:所以交流的重要性不言而喻,很多朋友有自己的经验分享,感谢分享,哈哈!回归主题,现在很多soc的硬编解码器在参数配置上,都会提供超低延迟模式配置,但是可能对这块的技术实现原理,没怎么描述,国内的技术文档一直都是简单几句话一笔带过,给俺们这些做开发的,可犯难了,不知道这里到底有啥猫腻呢。为了理解和掌...
2024-07-13 12:56:30
1611
原创 真的,坚持了两年,不容易!
前言:大家好,最近一段时间没抽出时间来更新技术文章,上半年一直忙于项目和翻译。转眼间2024年的上半年就要过去了,下半年就要开始了,大家还记得自己年初定的“小目标”不?是啊,出来工作了好几年,每一年对时间的感受是不一样的,特别是今年对时间感觉过的太快了,就好像刚过完年一样,现在就进入下半年了!所以对于在有限的时间里面,更需要规划好每一个阶段的节奏!上半年的核心扩展学习:上半年自己空闲时间主要集中在...
2024-06-29 12:13:21
635
原创 rtsp端到端传输,最低延迟可以做到多大?
前言:大家好,今天主要给大家分享一些关于延迟这块的问题,主要是这段时间有几个朋友,过来交流这块的问题,问怎么进行优化,这个也是工作当中的重点!交流过程:网友一:网友二:总结:上面的rtsp传输,是从编码段,经过摄像机、网络传输、解码,可以做300ms以内,可能大家平时一般可以做到的延迟是300~500ms左右,但是在一些芯片硬件ip核上,会有一种超低延迟模式,会降低很多延迟,在编码端和解码端都会有...
2024-06-13 22:48:07
1883
2
原创 耗时一个月,终于搞完!!!
前言:大家好,今天主要分享的内容是最近的一些学习状态,最近除忙工作任务开发,晚上下班回来,每天会抽出40分钟左右来进行流媒体协议的翻译:比如rtsp、rtmp等,虽然网上已经有了翻译以及很多相关资料,但是还是想自己从零折腾一下,就像从零接触一个新东西一样,自己折腾,印象会更深刻,理解也会更深刻,这就是翻译的目的!目前已经把rtmp协议翻译完了,是基于1.0的版本:后面还会不断完善这个文档,以及后面...
2024-06-06 21:57:42
303
原创 老家比较安逸!
上周末临时有事情,周五临时回去了一趟,平时回去还是很舒服的,不用抢票,不用赶,4个多小时的时间就可以到老家,不过5月份的老家比较热,比深圳还热,当时一下高铁,就受不了,热的不行!也是好久没有像平时这样回去,心情也难的得到了放松;印象里出来工作之后,就只有过年才会回去,国庆都不回去,不过以后回去就很轻松了,哈哈!随着年纪的增大,越发的有一种对家乡的思念,出来工作的几年,都是快节奏,很少再能体验到以前...
2024-05-25 08:40:33
476
原创 嵌入式音视频进阶学习(建议收藏!)
前言:大家好,今天花点时间,整理一下最近看的一些音视频英文文档资料和相关的一些音视频书籍,下面分享的资料,仅是个人的一个学习,仅供参考!rtp学习:在这里给大家汇总的资料,主要是rfc英文文档资料,因为在实际开发过程中,有很多技术细节在rfc文档里面都有详细的描述,就是要稍微耐心花点时间看:1、实现rtp封装h264的说明参考的是rfc6184:https://www.rfc-editor.org...
2024-04-13 23:19:03
908
原创 音频调试(2)
前言:大家好,今天继续分享记录一下最近的音频调试心得!同时这个过程中,也有朋友过来交流音频的问题,通过交流,也是学习到了新东西!视频和音频复合推流:在上一篇文章里面有提到fdk-aac编码库,最近在调试通过获取声卡的pcm数据,然后通过fdk-aac进行编码,得到aac的音频数据,然后通过rtsp推流出去,在这个过程中遇到一个问题,就是和h264一起推流出去的时候,用ffplay拉流解码播放的时候...
2024-04-10 23:01:13
608
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人