x264 loses frames

[medicina]

Hi,
I am using latest x264 version (x264 0.64.983M b4b6483) on my Linux system and trying to encode long video (2h) but in these cases I get frames loss in H264 stream (20-26 frames) and thus serious audio sync problems.

x264 is called with the following options:
--no-psnr --no-ssim --progress --threads auto --sar 1:1
--crf 26 --ref 3 --mixed-refs --bframes 16 --b-pyramid --bime
--weightb --direct auto --filter 1,1 --subme 6
--partitions p8x8,b8x8,i4x4 --me umh --merange 12

This is mplayer & x264 output:

MEncoder 1.0rc2-4.3 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) XP 2500+ (Family: 6, Model: 10, Stepping: 0)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

success: format: 0 data: 0x0 - 0x4681b49a
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO: [DX50] 512x384 24bpp 25.000 fps 1184.5 kbps (144.6 kbyte/s)
[V] filefmt:3 fourcc:0x30355844 size:512x384 fps:25.00 ftime:=0.0400
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
Opening video filter: [harddup]
Opening video filter: [format fmt=i420]
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2
VDec: vo config request - 512 x 384 (preferred colorspace: Planar YV12)
VDec: using Planar I420 as output csp (no 1)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
Pos: 2.1s 53f ( 0%) 30.98fps Trem: 0min 0mb A-V:0.000 [58982:0]
Pos:7333.8s 183367f (99%) 13.60fps Trem: 0min 51566mb A-V:0.000 [58982:0]]
Flushing video frames.

Video stream: 58982.400 kbit/s (7372799 B/s) size: 54070935552 bytes 7333.840 secs 183367 frames
x264 [info]: slice I:980 Avg QP:23.42 size: 15961
x264 [info]: slice P:154955 Avg QP:26.48 size: 2536
x264 [info]: slice B:27411 Avg QP:26.60 size: 574
x264 [info]: consecutive B-frames: 77.8% 5.9% 5.1% 5.9% 4.7% 0.4% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.1%
x264 [info]: mb I I16..4: 20.2% 0.0% 79.8%
x264 [info]: mb P I16..4: 1.6% 0.0% 1.7% P16..4: 43.3% 10.5% 9.1% 0.0% 0.0% skip:33.8%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 15.4% 1.1% 0.6% direct: 5.4% skip:76.9% L0:35.1% L1:53.5% BI:11.5%
x264 [info]: direct mvs spatial:98.8% temporal:1.2%
x264 [info]: ref P L0 89.0% 6.7% 4.2%
x264 [info]: ref B L0 84.7% 15.3%
x264 [info]: ref B L1 91.7% 8.3%
x264 [info]: kb/s:463.0

encoded 183346 frames, 13.60 fps, 463.02 kb/s

Any idea? x264 bug? :(
I am not 100% sure, but I think ffmpeg using libx264 works with these files.

[nm]

Post the full command lines of both MEncoder and x264 (apparently you are piping the video?).

How about using libx264 with MEncoder: http://forum.doom9.org/showthread.php?t=141378

[medicina]

Post the full command lines of both MEncoder and x264 (apparently you are piping the video?).


I have added some options probably unnecessary:

mencoder -mc 0 -nosound -noskip -ovc raw -of rawvideo -vf format=i420,harddup -o fifofile inputfile &
x264 [options, see above] --output outputfile fifofile [widthxheight]

But MEncoder prints the correct number of frames that matches the value of original file.


How about using libx264 with MEncoder: http://forum.doom9.org/showthread.php?t=141378

MEncoder test is in progress.

I confirm that FFmpeg & libx264 work as expected. I lose only 1 frame, probably the last frame. Instead, another mencoder+x264 test, but using x264 0.59.x, produces the same result then latest release.

[Comatose]

Are you losing frames from the start?
I have another PC where I lose about 20 frames off the start. I've tried figuring out why but really can't see it.

The lossless had the same amount of frames as the source, and the Avisynth avisource() script had the right amount of frames too, but after encoding there are 20 frames missing from the start.
I don't really care for encoding on that PC but I figured we might be able to find something in common.

[medicina]

I haven't familarity with tools to compare videos frame by frame, but I think 1 or more frames might be lost at whatever time. I see syncronization problems are in relation at file position, greater at end of file.

[medicina]

Well... x264 definitely doesn't want work, unlike FFmpeg and MEncoder in conjunction with libx264 and unlike Windows x264 version that uses AVIS input. I have tried to unset my CFLAGS variable to avoid compilation problem, and I enabled debug and changed encoding setting ("-B 200 --ref 1 --direct none --subme 1 --me dia --merange 8"). Nothing I see to fix this problem: frame: 162272, duration: 1h 48mn 10s 880ms; instead of: 162298, 1h 48mn 11s 920ms.

[nm]

He's only using MEncoder to decode the input video and then pipes it to x264 as raw YUV data.
The problem didn't occur when he used x264 through MEncoder (in which case b-frames are potentially a minor problem when using AVI output).

I'd suggest trying the same without piping (first decode to a raw file, then encode it), if there is enough disk space available. Or try "mplayer -vo yuv4mpeg" instead of mencoder. With yuv4mpeg you don't even need to write the frame dimensions to x264's command line.

[CruNcher]

Yes sorry misunderstood
i tried again with Mediacoder

mencoder.exe -quiet -of rawvideo -ovc raw -rawvidopts pipe=7 -ofps
29.970 -channels 2 -subcp cp1252 -sub-fuzziness 1 -subfont-autoscale 3 -subfont-
blur 2 -subfont-outline 2 -vf harddup,format=i420 -nosound "C:\x264\6238v1.wmv"
-o NUL

# ".\codecs\mencoder.exe" -demuxer rawvideo -rawvideo fps=2997/100:w=1280:h=720:
format=i420 pipe:8 -ovc x264 -x264encopts crf=26:level_idc=40:nodct_decimate:me=
hex:me_range=16:keyint=96:keyint_min=25:fast_pskip:scenecut=-1:deadzone_inter=11
:partitions=none:cabac:direct_pred=spatial:nomixed_refs:trellis=0:nobrdo:nobime:
nob_pyramid:nob_adapt:8x8dct:weight_b:bframes=2:threads=3:frameref=1:subq=6 -nos
ound -o "C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\mcstream1720.avi"

ahhh ok then its clear why Mediacoder still misses frames it uses .avi as intermediate how crazy is that :D

though both frameworks have the same problem Matroska (it uses AVI as intermediate) for MP4 it uses X264 with H.264 raw output as intermediate though both frameworks lose frames @ the end :(

i tried this now

mencoder.exe C:\x264\6238v1.wmv -nosound -ovc x264 -x264enc
opts crf=26:level_idc=40:nodct_decimate:me=hex:me_range=16:keyint=96:keyint_min=
25:fast_pskip:scenecut=-1:deadzone_inter=11:partitions=none:cabac:direct_pred=sp
atial:nomixed_refs:trellis=0:nobrdo:nobime:nob_pyramid:nob_adapt:8x8dct:weight_b
:bframes=2:threads=3:frameref=1:subq=1 -of rawvideo -o "C:\x264raw.264"

it's still losing 1 frame @ the end also it writes a complete wrong fps (1000) into the RAW file :(

[nm]

mencoder.exe C:\x264\6238v1.wmv -nosound -ovc x264 -x264enc
opts crf=26:level_idc=40:nodct_decimate:me=hex:me_range=16:keyint=96:keyint_min=
25:fast_pskip:scenecut=-1:deadzone_inter=11:partitions=none:cabac:direct_pred=sp
atial:nomixed_refs:trellis=0:nobrdo:nobime:nob_pyramid:nob_adapt:8x8dct:weight_b
:bframes=2:threads=3:frameref=1:subq=1 -of rawvideo -o "C:\x264raw.264"

it's still losing 1 frame @ the end also it writes a complete wrong fps (1000) into the RAW file :(
I don't know why it loses a frame, but fps is set to 1000 because that's how MPlayer/MEncoder handles ASF/WMV input which might have a variable framerate. Use -fps to override manually or extract timecodes and feed them to mkvmerge them when muxing to Matroska.

[CruNcher]

Thx nm though it seems to be a bug in mencoders demuxer at least for WMV input it loses 1 frame @ the end and yes it's to mark VFR streams all of them are shown as 1000 fps though not only that but it's also that way written into the final output stream :( you can avoid that currently by using the libavformat demuxer instead of the default asf demuxer that frame lose is also the case for mplayer.