A-V同步

关注

转载最新推荐文章于 2026-09-01 12:01:14 发布 1.4k 阅读 AI 写同款· GEO 优化 ›

RK3588 C-PHY摄像头驱动升级踩坑记：从‘Only CSI2 supported’报错到成功取流本文详细记录了在RK3588平台上调试C-PHY摄像头驱动的全过程，从‘Only CSI2 supported’报错分析到成功取流。内容涵盖C-PHY与CSI-2协议差异、SDK版本对比、V4L2框架下的bus-type解析机制，以及硬件排查与寄存器调优实战经验，为嵌入式Camera驱动工程师提供宝贵参考。阅读详情

AV同步的一些问题：

先转载一份A'rpi的邮件：
I've "developed" a new a-v sync engine in g2 code, which produces A-V: 0.0000
for most mpeg1/vob streams i have.

The video part is relative easy, but a bit tricky: when a PS packet has a
PTS timestamp, that timestamp belongs to the next complete frame.
(not to the one which ends in that packet!)

The audio is however very tricky.
The old (used in mplayer-g1) audio pts calculation method assumed, that the
timestamps received from the demuxer belongs to the first byte of that packet.
So, after decoded an audio frame/block, it increased PTS by the compressed
frame size divided by compressed byterate.
It is very inaccurate for mpeg. Now i've found why: in mpeg containers, the
audio timestamps behave like the video: they belong to the _next_ complete
frame/block. As AC3 frames are big, they usually go accross multiple
packets, this error may be big.
But fixing this, I got stable A-V but non-zero ct (correction total).
After experimencng with several streams, i've found that ct: value is the
time length of an audio frame. Strange, isn't it?
It means, that the PTS doesn't even belongs to the next audio frame, but to
the next after the next. Or in other words: it's the timestamp for the last
byte/sample of the next frame, instead of the first one:

v-- the PTS belongs to the
PTS end of f2 (or start of f3)
v
frames: [.....f1......][......f2......][.....f3......]
packets: | p1 | p2 | p3 | p4 | p5 |
^PTS^
^- the PTS is coded in p2's header

Using this logic I got <5ms ct: times for all mpeg streams!

But quoting the mpeg-system.pdf:
"
In the T-STD in figure 2-6 on page 11 the display of a video presentation
unit (a picture) occurs instantaneously at its presentation time, tp n (k).

In the T_STD the output of an audio presentation unit starts at its presentation
time, tp n (k), when the decoder instantaneously presents the first sample.
Subsequent samples in the presentation unit are presented in sequence at the audio sampling rate.
"

It suggests that PTS if the beginning of that audio block, not the end!

Do anyone have accurate info about the meaning/calculation of audio PTS for
mpeg container?

A'rpi / Astral & ESP-team