皮皮网

1.音视频编解码-H264和H265 运动估计对比
2.FFmpeg 集成 x265 编译及解码
3.解决FFmpeg播放RTSP推送的源码H265码流报错问题
4.优秀的 Verilog/FPGA开源项目介绍（十）- H.264和H.265
5.音视频开发项目：H.265播放器：视频解码篇
6.哪里有免费的网址导航源代码，网站导航代码 网址导航模板下载

音视频编解码-H264和H265 运动估计对比

       本文探讨了H和H编码中运动估计的源码两种关键策略，MVP（运动矢量预测）和AMVP（自适应运动矢量预测）的源码差异。H的源码MVP基于单个参考的简单平均，而H的源码AMVP则更复杂，支持多个候选位置，源码工作室网站源码包括不同参考帧的源码MV缩放后作为MVP，这提高了预测精度和压缩效率。源码

       运动估计是源码视频编码的核心环节，它通过比较连续帧识别像素移动，源码以减少冗余数据。源码运动补偿则是源码利用这些估计的运动矢量来预测帧间变化，减少数据传输。源码H的源码AMVP不仅考虑了空间相邻块的运动，还考虑了时间依赖性和运动矢量场，源码这在处理复杂运动场景时更具优势。

       在H中，MVP候选列表基于当前块的上下邻接块运动矢量；而在H中，AMVP的候选列表扩展到了空间候选、时间候选和零候选，提供了更细致的预测。AMVP的引入不仅减小了预测误差，还优化了编码比特率，特别是在高运动场景下。

       总结来说，H的AMVP在运动估计的精度和压缩效率上超越了H的MVP。深入理解这些技术需要查阅相关标准、论文和编码器源码，以获得更全面的视角。

       如果你对音视频编解码技术感兴趣，欢迎关注我的公众号《MediaStack》或知乎专栏，我们将定期分享深入的技术内容。

FFmpeg 集成 x 编译及解码

       x 是一个免费开源的视频编码库，支持 H./MPEG-H HEVC 格式，遵循 GNU GPL 许可证。

       为了在 FFmpeg 中集成 x，以支持 H. 编解码功能，需先编译 x。然而，并非所有 FFmpeg 版本都能直接使用 x，如在 Android、Windows 和 Linux 平台上使用 Android NDK re 时，可能会遇到符号缺失、潮汕暗宝源码无法编译 .S 文件等问题。

       一、x 的编译

       在进行编译前，请确保系统使用的是 Ubuntu .。编译目录结构应根据平台选择相应的目录，例如在 Windows 平台下使用 i 或 x_ 目录，Android 则使用 arm 平台的 armeabi-v7a 或 arm-v8a 目录。

       编译 x 时，使用特定脚本执行编译过程，如 `build_x.sh`，然后在同级目录下的 build 目录中生成编译产物。

       对于 Android 平台，需要使用 Android NDK re 的 Linux 版本。需要调整 `build_x.sh` 脚本中的内容，并修改 x 源代码以支持 NEON 处理。编译 x Release_3.5 版本时，可能遇到 fseeko 和 ftello 符号缺失的问题，这是因为 NDK re 中无法导出这些符号。解决办法是使用 x 2.6 版本，该版本能正常编译。

       在 Windows 平台上，可以使用 mingw-w-build 工具来搭建编译环境。对于 Linux 平台，仅需编译 x_ 版本。

       二、FFmpeg 集成 x 的编译

       在编译 FFmpeg 时，需对脚本进行修改以集成 x。这包括在 Linux 系统上增加特定差异点，确保 FFmpeg 能够成功利用 x 进行 H. 编解码。

解决FFmpeg播放RTSP推送的H码流报错问题

       RTSP，实时流传输协议，常用于传输视频流。许多流媒体平台，如B站的ijkplayer，都是基于FFmpeg的FFplay内核。我曾分享过关于使用RTSP推送H码流的文章，包括本地拉流和编码时的推流显示。然而，当尝试使用FFplay处理RTSP推送的H码流时，遇到了报错"illegaltemporal ID in RTP/HEVC packet"。

       这个错误提示指向了H的NALU Header中的temporal ID问题。FFmpeg的爱信红包源码源码检查了这个值，如果为0，会报错。H标准规定temporal ID不能为0，因此这个检查是合理的。问题可能出在RTP封装过程，而非原始码流，因为本地H码流的NALU Header值并不是0。

       为了解决这个问题，我深入研究了RTP封装H裸流的原理，发现在HSource.cpp的HandleFrame函数中，处理NALU数据时忽略了起始码。修正这一逻辑后，成功用FFplay播放了RTSP推送的H视频，尽管与VLC的播放效果相比稍有卡顿。FFplay播放的命令行参数包括指定窗口名称和分辨率。

       总结来说，通过问题定位和源码解析，我解决了FFplay在处理RTSP H码流时的报错，实现了本地H视频的正确播放。这个过程对理解FFmpeg工作原理和RTSP封装有帮助。

优秀的 Verilog/FPGA开源项目介绍（十）- H.和H.

       H.是ITU-TVCEG在H.之后推出的新视频编码标准，它在保留H.某些技术的基础上，对相关技术进行了改进。H.采用了先进技术，以优化码流、编码质量、延时和算法复杂度之间的关系，旨在提高压缩效率、鲁棒性和错误恢复能力，减少实时延时和信道获取时间，降低复杂度。

       H.，即MPEG-4第十部分，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT）提出的高度压缩数字视频编解码器标准。H.的最大优势是其高数据压缩比率，在同等图像质量的条件下，其压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。

       H.旨在在有限带宽下传输更高质量的网络视频，仅需原先的一半带宽即可播放相同质量的视频。这意味着，我们的比快爆源码智能手机、平板机等移动设备将能够直接在线播放p的全高清视频。H.标准也同时支持4K（×）和8K（×）超高清视频。

       H.与H.的不同之处在于，H.在H.的基础上进行了改进，包括帧内预测、帧间预测、转换、量化、去区块滤波器和熵编码等模块。H.的编码架构大致上与H.相似，但整体被分为三个基本单位：编码单位（CU）、预测单位（PU）和转换单位（TU）。

       复旦大学H./H.开源IP，包括H. Video Encoder IP Core，是由复旦大学专用集成电路与系统国家重点实验室（State Key Lab of ASIC & System，Fudan University）视频图像处理实验室（VIP Lab）范益波教授研究团队开发完成，并开放源代码。

       开源地址：openasic.org

       关于上板验证，网站上有相关的验证板卡代码，如下：

       github上的开源H.，开源地址：github.com/tishi/h...

       用verilog和system verilog编写，在FPGA板上用Xilinx ZYNQ验证，运行最高MHZ。

       内容：文件夹“src”包含所有解码源文件。文件夹“tb”包含测试台文件，ext_ram_.v使用axi3接口模拟ddr。文件夹“pli_fputc”是verilog pli，用于在运行模拟时将输出bin写入文件。

       使用方法：模拟：将所有测试平台和源代码文件添加到您的模拟项目源中，例如modelsim。将测试文件in.放到您的模拟项目文件夹中。然后运行，例如，对于modelsim，运行“vsim -pli pli_fputc.dll bitstream_tb”。输出是out.yuv和一些日志文件。

       在FPGA板上运行：将“src”文件夹中的源文件添加到您的FPGA项目中。顶部文件是decode_stream.sv。两个接口，stream_mem_xxx用于将H比特流馈送到解码器。

       github上的开源H.，开源地址：github.com/aiminickwong...

       无介绍

       说明：第一个项目由复旦大学专用集成电路与系统国家重点实验室（State Key Lab of ASIC & System，哆啦咪源码Fudan University）视频图像处理实验室（VIP Lab）推出，不论项目完成度还是文档说明，都非常详细，同时上面给的是该项目的论坛，论坛上有相关工作人员维护，活跃度很高，适合去学习使用。

       后面两个项目，碎碎并没验证过，但是感觉不怎么靠谱，README完整度不高，有兴趣的可以去看看。

       最后，还是感谢各个大佬开源的项目，让我们受益匪浅。后面有什么感兴趣方面的项目，大家可以在后台留言或者加微信留言，今天就到这，我是爆肝的碎碎思，期待下期文章与你相见。

       优秀的 Verilog/FPGA开源项目介绍（九）- DP（增改版）

       优秀的 Verilog/FPGA开源项目介绍（八）- HDMI

       优秀的 Verilog/FPGA开源项目介绍（七）- CAN通信

       介绍一些新手入门FPGA的优秀网站（新增2）

       优秀的 Verilog/FPGA开源项目介绍（六）- MIPI

       优秀的 Verilog/FPGA开源项目介绍（五）- USB通信

       优秀的 Verilog/FPGA开源项目介绍（四）- Ethernet

       优秀的 Verilog/FPGA开源项目介绍（三）- 大厂的项目

       优秀的 Verilog/FPGA开源项目介绍（二）-RISC-V

       优秀的 Verilog/FPGA开源项目介绍（一）-PCIe通信

音视频开发项目：H.播放器：视频解码篇

       探索音视频开发的前沿技术，让我们深入剖析一款H.播放器的视频解码优化过程。在这款高性能播放器中，新版以惊人的效率展示了其解码能力，1分钟内处理p/fps的H. MP4视频，内存占用仅为4.6GB，而CPU占用率在极限条件下也保持在+。单帧解码p的速度已经优化到了惊人的毫秒，相较于旧版p的毫秒，无疑展示了技术的飞跃。

       播放器的架构设计巧妙，由Loader、Demuxer、Renderer（核心模块）和UI View等模块构成，各部分独立却又协同工作。让我们走进DEMO架构示例：Loader负责从Annex-B码流中读取数据，WASM技术则高效地解码YUV数据，而FFmpeg经过精简编译后，被转化为轻量级的WASM包，实现资源优化。

       要实现这一优化，首先从FFmpeg官网获取emsdk和源码版本（4.1），然后通过定制的make_decoder.sh脚本，去除不必要的模块，如swresample和postproc，专注于关键的hevc-decoder模块。这个过程包括禁用非必要的FFmpeg功能，生成简化库和.h文件，为后续的WASM编译做准备。

       接下来，编写自定义的C语言入口文件（如decoder.c），运用C语言基础，创建一个初始化解码器的接口，如init_decoder，它接受一个JS回调函数，传递解码数据的地址、长度，以及可选的时间戳（pts）。附赠的学习资料包，包含FFmpeg、webRTC等技术，可通过企鹅裙获取，助你快速上手。

       解码的核心在于处理AVPacket和AVFrame，视频中每个压缩帧需要通过demuxers和decoders逐一解析。decode_buffer函数负责数据解析和解码，将解码后的AVPacket传递给解码器，可能需要多次循环以接收完整的AVFrame。而在3.x和4.x版本中，avcodec_send_packet和avcodec_decode_video2/avcodec_decode_audio4的调用方法有所不同。

       解码后的YUV数据通常以紧缩格式（如YUVp）和平面格式存储，需要转换后供JS使用。在这个过程中，采样率决定了数据处理的复杂度，例如4个Y分量对应1个U和V分量。将解码后的AVFrame复制到yuv_buffer，然后通过decoder_callback传递给JavaScript。

       通过Emscripten构建WASM包，我们编写build_decoder.sh脚本，设置出口函数和内存配置，最终生成wasm/libffmpeg.js。在JS和Worker中，我们加载并调用WASM函数，构建Decoder类，扩展EventEmitter，处理数据的异步加载和解码。在主线程中，通过webpack和worker-loader，数据从主线程传输到Worker，解码器负责解码并返回处理后的数据。

       H.视频解码的挑战在于高效处理AVPacket和AVFrame，音频解码则可能需要复用解码链路或者利用浏览器内置的解码器。音频播放则依赖于AudioContext，确保主流音频编码格式在浏览器中的兼容性。通过这个案例，我们了解了如何避免常见问题，以及FFmpeg在视频处理中的强大能力。H.播放器的应用场景广泛，为创新提供无限可能。

哪里有免费的网址导航源代码，网站导航代码 网址导航模板下载

       网址导航站很多，可是真正具有代表性的主要有hao,万能导航网，，百度导航等

       具体的是：

       /

       /

       /

       我也做了一个导航网站，主要是参考“万能导航网”来制作的

       因为万能导航网是纯手工制作的导航网页

       下载下来只需要改个头和尾就行了

音视频探索(6)：浅析MediaCodec工作原理

       MediaCodec类是Android平台用于访问低层多媒体编/解码器的接口，它是Android多媒体架构的一部分，通常与MediaExtractor、MediaMuxer、AudioTrack等工具配合使用，可以处理多种常见的音视频格式，包括H.、H.、AAC、3gp等。MediaCodec的工作原理是通过输入/输出缓存区同步或异步处理数据。客户端首先将要编解码的数据写入编解码器的输入缓存区，并提交给编解码器。编解码器处理后，数据转存到输出缓存区，同时收回客户端对输入缓存区的所有权。然后，客户端从编解码器的输出缓存区读取编码好的数据进行处理，读取完毕后编解码器收回客户端对输出缓存区的所有权。这一过程不断重复，直至编码器停止工作或异常退出。

       在整个MediaCodec的使用过程中，会经历配置、启动、数据处理、停止、释放等步骤，对应的状态包括停止(Stopped)、执行(Executing)以及释放(Released)，而Stopped状态又细分为未初始化(Uninitialized)、配置(Configured)、异常(Error)，Executing状态细分为读写数据(Flushed)、运行(Running)和流结束(End-of-Stream)。当MediaCodec被创建后，它会处于未初始化状态，待设置好配置信息并调用start()方法启动后，它会进入运行状态，并可以进行数据读写操作。若在运行过程中出现错误，MediaCodec会进入Stopped状态。此时，使用reset方法来重置编解码器是必要的，否则MediaCodec所持有的资源最终会被释放。如果MediaCodec正常完成使用，可以向编解码器发送EOS指令，同时调用stop和release方法来终止编解码器的使用。

       MediaCodec主要提供了createEncoderByType(String type)、createDecoderByType(String type)两个方法来创建编解码器，这两个方法需要传入一个MIME类型多媒体格式。常见的MIME类型多媒体格式有：image/jpeg、audio/amr、video/3gpp、video/h、video/avc等。此外，MediaCodec还提供了createByCodecName (String name)方法，可以使用组件的具体名称来创建编解码器，但这种方法的使用相对繁琐，且官方建议最好配合MediaCodecList使用，因为MediaCodecList记录了所有可用的编解码器。我们也可以使用MediaCodecList对传入的minmeType参数进行判断，以匹配出MediaCodec对该mineType类型的编解码器是否支持。例如，指定MIME类型为“video/avc”时，可以使用如下代码来创建H.编码器：

       java

       MediaCodecInfo.CodecCapabilities capabilities = MediaCodecList.getCodecCapabilities("video/avc");

       if (capabilities != null) {

        MediaCodec codec = MediaCodec.createByCodecName(capabilities.getName());

       }

       配置和启动编解码器使用MediaCodec的configure方法。这个方法首先提取MediaFormat存储的数据map，然后调用本地方法native_configure实现配置工作。在配置时，需要传入format、surface、crypto、flags参数。format是一个MediaFormat实例，它以“key-value”键值对的形式存储多媒体数据格式信息；surface用于指定解码器的数据源；crypto用于指定一个MediaCrypto对象，以便对媒体数据进行安全解密；flags指明配置的是编码器(CONFIGURE_FLAG_ENCODE)。对于H.编码器的配置，可以使用createVideoFormat("video/avc", , )方法创建“video/avc”类型的编码器的MediaFormat对象，并需要指定视频数据的宽高。如果处理音频数据，则可以调用MediaFormat的createAudioFormat(String mime, int sampleRate,int channelCount)方法。

       配置完毕后，通过调用MediaCodec的start()方法启动编码器，并调用本地方法ByteBuffer[] getBuffers(input)开辟一系列输入、输出缓存区。start()方法的源码如下：

       java

       native_start();

       ByteBuffer[] buffers = getBuffers(input);

       MediaCodec支持同步(synchronous)和异步(asynchronous)两种编解码模式。同步模式下，编解码器的数据输入和输出是同步的，只有当输出数据处理完毕时，编解码器才会接收下一次输入数据。而异步模式下，输入和输出数据是异步的，编解码器不会等待输出数据处理完毕就接收下一次输入数据。这里主要介绍同步编解码模式，因为它更常用。当编解码器启动后，它会拥有输入和输出缓存区，但是这些缓存区暂时无法使用，需要通过MediaCodec的dequeueInputBuffer/dequeueOutputBuffer方法获取输入输出缓存区的授权，并通过返回的ID来操作这些缓存区。下面是一个官方提供的示例代码：

       java

       for (;;) {

        ByteBuffer[] buffers = codec.dequeueInputBuffer();

        if (buffers != null) {

        // 处理输入缓存区

        }

        ByteBuffer[] outputBuffers = codec.dequeueOutputBuffer(new MediaCodec.BufferInfo(), );

        if (outputBuffers != null) {

        // 处理输出缓存区

        }

       }

       获取编解码器的输入缓存区并写入数据。首先调用MediaCodec的dequeueInputBuffer(long timeoutUs)方法从编码器的输入缓存区集合中获取一个输入缓存区，并返回该缓存区的下标index。接着调用MediaCodec的getInputBuffer(int index)，该方法返回缓存区的ByteBuffer，并将获得的ByteBuffer对象及其index存储到BufferMap对象中，以便在输入结束后释放缓存区并交还给编解码器。然后，在获得输入缓冲区后，将数据填入并使用queueInputBuffer将其提交到编解码器中处理，同时释放输入缓存区交还给编解码器。queueInputBuffer的源码如下：

       java

       native_queueInputBuffer(index, offset, size, presentationTimeUs, flags);

       获取编解码器的输出缓存区并读出数据。与获取输入缓存区类似，MediaCodec提供了dequeueOutputBuffer和getOutputBuffer方法来获取输出缓存区。但是，在调用dequeueOutputBuffer时，还需要传入一个MediaCodec.BufferInfo对象，它记录了编解码好的数据在输出缓存区中的偏移量和大小。当调用本地方法native_dequeueOutputBuffer返回INFO_OUTPUT_BUFFERS_CHANGED时，会调用cacheBuffers方法重新获取一组输出缓存区。这意味着在使用getOutputBuffers方法（API 后被弃用，使用getOutputBuffer(index)代替）来获取输出缓存区时，需要在调用dequeueOutputBuffer时判断返回值，如果返回值为MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED，则需要重新获取输出缓存区集合。此外，还需要判断dequeueOutputBuffer的其他两个返回值：MediaCodec.INFO_TRY_AGAIN_LATER、MediaCodec.INFO_OUTPUT_FORMAT_CHANGED，以处理获取缓存区超时或输出数据格式改变的情况。最后，当输出缓存区的数据被处理完毕后，通过调用MediaCodec的releaseOutputBuffer释放输出缓存区，交还给编解码器。releaseOutputBuffer方法接收两个参数：Index、render，其中Index为输出缓存区索引，render表示当配置编码器时指定了surface，那么应该置为true，输出缓存区的数据将被传递到surface中。