digimoon
帖子: 49
注册时间: 2011-07-15 11:59

Re: x264 - 06_taro编译版(r2323+704)

2013-06-20 10:57

264768502 写了:不一定是水果的HLS,那种得把文件真的分割成好多个,然后弄个索引文件m3u8,嘛,这个不是讨论的重点啦,越扯越远啦

具体到你的情况,只是最简单的video标签的话,用的就是浏览器自带的播放器了,只是目前的情况的话,很难说是谁的问题,毕竟播放器的支持特性不一样
有兴趣的话可以在试试看PC上几个支持HTML5视频的浏览器,来看看情况.
pc上用chrome测试过能正常播放所以才来问问兼容性问题,毕竟官版和ffmpeg默认出来的不管哪边都能正常播放,如果tmod能作改进更好了

264768502
核心会员
核心会员
帖子: 402
注册时间: 2010-09-23 17:38

Re: x264 - 06_taro编译版(r2323+704)

2013-06-20 22:36

现在不知道,以前官版x264用mp4box来mux mp4的,如果真是l-smash的问题的话,这个估计没法让tmod做改进了

dwing
帖子: 2
注册时间: 2013-07-12 17:22

Re: x264 - 06_taro编译版(r2348+704)

2013-07-12 17:29

用过了最近的2348和之前的几个版本一段时间, 发现2个问题, 不知道是不是bug:
1. 用MediaInfo查片源(MKV)是固定帧率的, 但用这个版本的x264直接压成mp4后, 再查看MediaInfo却变成了可变帧率(VFR)
2. 片源同上, 压片时如果指定了--fps xxx并且带字幕, 压到有字幕的地方会崩溃, 看崩溃信息是VSFilter.dll导致的, 两个版本的VSFilter都会崩溃, 如果不加--fps就没问题

头像
Billy Herrington
帖子: 83
注册时间: 2013-01-09 9:54

Re: x264 - 06_taro编译版(r2348+704)

2013-07-13 0:08

matroska (by default) uses 1/1000s timebase, so for example the PTSes of 24000/1001fps videos will be:
0
41
83
125
...

thus the PTS*timebase is actually
0*(1/1000s)=0.000000,
41*(1/1000s)=41.000000ms,
83*(1/1000s)=83.000000ms,
125*(1/1000s)=125.000000ms
...


while mp4 normally won't touch timebase, so for the same example, mp4 stores 1/24000s as timebase, and uses 1001 as timebase-scale, so the PTSes are:
0
1
2
3
...

and the PTS*timebase*timescale is:
0*(1/24000s)*1001=0.000000ms
1*(1/24000s)*1001=41.708333ms
2*(1/24000s)*1001=83.416667ms
3*(1/24000s)*1001=125.125ms
...


Obviously, matroska's timestamp suffers rounding error when muxing, while mp4 don't. There is no harm if you only need to play matroska files, since 1ms precision is accurate enough for playbacks. But when doing mkv->mp4 re-muxing or re-encoding, x264 (or FFmpeg, or any other normal tools) reads 1/1000s timebase from matroska header, and tries to use it for mp4, passing the rounding error to mp4 which normally expects accurate timebase, making the mp4 header a bullshit. Not only tMod but also vanilla x264, FFmpeg, Libav and many tools have the same problem, which is definitely not a bug of them. It is quite clear to me that matroska should be blamed.

MediaInfo does not get accurate CFR/VFR info. Neither for matroska nor for mp4. However, it sometimes gets it right, by accident. Vanilla x264 uses GPAC to generate mp4 files, while tMod uses l-smash. Generally, GPAC is famous for its not always doing things according to specifications and using its own standards, but l-smash tries to be "Loyal to Spec of Mpeg4", even if sometimes the spec does not do MediaInfo a favour. If you want to find out whether an mp4 file is VFR or CFR, use DtsEdit to extract the timecodes_v1, the results is quite clear whether fps is only one line of constant value or jittered values. Or being more accurate for research, use boxdumper ( from l-smash packet ) to extract the raw mp4 header.

There are many ways to fix the jitter in matroska when outputing mp4. If you need to deal with timecodes, there is a tiny tool named tctool which intends to fix the jitter resaulted from rounding errors, converting
0
41
83
125
...

timecodes_v2 to
0
41.708333
83.416667
125.125000
...

or from
Assume 24.390244
0,0,23.809524
1,1,24.390244
2,4,23.809524
5,5,24.390244
...

timecodes_v1 to
Assume 23.976024
0,35007,23.976024

or doing v1<->v2 conversion in the same time. However, you might still need to specify --timebase to prevent x264 from reading from lavf/ffms/avs/y4m. Anyway, it is a good habbit to always tell x264 the timebase whenever one uses --tcfile-in.

If you don't need to bother with timecodes, it is much easier:

In x264, use --timebase 1001/24000 ( or 1001/120000, or 1001/360000, etc, according to your source ). For example: x264 --demuxer lavf --timebase 1001/24000 --output output.mp4 input.mkv. x264 will recalculate the timebase and PTS for you.

In FFmpeg/Libav, use -filter:v settb=1001/24000 when re-encoding. For example: ffmpeg -i input.mkv -filter:v settb=1001/24000 output.mp4.

Unfortunately, "settb" is a filter, and currently ffmpeg does not support applying filters when copying streams, so there's no easy way to remuxing mkv->mp4 in one step. I personally uses such method:
[syntax lang="winbatch"]ffmpeg.exe -i "input.mkv" -c copy "tmp.mp4"
DtsEdit.exe -tv 1 -o "tmp.tc" "tmp.mp4"
tctool.exe -v 2 "tmp.tc" > "tmp.tc2"
timelineeditor.exe --media-timebase 1001 --timecode "tmp.tc2" "tmp.mp4" "output.mp4"
[/syntax]It is rather easy to make a batch script.

Don't know about the crash in VSFilter. Seems to work good with --demuxer avs/y4m/raw --fps x, so might be a bug in vfr reading mode which lavf/ffms demuxer uses along with cfr outputing mode which --fps x forces.

dwing
帖子: 2
注册时间: 2013-07-12 17:22

Re: x264 - 06_taro编译版(r2359+704)

2013-09-02 21:56

tmod 2359 有严重bug: 使用默认ffms2解mp4/flv片源时, 会立即崩溃:
x264_32_tMod-8bit-all.exe 中的 0x00c56997 处未处理的异常: 0xC0000005: 读取位置 0x00000000 时发生访问冲突

而用ffms2解mkv, 或者lavf解任何格式, 或者使用2348版的ffms2都没问题

ssjck
帖子: 11
注册时间: 2012-03-11 23:34

Re: x264 - 06_taro编译版(r2359+704)

2013-09-04 18:03

我的2359 ffmpeg 还是ladv都没有上面问题,使用avs64mod 来pipe 使用64位的,32位没有试过

dreamgogo
帖子: 72
注册时间: 2013-01-12 11:25

Re: x264 - 06_taro编译版(r2359+704)

2013-09-08 23:24

我想问下 (r2359+704)这个版本,是F开头那个版本,在启动编码的时候,提示error can't open XXX.avs,请问是否需要什么插件或要求才能使用到,还是我参数设置错了?

ssjck
帖子: 11
注册时间: 2012-03-11 23:34

Re: x264 - 06_taro编译版(r2359+704)

2013-09-09 9:24

把avs内容贴出来才晓得哪错了

dreamgogo
帖子: 72
注册时间: 2013-01-12 11:25

Re: x264 - 06_taro编译版(r2359+704)

2013-09-09 12:29

ssjck 写了:把avs内容贴出来才晓得哪错了
原来新版不支持中文路径,改回数字或英文就可以了

头像
Billy Herrington
帖子: 83
注册时间: 2013-01-09 9:54

Re: x264 - 06_taro编译版(r2359+704)

2013-11-08 0:31

dwing 写了:tmod 2359 有严重bug: 使用默认ffms2解mp4/flv片源时, 会立即崩溃:
x264_32_tMod-8bit-all.exe 中的 0x00c56997 处未处理的异常: 0xC0000005: 读取位置 0x00000000 时发生访问冲突

而用ffms2解mkv, 或者lavf解任何格式, 或者使用2348版的ffms2都没问题
Try to rename those mp4/flv files with ASCII-only characters.

回到 “视频编码器 / Video encoder discussion”