fq 解码 AVI样本索引优先级、流信息提取与解码加速实战指南【免费下载链接】fqfq - jq for binary formats. Tool, language and decoders for working with binary formats.项目地址: https://gitcode.com/gh_mirrors/fq/fqfq 是面向二进制格式的 jq 工具内置了对 AVIAudio Video Interleaved微软音视频交错容器的完整解码支持。本篇指南以 format/riff/avi.md 为骨架结合 format/riff/avi.go 源码与其 测试数据系统讲解 fq 如何处理 AVI 中冗余的样本索引机制、如何提取指定流的样本数据、如何快速查看流摘要以及如何通过关闭样本与扩展块解码来大幅加速解码。读完本文你将能够用 fq 独立完成 AVI 文件的样本抽取、流级元数据分析和性能调优。fq 中的 AVI 解码器概览AVI 解码器位于format/riff包内与 WAVwav.go、AIFFaiff.go、WebPwebp.go等格式共享 RIFF 容器基础实现format/riff/common.go 中的riffDecode负责递归解析 RIFF chunk 结构并处理 16 位字对齐。解码器在 format/riff/avi.go 中注册核心信息如下格式标识format.AVI描述为 Audio Video Interleaved解码入口aviDecode采用小端字节序d.Endian decode.LittleEndian默认输入参数定义于 format/format.godecode_samplestrue是否解码样本samplesdecode_extended_chunkstrue是否解码扩展块extended chunks即 OpenDML AVIX 后续 RIFF 块依赖格式组用于样本深层解码format.AVC_AUH.264 访问单元对应视频流format.HEVC_AUH.265 访问单元format.MP3_FrameMP3 音频帧format.FLAC_FrameFLAC 音频帧。通过fq -h avi可以随时查看解码器的帮助信息与仓库中的 format/riff/testdata/help_avi.fqtest 输出一致avi: Audio Video Interleaved decoder Options decode_extended_chunkstrue Decode extended chunks decode_samplestrue Decode samples理解 AVI 的样本索引机制为何存在多种索引AVI 格式发展历史较长历史上出现过多种记录媒体样本音频帧、视频帧位置的方式因此一个 AVI 文件可能同时携带多套索引。fq 文档明确说明AVI has many redundant ways to index samples so currently.streams[].sampleswill only include samples using the most modern method found in the file. That is in order of stream super index, movi ix index then idx1 index.即AVI 拥有许多冗余的样本索引方式因此当前实现中.streams[].samples只会使用文件中找到的最现代的索引方法优先级从高到低为Stream super index流超索引 /indx即 OpenDMLindx块位于strl流列表内属于现代索引支持 64 位偏移与多级子索引movi ix indexix##块位于movi数据区内的流索引块chunk id 形如ix00、ix01与具体流编号绑定idx1 indexidx1块传统 AVI 索引位于文件末尾采用 32 位偏移的旧式索引。源码中对应优先级选择的逻辑在 format/riff/avi.go解码完streams数组后按顺序尝试三套候选区间——streamIndexSampleRanges来自indx超索引解析出的子索引、stream.ixSamples来自ix块、idx1Samples来自idx1只取第一套非空的作为samples输出避免同一份样本被重复列出。这三种索引在解码过程中被分别收集indx在strl列表内被解析format/riff/avi.go解析出的区间暂存于stream.indexes随后在输出streams时通过aviDecodeChunkIndex逐级展开为子索引区间ix块在movi区遇到形如ixNN的 chunk id 时解析format/riff/avi.go区间累积到对应流streams[index]的ixSamplesidx1块在 RIFF 顶层解析format/riff/avi.go每条记录包含id如00wb、flags含key_frame与list位、offset、length全部收集到idx1Samples。值得一提的是idx1的offset是相对movi数据区开始位置的偏移因此使用idx1计算样本绝对位置时源码会额外加上moviListPos并跳过 32 位的 chunk size 字段32见 format/riff/avi.go。提取指定流的样本.streams[N].samples[] | tobytes原文档提供了提取流样本的标准命令。例如提取 1 号流下标从 0 开始的全部样本并将每个样本的原始字节拼接后重定向输出$ fq .streams[1].samples[] | tobytes file.avi stream01.mp3命令拆解.streams[1]取第二个流的流对象streams数组按strl声明顺序排列.samples[]按上文所述优先级挑选的样本数组展开每个元素是一个已被深层解码的样本如mp3_frame| tobytes将解码后的样本还原为原始字节串 stream01.mp3重定向保存得到可直接播放的裸 MP3 流。若文件是双流 AVI如视频流 音频流把下标换成对应流的序号即可。从仓库测试 format/riff/testdata/mp3.avi.fqtest 可以看到实际效果该文件只有一个音频流其streams[0]下的samples[0:3]被逐一解码为(mp3_frame)每个样本内部展开了完整的 MP3 帧结构header{}、side_info{}、audio_data、crc_calculated证明tobytes提取的是帧边界精确的原始数据。注意只有strf声明了 fq 支持的编解码格式见下文支持的流格式一节时样本才会被深层解码否则样本会以FieldRawLen原始位形式呈现。查看流摘要grep_by 组合查询当只需要了解每个流是什么而不想看全部细节时原文档提供了流摘要命令$ fq -o decode_samplesfalse [.chunks[0] | grep_by(.idLIST and .typestrl) | grep_by(.idstrh) as {$type} | grep_by(.idstrf) as {$format_tag, $compression} | {$type,$format_tag,$compression}] *.avi这条命令同时适用于多个文件*.avi输出每个 AVI 内所有流的(type, format_tag, compression)三元组。逐步解释-o decode_samplesfalse关闭样本解码只解析容器与流头速度更快.chunks[0]进入最外层 RIFFAVI的 chunk 数组grep_by(.idLIST and .typestrl)筛选出LIST类型的流列表块。grep_by是 fq 提供的按条件查找的便捷函数grep_by(.idstrh) as {$type}在strl内找到流头strh块解构出type字段如auds/vids。strh的解析见 format/riff/avi.go其中type会映射为友好描述audsAudio stream、midsMIDI stream、txtsText stream、vidsVideo stream映射表见 format/riff/avi.gogrep_by(.idstrf) as {$format_tag, $compression}在strl内找到流格式strf块解构出音频流的format_tagWAV 格式标签如mp3、FLAC或视频流的compressionBITMAPINFOHEADER 中的四字符压缩标识如 H.264 相关标识。strf的解析见 format/riff/avi.go最终{$type,$format_tag,$compression}组装为摘要对象其中不存在的字段在输出中为null可以直观区分音频流有format_tag与视频流有compression。以仓库测试中的 format/riff/testdata/mp3.avi.fqtest 为参照strf解码结果中format_tag: mp3 (85)会被映射为符号名mp3视频流则会显示compression字段。对avc.aviformat/riff/testdata/avc.avi执行此命令可以确认其视频流compression为 H.264 相关标识。解码选项详解样本与扩展块的开关-o decode_samplesfalse关闭样本深层解码fq 在解析到movi内的媒体 chunk如00wb、00dc、00db时若decode_samplestrue且该流声明了受支持的格式会调用对应格式组MP3_Frame、FLAC_Frame、AVC_AU、HEVC_AU做逐样本解码见 format/riff/avi.go 与decodeSample函数 format/riff/avi.go。样本解码计算量较大关闭后movi数据块以data: raw bits形式呈现仅保留容器层级结构。-o decode_extended_chunksfalse关闭扩展块解码OpenDML 允许 AVI 超过 1 GB通过额外的RIFFAVIX块扩展数据。解码器在 format/riff/avi.go 中循环TryPeekBytes(4)检测是否还有RIFF块并将其解析为extended_chunks数组。关闭该选项可跳过这些扩展块。组合使用以加速解码原文档给出的加速命令$ fq -o decode_samplesfalse -o decode_extended_chunksfalse d file.avi若你只关心容器结构、索引或流头信息而不需要样本细节和扩展块这条命令会显著加快解码速度并减少输出体积。同理帮助信息中也给出了等价的对象写法avi({decode_extended_chunks:false,decode_samples:false})适用于管道场景$ fq -d avi -o decode_extended_chunkstrue -o decode_samplestrue . file样本解码的底层细节如何划分帧边界decodeSampleformat/riff/avi.go体现了 fq 对 AVI 样本边界的处理策略若索引区间长度为 0直接输出剩余位作为单个sample子样本大小subSampleSize stream.sampleSize * 8来自strh的sample_size字段。若sample_size为 0或流没有受支持格式且子样本大小不超过 64 位8*8的启发式规则避免把 PCM 拆成过小的块则退化为整个区间作为一个样本随后用FramedFn(subSampleSize, ...)按固定帧大小逐帧解码若decode_samplestrue且流有受支持格式每帧用FieldFormat交给对应格式组MP3/FLAC/H.264/HEVC深解否则按原始位输出。这套逻辑使得固定帧大小如strh.sample_size非零的流可以被精确分帧而变长帧如 MP3则交由 MP3 帧解码器自行同步帧边界。仓库中 format/riff/testdata/mp3.avi.fqtest、format/riff/testdata/flac.avi.fqtest、format/riff/testdata/avc.avi.fqtest、format/riff/testdata/pcm.avi.fqtest 分别覆盖了 MP3、FLAC、H.264 与 PCM 样本的解码验证。支持的流格式与格式标签从strf解析逻辑format/riff/avi.go可以看出当前支持的映射流类型判定字段受支持取值深层解码格式音频audsformat_tagmp3WAVTagMP3MP3_Frame音频audsformat_tagFLACWAVTagFLACFLAC_Frame视频vidscompressionH.264 一族标识H264、h264、X264、x264、avc1、DAVC、SMV2、VSSH、Q264、V264、GAVC、UMSV、tshd、INMCAVC_AU视频vidscompressionHEVC、H265HEVC_AU音频流的format_tag通过format.WAVTagNames映射为符号名如 85 →mp3视频流的compression以四字符码形式展示。这些格式标签常量定义在format包中例如format.WAVTagMP3、format.BMPTagH264等。未在列表内的编解码如 MPEG-4 Part 2、DV 等源码中TODO也标注了 DV handler、palette change 等未实现项会以原始位输出。容器与流的完整字段速览了解解码输出的字段有助于编写更精确的查询RIFF 层idRIFF、size、typeAVI 通过StrAssert校验错误时报wrong or no AVI riff type found见 format/riff/avi.goavih主头micro_sec_per_frame、max_bytes_per_sec、padding_granularity、flags含must_use_index、has_index、trust_ck_type、is_interleaved、copyrighted、was_capture_file等位字段、total_frames、initial_frames、streams、suggested_buffer_size、width、height、reserved见 format/riff/avi.godmlh扩展头total_frames64 位宽见 format/riff/avi.gostrh流头type、handler、flagsdisabled、pal_changes、priority、language、initial_frames、scale、rate、start、length、suggested_buffer_size、quality、sample_size、frameleft/top/right/bottom见 format/riff/avi.gostrf流格式视频为 BITMAPINFOHEADERbi_size、width、height、planes、bit_count、compression、size_image、x/y_pels_per_meter、clr_used、clr_important音频为 WAVEFORMATEXformat_tag、channels、samples_per_sec、avg_bytes_per_sec、block_align、bits_per_sample、可选cb_size与extravprp视频属性、strn/INFO 元数据字符串块ISFT等见 format/riff/common.go 的 chunk 描述表streams[]汇总每个流输出type、handler、format_tag或compression以及按优先级选出的indexes/samplesextended_chunks[]OpenDML AVIX 扩展块数组。测试与验证仓库通过 fqtest 机制对 AVI 解码器做了回归验证相关测试文件位于 format/riff/testdata/mp3.avi.fqtestMP3 音频流 AVI验证容器头解析、movi内00wb块、idx1索引解析以及streams[0].samples的逐帧 MP3 深解avc.avi.fqtestH.264 视频流 AVI验证strf中compression识别与AVC_AU样本解码flac.avi.fqtest、pcm.avi.fqtest分别覆盖 FLAC 与 PCM 音频样本help_avi.fqtestfq -h avi帮助输出与本文介绍的命令一致。这些测试同时也展示了d file.avi十六进制 解码树视图与dv file.avi的实际输出格式可作为排查解码问题的参照。参考资料原文档末尾附有 AVI 格式的两份权威背景资料微软官方 AVI RIFF 文件参考AVI RIFF File Reference以及 OpenDML AVI 文件格式扩展规范OpenDML AVI File Format Extensions它们是理解indx/ix/idx1三类索引与AVIX扩展块设计初衷的基础读物。结合本文介绍的 fq 命令与 format/riff/avi.go 源码即可完整掌握用 fq 分析、提取与调优 AVI 文件的实用技能。【免费下载链接】fqfq - jq for binary formats. Tool, language and decoders for working with binary formats.项目地址: https://gitcode.com/gh_mirrors/fq/fq创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考