x64 x264cli video filtering system problem

[quantum5uicid3]

i've gotten the same error repeatedly with all inputs with komisar's 1677kmod and jeeb's 1683 patched. can this be chalked up to ffmpeg's lack of x64 support or did i miss something? thank you all, you're awesome. :) source is bluray mkv's created by eac3to

did not even try unpatched builds because i've also come across the mp4+baseline issue. i have tried different x264 settings and resize values and the same result: dropped frames and the fllowing error.

>x264 --preset placebo --tune film --profile baseline --crf 20 --aq-mode 2 --me umh --level 3.1 --vf resize:856,480 --ref 5 --output o.mp4 i.mkv
ffms [info]: 1920x1080p 1:1 @ 24000/1001 fps (vfr)
resize [info]: resizing to 856x480
x264 [info]: using SAR=320/321
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Baseline, level 3.1
ffms [error]: could not read frame 1452961056.05 kb/s, eta 0:00:04
x264 [info]: frame I:2438 Avg QP:18.53 size: 23074
x264 [info]: frame P:142858 Avg QP:22.24 size: 5204
x264 [info]: mb I I16..4: 59.6% 0.0% 40.4%
x264 [info]: mb P I16..4: 1.2% 0.0% 1.0% P16..4: 37.6% 11.8% 0.4% 0.0% 0
.2% skip:47.7%
x264 [info]: coded y,uvDC,uvAC intra: 42.1% 41.1% 21.6% inter: 12.2% 8.0% 0.8%
x264 [info]: i16 v,h,dc,p: 55% 27% 2% 16%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 12% 6% 12% 16% 14% 13% 10% 9%
x264 [info]: i8c dc,h,v,p: 58% 21% 15% 6%
x264 [info]: ref P L0: 61.3% 17.6% 11.6% 4.8% 4.7%
x264 [info]: kb/s:1055.59

encoded 145296 frames, 18.20 fps, 1055.59 kb/s

[kemuri-_9]

i have tried different x264 settings and resize values and the same result: dropped frames and the fllowing error.

the ffms read error occurring at the end of the video is a side-effect of vfr pts handling when it tries to read past the end of the file stream - I will see what I can do to remedy this part.
but if the error is not occurring when trying to read past the end of the file stream, then your file is having issues being read.

the problem seems to that your source file is having issues being read by ffms or the ffmpeg underneath it.
you can alternately try to have it be read by the lavf reader by specifying --demuxer lavf and see if there's any differences.
you can also try to add --force-cfr to the parameters and see if there's any differences.

you say "I'm experiencing dropped frames" but aren't even explaining how you determined this.
(e.g. the expected frame count in x264cli is not how many frames are actually in your video)

At this point, I still think you're being hasty to blame the filtering system as the reason for your dropped frames issue.

[quantum5uicid3]

yeah, i'm sorry, i jumped the gun, i need to test more. the only thing i can conclusively say is that i have received that error on every file i've tried. this last file appears to be fine, watching on moto droid now :)

i only assumed dropped frames because on my first attempts, the audio ran longer than the video. (i'm no expert.)

[kemuri-_9]

i only assumed dropped frames because on my first attempts, the audio ran longer than the video. (i'm no expert.)

dropped frames is only one of the possibly causes of this.

another cause is when frames have the wrong duration. this can happen if
A) the input is VFR and has incorrect PTS for frames
B) the input is VFR but is read in as CFR (PTS are ignored)

[Snowknight26]

Happens a lot for Fraps videos too. lavf gives some error about how ffmpeg is unable to decode Fraps verions > 5 and says that this version is something absurd like 123.

[quantum5uicid3]

ok audio running longer was just a muxing error on my part sorry(25fps). the above error seems to be harmless, as it always coincides with the last frame encoded. to provide more info, ffms through the commandline is decoding one more frame than it does using avs on the same input and this is what is giving the error.

[kemuri-_9]

ok audio running longer was just a muxing error on my part sorry(25fps). the above error seems to be harmless, as it always coincides with the last frame encoded. to provide more info, ffms through the commandline is decoding one more frame than it does using avs on the same input and this is what is giving the error.

at least you discovered your problem.
there is a commit in Dark_Shikari's local tree to fix the ffms error being caused by attempts at reading frames beyond EOF,
I don't want more people getting worried about it unnecessarily.