gpt4 book ai didi

ffmpeg - ffmpeg 是否因 h.264 RTP 输出而损坏?

转载 作者:行者123 更新时间:2023-12-04 23:11:19 26 4
gpt4 key购买 nike

我使用wireshark来捕获发送的RTP流:ffmpeg -f lavfi -i "testsrc=duration=5:size=cif:rate=25" -pix_fmt yuv420p -g 25 -bf 2 -an -c:v libx264 -f rtp rtp://127.0.0.1:1234 > play.sdpffmpeg 版本
ffmpeg 版本 git-2020-03-15-c467328 版权所有 (c) 2000-2020 FFmpeg 开发者
如粗体所示,RTP 时间戳向前和向后。我希望它们对于帧中的每个数据包都是相同的,然后根据 H.264/RTP 规范仅前进 40 毫秒(在 90khz 时钟下 +3600)。
此外,根据该规范,帧中的最后一个数据包应该设置其标记位,但这里几乎所有数据包都设置了该位。
难道我做错了什么?不明白什么?还是 ffmpeg 对编写 H.264 RTP 的支持被破坏了?
SSRC=0xA49C3DC9,序列=3595,时间=3153114809
SSRC=0xA49C3DC9,序列=3596,时间=3153114809
SSRC=0xA49C3DC9,序列=3597,时间=3153114809
SSRC=0xA49C3DC9,Seq=3598,时间=3153114809,标记
SSRC=0xA49C3DC9,Seq=3599,时间=3153125609,标记
SSRC=0xA49C3DC9,序列=3600,时间= 3153118409 , 标记
SSRC=0xA49C3DC9,序列=3601,时间= 3153122009 , 标记
SSRC=0xA49C3DC9,序列=3602,时间= 3153136409 , 标记
SSRC=0xA49C3DC9,序列=3603,时间= 3153129209 , 标记
SSRC=0xA49C3DC9,序列=3604,时间= 3153132809 , 标记
SSRC=0xA49C3DC9,序列=3605,时间= 3153147209 , 标记
SSRC=0xA49C3DC9,Seq=3606,时间=3153140009,标记
SSRC=0xA49C3DC9,Seq=3607,时间=3153143609,标记
SSRC=0xA49C3DC9,Seq=3608,时间=3153158009,标记
SSRC=0xA49C3DC9,Seq=3609,时间=3153150809,标记
SSRC=0xA49C3DC9,Seq=3610,时间=3153154409,标记
SSRC=0xA49C3DC9,Seq=3611,时间=3153168809,标记
SSRC=0xA49C3DC9,Seq=3612,时间=3153161609,标记
SSRC=0xA49C3DC9,Seq=3613,时间=3153165209,标记
SSRC=0xA49C3DC9,Seq=3614,时间=3153179609,标记
SSRC=0xA49C3DC9,Seq=3615,时间=3153172409,标记
SSRC=0xA49C3DC9,Seq=3616,时间=3153176009,标记
SSRC=0xA49C3DC9,Seq=3617,时间=3153190409,标记
SSRC=0xA49C3DC9, Seq=3618, Time=3153183209, 标记

最佳答案

规范 RFC 6184 对标记位说,

Set for the very last packet of the access unit indicated by the RTP timestamp
编码器为每个 AU 编码一帧,因此这里没有中断。
时间戳是非单调的,因为您启用了 B 帧。 B 帧在任何引用的 P 帧之前显示,但在编码期间在其之后编码并按编码顺序发出。设置 -bf 0禁用 B 帧并具有单调 PTS。

关于ffmpeg - ffmpeg 是否因 h.264 RTP 输出而损坏?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/67376316/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com