最初由 su_xinling 发布
应该不是vfr的问题,而是23.976和24000/1001的关系,会有点差异的吧。用x264cli压出23.976fps的mkv应该就是接近前者这种吧,timcode会精确到小数2位,然后再用mkvmerge合并声音时就4舍5入 -- 也就是重新封的话最好是直接倒入mkv,这样不会重算timecode而是保持原来的到整数位,如果倒入raw的话指定fps为23976/1000时,也能形成a栏那种timecode...
请问timecodev2是什么意思?
SoMaster@2008-07-29 22:05
这段我看不明白雷鸣@2008-07-29 22:18
1000 / 25 = 40SoMaster@2008-07-31 02:02
最近尝试把avc封到mkv去SAPikachu@2008-07-31 08:49
因为你下载回来的mkv的vfr的。。。每帧的间隔不同。。。su_xinling@2008-07-31 12:50
应该不是vfr的问题,而是23.976和24000/1001的关系,会有点差异的吧。用x264cli压出23.976fps的mkv应该就是接近前者这种吧,timcode会精确到小数2位,然后再用mkvmerge合并声音时就4舍5入 -- 也就是重新封的话最好是直接倒入mkv,这样不会重算timecode而是保持原来的到整数位,如果倒入raw的话指定fps为23976/1000时,也能形成a栏那种timecode...SoMaster@2008-08-01 02:25
引用最初由 su_xinling 发布
应该不是vfr的问题,而是23.976和24000/1001的关系,会有点差异的吧。用x264cli压出23.976fps的mkv应该就是接近前者这种吧,timcode会精确到小数2位,然后再用mkvmerge合并声音时就4舍5入 -- 也就是重新封的话最好是直接倒入mkv,这样不会重算timecode而是保持原来的到整数位,如果倒入raw的话指定fps为23976/1000时,也能形成a栏那种timecode...
su_xinling@2008-08-01 16:54
毫秒的个位数差别是感觉不出的,没什么好计较,毕竟封装软件本身不一致,timecode的算法可能存在微小的差异。如果差很多,要嘛就是指定的帧率不对,或者就是所谓的vfr的,这时候应该使用timecode文件了。52wy@2008-08-05 08:47
基本上=。= 只要再合成后没有严重的不同步,都可以无视啦。。。追求完全一致很痛苦的说。roozhou@2008-08-05 13:23
2ms时间声音还走不满1米,要知道音箱距离不同造成的误差都比这个大。