吃透mp4格式系列——(六)

本文详细解析了MP4文件中的元数据moovbox之trefbox,介绍了其作用及应用场景,包括如何描述不同track之间的关系,如视频与音频的绑定。

http://blog.youkuaiyun.com/pirateleo/article/details/7608781



MP4文件格式详解——元数据moov(三)tref box

原创  2012年05月28日 13:20:51

元数据moov(三)tref box(ISO-14496-12)

Author:Pirate Leo

Email:codeevoship@gmail.com

ISO 14496 - 12 定义了一种封装媒体数据的基础文件格式,mp4、3gp、ismv等我们常见媒体封装格式都是以这种基础文件格式为基础衍生的。

如果从全局角度了解基础文件格式,请看我之前的博文《MP4文件格式详解——结构概述》。

本系列文档从MP4文件入手,对文件中重要的box进行解析。

<======================================================================>

本次继续解析moov box,关于moov的解析推荐从我之前的博文《MP4文件格式详解——元数据moov(一)》看起。

moov

 

 

 

 

 

√ 

container for all the metadata

 

mvhd

 

 

 

 

√ 

movie header, overall declarations

 

trak

 

 

 

 

√ 

container for an individual track or stream

 

 

tkhd

 

 

 

√ 

track header, overall information about the track

 

 

tref

 

 

 

 

track reference container

 

 

edts

 

 

 

 

edit list container

 

 

 

elst

 

 

 

an edit list

 

 

mdia

 

 

 

√ 

container for the media information in a track

 

 

 

mdhd

 

 

√ 

media header, overall information about the media

 

 

 

hdlr

 

 

√ 

handler, declares the media (handler) type

 

 

 

minf

 

 

√ 

media information container

 

 

 

 

vmhd

 

 

video media header, overall information (video track only)

 

 

 

 

smhd

 

 

sound media header, overall information (sound track only)

 

 

 

 

hmhd

 

 

hint media header, overall information (hint track only)

 

 

 

 

nmhd

 

 

Null media header, overall information (some tracks only)

 

 

 

 

dinf

 

√ 

data information box, container

 

 

 

 

 

dref

√ 

data reference box, declares source(s) of media data in track

 

 

 

 

stbl

 

√ 

sample table box, container for the time/space map

 

 

 

 

 

stsd

√ 

sample descriptions (codec types, initialization etc.)

 

 

 

 

 

stts

√  

(decoding) time-to-sample

 

 

 

 

 

ctts

 

(composition) time to sample

 

 

 

 

 

stsc

√ 

sample-to-chunk, partial data-offset

information

 

 

 

 

 

stsz

 

sample sizes (framing)

 

 

 

 

 

stz2

 

compact sample sizes (framing)

 

 

 

 

 

stco

√ 

chunk offset, partial data-offset information

 

 

 

 

 

co64

 

64-bit chunk offset

 

 

 

 

 

stss

 

sync sample table (random access points)

 

 

 

 

 

stsh

 

shadow sync sample table

 

 

 

 

 

padb

 

sample padding bits

 

 

 

 

 

stdp

 

sample degradation priority

 

 

 

 

 

sdtp

 

independent and disposable samples

 

 

 

 

 

sbgp

 

sample-to-group

 

 

 

 

 

sgpd

 

sample group description

 

 

 

 

 

subs

 

sub-sample information


本次分析tref box——TrackReferenceBox

由于我本地没有找到包含tref box的MP4文件,因此无法以实际数据分析。

但通过协议足以使我们明白tref box的作用:

tref box可以描述两track之间关系。

比如:一个MP4文件中有三条video track,ID分别是2、3、4,以及三条audio track,ID分别是6、7、8。

在播放track 2视频时到底应该采用6、7、8哪条音频与其配套播放?这时候就需要在track 2与6的tref box中指定一下,将2与6两条track绑定起来。


在我们常见的MP4文件中几乎看不到这种情况的存在,实际应用场景在哪呢?

我们知道,ISO-14496-12是一种基础文件格式,从这种文件格式衍生出的不仅mp4文件,还有很多用于在线实时交付的流媒体视频格式,比如微软的Smooth Streaming的解决方案中的ismv文件。

假设我们是一家电视台,我们采用了微软的Smooth Streaming技术进行节目发布,我们推出了13套节目,分别是CCAV 1-13。这时候我们服务器推出的媒体流可能只有一个。这个流中包含了全部的13套节目,至少有13条视频轨与13条音频轨。用户在收看节目时使用了某公司生产的类似机顶盒似的硬件设备,可以解码与播放,但是必须要找到每套节目对应的视频与音频(不能播放CCAV 5篮球赛画面的同时配上了CCAV 13的共同关注声音)。这时候就需要通过tref box将视频与音频之间的关系一一对应起来。

这就是tref box的实际应用场景之一,有些类似ts格式中的PAT,PMT。在官方协议中描述了另一种应用,即,参考时钟track,简单理解就是音视频在此处都引用了同一个time code track,以使音视频同步播放,类似ts格式中PCR与各track的PTS关系。

下面看具体字段:

[cpp]  view plain  copy
  1. aligned(8) class TrackReferenceBox extends Box(‘tref’)   
  2. {  
  3.   
  4. }   
  5. aligned(8) class TrackReferenceTypeBox (unsigned int(32) reference_type) extends Box(reference_type)   
  6. {  
  7.   unsigned int(32) track_IDs[];   
  8. }   

顾名思意,tref box用于列出本track解析时所参考的track有哪些。

每个trak box中只能包含[0-1]个tref box;(通常情况下,我们所见的MP4文件是没有tref box的)

每个tref box下面可以包含1个以上的tref type box;

引用Apple官方给出的结构图如下:


在Apple协议中,atom是box的另一种名称;图中可知tref box中包含多个子box,每个子box需要填写type和track ID。

Type的填写参照下表(Apple定义):

Track reference types

Reference type

Description

'tmcd'

Time code. Usually references a time code track.

'chap'

Chapter or scene list. Usually references a text track.

'sync'

Synchronization. Usually between a video and sound track. Indicates that the two tracks are synchronized. The reference can be from either track to the other, or there may be two references.

'scpt'

Transcript. Usually references a text track.

'ssrc'

Non-primary source. Indicates that the referenced track should send its data to this track, rather than presenting it. The referencing track will use the data to modify how it presents its data. See “Track Input Map Atoms” for more information.

'hint'

The referenced tracks contain the original media for this hint track.

ISO-14496-12又重新整理了这些type字段为以下三种:

•  ‘hint’  the referenced track(s) contain the original media for this hint track 
•  ‘cdsc‘  this track describes the referenced track. 
•  ‘hind‘  this track depends on the referenced hint track, i.e., it should only be used if the referenced 
hint track is used. 


<think> 嗯,用户明确询问如何吃透Java项目的方法,这已经是第二次提问了(之前系统提示过参考站内引用),看来用户对技术深度掌握有强烈需求。从用户身份推测大概率是中级Java开发者——既熟悉基础语法但缺乏复杂项目实战经验,可能正面临跳槽或接手重要项目。 注意到用户引用的资料强调“真实业务场景”和“技术栈全面性”,这提示我需要避开理论空谈。引用[2]提供了完整步骤框架,但用户可能更需要可落地的实操技巧。特别要突出三点:如何避免陷入代码海洋的陷阱、怎样验证是否真“吃透”了、企业级项目的特殊考量。 上次回复时已经拆解过技术栈和调试方法,这次应该升级维度:重点补充引用[4]提到的“架构设计责任”视角和“主干分支切割法”。用户引用中rocketMQ案例值得展开,但需注意平衡深度与普适性——用消息队列举例时得同步说明通用方法论。 用户焦虑点可能在时间效率,“几个月才能吃透”这种话绝不能出现。要把“里程碑验证法”(如七天能画架构图)和“渐进式目标”设计得更清晰。另外所有引用都未提及团队协作层面的吃透技巧,这恰好是实际开发的关键,需要补充。 </think> 以下是基于技术实践总结的**吃透Java项目方法论**,结合核心步骤与关键技巧,帮助深度掌握项目全貌: --- ### **一、系统化拆解步骤** 1. **理解业务背景与目标** - 明确项目解决的**核心问题**(如电商平台的秒杀场景、支付对账系统) - 梳理关键业务流程(用流程图/UML梳理订单创建→支付→履约的主干) - 定位项目在技术架构中的**层级角色**(如属于中台服务/网关层/数据聚合层)[^4] 2. **解剖项目结构** ```bash ├── src/main/java │ ├── controller # API入口 │ ├── service # 业务逻辑 │ ├── dao # 数据访问层 │ └── config # 配置类(Spring Boot) ├── resources │ ├── application.yml # 主配置 │ └── mapper # MyBatis XML └── test # 单元测试 ``` - 重点:**依赖关系分析**(利用`mvn dependency:tree`或IDE插件生成依赖图) 3. **技术栈深度掌握** | 技术类型 | 关键学习点 | 实践验证方式 | |----------------|-----------------------------------|--------------------------------| | **核心框架** | Spring IOC/AOP、事务管理机制 | 修改事务传播级别观察回滚效果 | | **中间件** | Redis缓存击穿解决方案、MQ消息幂等 | 模拟高并发测试消息重复消费 | | **数据库** | 分库分表策略、索引优化方案 | 用Explain分析慢SQL | 4. **代码研读技巧** - **从入口切入**:找到`SpringBootApplication`启动类,追踪请求链路(如HTTP请求→Controller→Service) - **断点调试黄金法则**: ```java // 关键位置设断点 + 条件触发(IDEA技巧) if(orderId > 10000) { // 设置条件断点 logger.debug("大订单处理逻辑"); } ``` - **逆向推导**:通过单元测试(`@Test`)反推模块功能 --- ### **二、进阶实践策略** 1. **数据流全景分析** - 绘制**数据流转图**: ```mermaid graph LR A[用户请求] --> B(网关鉴权) B --> C[服务A处理] C --> D[(DB读写)] D --> E[消息队列通知] E --> F[服务B消费] ``` 2. **深度改造验证** - 示例挑战: - 将单点登录改造为OAuth2.0协议 - 将同步扣库存改为Redis+Lua分布式锁 3. **性能压测反推架构** - 用`JMeter`模拟并发场景,观察: - 线程池配置是否合理(拒绝策略触发条件) - 数据库连接池瓶颈(如Druid监控页) - 缓存命中率波动(Redis监控工具) --- ### **三、避坑指南** 1. **文档缺失时的应对** - 通过`git blame`追溯历史提交记录,还原代码演进逻辑 - 用Arthas在线诊断:`watch com.example.Service * '{params,returnObj}'` 观察方法入出参 2. **复杂技术栈速攻法** - 优先掌握**20%核心功能**(如Spring Cloud只深挖Gateway/Nacos) - 对照官方文档验证项目中的定制化修改(如RocketMQ消息重试机制被覆写)[^4] > **关键衡量标准**:能准确回答—— > - 项目的**技术选型权衡**(为什么用Kafka而非RabbitMQ?) > - **极端场景处理方案**(数据库挂掉时降级策略是什么?) > - **扩展性设计缺陷**(百万人同时抢券系统如何改造?) --- **
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值