Andius的博客

最近在学习有关Windows上的音频驱动相关的知识，在正式开始说WASAPI之前，我想先说一说Qt的Multiple Media，为什么呢？因为Qt的MultipleMedia实际上是WASAPI的一层封装，它在是线上替我做了很多事，就好像在Microsoft的文档上会推荐你先学习Windows.Media.Capture，然后再看low level的WASAPI。

现在不是搞音频嘛，正好自己买了无源音箱，买了套DSP芯片玩一下。

最近学了不少有关音频相关的，最近搞一下ALSA驱动。

当我们在使用JUCE库的时候，可能会需要使用到静态链接的方式，还好的一点是JUCE本身提供了CMake编译，也提供了单独的sln编译。本文章仅针对juce-7.0.1-windows，由于不同版本之间差异较大，可能不能通用，但主要的不同点都在修改源码那个环节。

上次我们做了一个简单的视频解码，这一次简单对这个代码进行一个剖析，对其中的数据结构进行一个解析。

话不多说，重走霄骅登神路前一篇文章。

参考了雷神的自制播放器项目，100行代码实现最简单的基于FFMPEG+SDL的视频播放器（SDL1.x）不过老版本的代码参考意义不大了，我现在准备使用Qt + VS2022 + FFmpeg59重写这部分代码，具体的代码仓库如下：LeventureQys/MediaPlay-FFmpeg开发环境：Visual Studio 2022 + Qt 5.14.2 + FFmpeg 59首先我们Visual Studio 2022 + qt是准备好的，这里不做过多介绍了。这里简单说说我在做这一块的时候，为什么没

Tag Header里存放的是当前tag的类型、数据区(tag data)的长度等信息。一个FLV文件，每种类型的tag都属于一个流，也就是一个flv文件最多只有一个音频流，一个视频流，不存在多个独立的音视频流在一个文件的情况。格式0与格式3的不同之处只有一点：格式0存储16位采样数据，采用的大小端顺序是创建FLV文件的平台所使用的大小端顺序。因此，不应使用格式0，而应使用格式3。格式11，Speex，音频以16 kHz采样率压缩为单声道，采样率字段值应为0，采样位深字段值应为1，声音类型字段值应为0。

ADIF：Audio Data Interchange Format 音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。故这种格式常用在磁盘文件中。是AAC音频的传输流格式。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。总结：ADTS可以在任意帧解码，也就是说它每一帧都有头信息。ADIF只有一个统一的头，所以必须得到所有的数据后解码。

最近在搞交叉编译的事，手上拿了个同事的香橙派玩交叉编译，现在来到了第一步，就是先在arm上配置qt的开发环境。当然了Qt没有直接提供qt on arm，而是需要自行在arm环境下编译一个qt环境出来，所以这里需要使用到qt提供的qt everywhere套件在板载系统上编译。

1、编码是为了将数据进行压缩，这样在传输的过程中就不会使资源被浪费。2、用一个简单的例子来说明编码的必要性：当你此刻显示器正在播放一个视频，分辨率是1280720，帧率是25，那么一秒所产生正常的数据大小为：1280720(位像素)*25(张) / 8(1字节8位)(结果:B) / 1024(结果:KB) / 1024 (结果:MB) = 2.75MB。显然一秒这么大的数据你是无法接受的，需要将数据进行压缩。

PCM(Pulse Code Modulation)也被称为脉冲编码调制。PCM音频数据是未经压缩的音频采样数据裸流，它是由模拟信号经过采样、量化、编码转换成的标准的数字音频数据。

YUV 是一种颜色编码方法，和它等同的还有 RGB 颜色编码方法。因为RGB颜色编码的方式是我们从小看到大的，所以先简单聊聊RGB颜色编码。

本文旨在自学Linux相关知识，这里简单聊聊记录一下。