x264 cli bugreports

[Dracaena]

Ah. I had assumed that meGUI would have downloaded the most recent build.
I went and got rev1471 from x264.nl, and the error does not occur.

[nurbs]

The reason for that is that some defaults have recently changed in x264 and also the parameters the NAL-HRD patch takes have changed and those changes haven't been integrated into MeGUI yet. With the settings you use it doesn't make a difference, but with (like the old --nal-hrd option) it would lead to x264 giving an error massage. I guess they'll push a new one out with the next stable release.

[ajp_anton]

Isn't rc-lookahead also used for something with VBV even though mb-tree is off? Because when I do turn mb-tree off, x264 will always write "rc_lookahead=0" to the stream.

[b66pak]

hi,

there is a bug in the resize filter (tested with "x264 core:108 r1788 c764e29", "x264 core:107 r1772 c9dad9e"):

source: 704×528 (DAR 4:3, SAR 1:1)

destination: 480×270 (DAR 16:9, SAR 1:1)

my line:

"--vf resize:width=480,height=270,fittobox=both"

result:

lavf [info]: 704x528p 1:1 @ 25/1 fps (vfr)
resize [info]: resizing to 358x268
x264 [info]: using SAR=1/1

it should be:

resizing to 360×270

best regards…
_

P.S. last bug free build: "x264 core:107 r1766 f9f0035"

[kemuri-_9]

you had stated elsewhere/previously that the issue was only being exhibited in certain builds, (iirc it was only JEEBs builds)...
is the issue exhibiting itself in jarod's x264.nl builds (the x86 ones) as well now?

[b66pak]

yes...i am talking about x264.nl builds...
_

[kemuri-_9]

I looked into this previously when J_Darnley was poking me about it in between my battling with viruses on my pc.

the issue appears to be how gcc is optimizing the rounding routine used in the resize filter.
once i told gcc that it couldn't inline the function, the circumstances you provide give the expected 360x270 resolution rather than the unexpected 358x268 resolution.

i thought i had told J_Darnley this to have him confirm it some several days ago, but i never heard on this...

[Dark Shikari]

"Optimizing" does not affect output. Miscompilation does. If it's miscompiling, you should investigate what the difference is.

Just throwing NOINLINEs at the problem is not a solution.

[J_Darnley]

Why not just replace the problem code with the standard math functions of round() and trunc()?

[EDIT] http://pastebin.com/BUxKr4h2 This was just applied, I'm linking it so that anyone can use it now, if they need or wish to.

[b66pak]

if anyone need a vf resize bug free...Komisar (http://komisar.gin.by/) builds are OK...
_

[Maccara]

Why not just replace the problem code with the standard math functions of round() and trunc()?

Is round() guaranteed to have the same implementation on every system nowadays? I know it didn't use to.

[b66pak]

new set of tests with "x264 core:108 r1790 8eaf8a6" (x264.nl build)


line:
--vf resize:width=720,height=480,sar=32:27,fittobox=both

result:
lavf [info]: 720x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 404x480
x264 [info]: using SAR=32/27

lavf [info]: 960x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 540x480
x264 [info]: using SAR=32/27

lavf [info]: 1120x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 606x462 it should be 630x480
x264 [info]: using SAR=32/27

lavf [info]: 1280x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 606x404 it should be 720x480
x264 [info]: using SAR=32/27

lavf [info]: 1280x640p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 606x360 it should be 720x426
x264 [info]: using SAR=32/27


line:
--vf resize:width=720,height=480,sar=8:9,fittobox=both

result:
lavf [info]: 720x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 480x426 it should be 540x480
x264 [info]: using SAR=8/9

lavf [info]: 960x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 640x426 it should be 720x480
x264 [info]: using SAR=8/9

lavf [info]: 1120x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 720x410
x264 [info]: using SAR=8/9

lavf [info]: 1280x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 720x360
x264 [info]: using SAR=8/9

lavf [info]: 1280x640p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 720x320
x264 [info]: using SAR=8/9


line:
--vf resize:width=720,height=576,sar=64:45,fittobox=both

result:
lavf [info]: 720x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 404x576
x264 [info]: using SAR=64/45

lavf [info]: 960x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 506x540 it should be 540x576
x264 [info]: using SAR=64/45

lavf [info]: 1120x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 506x462 it should be 630x576
x264 [info]: using SAR=64/45

lavf [info]: 1280x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 506x404 it should be 720x576
x264 [info]: using SAR=64/45

lavf [info]: 1280x640p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 506x360 it should be 720x512
x264 [info]: using SAR=64/45


line:
--vf resize:width=720,height=576,sar=16:15,fittobox=both

result:
lavf [info]: 720x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 540x576
x264 [info]: using SAR=16/15

lavf [info]: 960x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 674x540 it should be 720x576
x264 [info]: using SAR=16/15

lavf [info]: 1120x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 674x462 it should be 720x494
x264 [info]: using SAR=16/15

lavf [info]: 1280x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 674x404 it should be 720x432
x264 [info]: using SAR=16/15

lavf [info]: 1280x640p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 674x360 it should be 720x384
x264 [info]: using SAR=16/15
_

[b66pak]

rounding errors still exists with "x264 core:108 r1790 8eaf8a6" and "x264 core:110 r1804 e89c4cf" (both x264.nl builds)

line:
--vf resize:width=720,height=528,sar=10:11,fittobox=both

result:
lavf [info]: 960x720p 1:1 @ 24/1 fps (vfr)
resize [info]: resizing to 704x478 it should be 704x480
x264 [info]: using SAR=10/11

_

[J_Darnley]

Why don't you guys try this: http://pastebin.com/wckZhxbr

And before you report any rounding errors, run the decimal math yourself.

[MasterNobody]

Why don't you guys try this: http://pastebin.com/wckZhxbr

And before you report any rounding errors, run the decimal math yourself.
Your variant will run out of the box with such params:
--vf resize:width=721,height=528,sar=10:11,fittobox=both --input-res 960x720
It will try to resize to 722x492

Here is my current patch: http://privatepaste.com/afda985c84 (also have cosmetics to error messages because "unsetxunset" looks ugly)

[J_Darnley]

>width=721
Now that sounds like a reason for an error message

[b66pak]

--vf resize:width=720,height=528,sar=10:11,fittobox=both --input-res 960x720

@MasterNobody with your patch i get 720x490 (sar=10:11)...players like MPC-HC or VLC display this like 720x538(9) (sar=1:1) witch defeat the conditions:

width=720,height=528,sar=10:11,fittobox=both

the correct result should be 704x480 (sar=10:11) displayed as 704x528 (sar=1:1)...
_

L.E. on a second look:

i was using:

--vf resize:width=720,height=528,sar=10:11,fittobox=both/pad:width=720,height=480 --input-res ANY

as a workaround for this (see up (http://forum.doom9.org/showthread.php?p=1460256#post1460256)):

--vf resize:width=720,height=480,sar=10:11,fittobox=both/pad:width=720,height=480 --input-res ANY

your patch fix it! so i will use it...

thanks a lot!
_

[MasterNobody]

--vf resize:width=72o,height=528,sar=10:11,fittobox=both --input-res 960x720

@MasterNobody with your patch i get 720x490 (sar=10:11)...players like MPC-HC or VLC display this like 720x538(9) (sar=1:1) witch defeat the conditions:

width=721,height=528,sar=10:11,fittobox=both

the correct result should be 704x480 (sar=10:11) displayed as 704x528 (sar=1:1)...
_
Why 704x528? Box limits coded resolution not the displaying resolution (the method of scaling in decoder can be any so we can't suppose anyone). So 720x490 is fully inside the limits of 720x528.

[b66pak]

hi,

i edited my post...see the L.E...actually the current implementation for fittobox is based on displaying resolution (no matter how you apply the sar the final result is in the box)! take look at my examples (http://forum.doom9.org/showthread.php?p=1460256#post1460256)!

704x480 (sar=10:11) can be displayed as 704x528 (sar=1:1) or 640x480 (sar=1:1) both in the box limits...
_

[MasterNobody]

hi,

i edited my post...see the L.E...actually the current implementation for fittobox is based on displaying resolution! take look at my examples (http://forum.doom9.org/showthread.php?p=1460256#post1460256)!
_
And this is incorrect because most of devices limits coded resolution not displaying IMHO. For displaying they can shrink instead of enlarge.

[b66pak]

this is my opinion too...sar should be applied only horizontal (like in tv sets or dvd players)...i am not defending the current implementation for fittobox...i explain it...
_

[J_Darnley]

fittobox works exactly as it should. You say "I need this resolution and sar" and that's what you get.

[rasmusb]

This is my first bug report for x264 so while I've tried my best to be precise and concise bear with me if the problem is on my end or I'm missing something obvious. That said, I sometimes experience a corrupted blocky or gray output from x264. From my experiments the problems occur when using --preset slow but goes away with --preset medium. I have found that "--preset fast --b-adapt 2 --rc-lookahead 50" is enough to provoke the error. I have isolated 150 frames (about 27MB) from the source which by itself will show the error at about frame 128. I have used both a recent ffdshow and dxva from MPC-HC to decode the stream with the same result. I have also tried encoding it on another computer with a fresh Windows 7 install with only Haali Splitter, ffdshow and AviSynth installed with the same result.

I have tested the following builds (all x86):
(from x264.nl) x264 core:112 r1834 a51816a - The bitstream freezes for about 15 frames and then the frame gets gray
(from komisar) x264 core:110 r1820 fdcf2ae - Same as above
(from x264.nl) x264 core:83 r1391 3d0f110 - The bitstream gets blocky for about 15 frames

The source stream can be found here: http://www.megaupload.com/?d=MCL8OF16


Example images:
http://i53.tinypic.com/2vajn08.jpg
x264.r1391 --b-adapt 2 --rc-lookahead 50

http://i56.tinypic.com/2u4j0cx.jpg
x264.r1834 --b-adapt 2 --rc-lookahead 50

http://i52.tinypic.com/21d0nl5.jpg
x264.r1834 --preset medium



The AviSynth script:
DirectShowSource("new.split.1.m2ts", fps=23.976, audio=false, convertfps=true)

Log for x264.nl r1834:
x264 --b-adapt 2 --rc-lookahead 50 -o out.mp4 00009_demux.avs

avs [info]: 1920x1080p 0:0 @ 2500000/104271 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:2 Avg QP:21.07 size: 97845
x264 [info]: frame P:58 Avg QP:21.22 size: 30003
x264 [info]: frame B:92 Avg QP:26.31 size: 17763
x264 [info]: consecutive B-frames: 16.0% 1.3% 16.0% 66.7%
x264 [info]: mb I I16..4: 24.9% 55.8% 19.3%
x264 [info]: mb P I16..4: 1.8% 5.5% 1.4% P16..4: 20.1% 6.1% 3.5% 0.0% 0.0% skip:61.6%
x264 [info]: mb B I16..4: 0.6% 1.6% 0.5% B16..8: 39.5% 4.7% 1.2% direct: 2.2% skip:49.8% L0:42.4% L1:51.2% BI: 6.3%
x264 [info]: 8x8 transform intra:61.1% inter:73.1%
x264 [info]: coded y,uvDC,uvAC intra: 65.4% 31.2% 5.0% inter: 12.1% 4.2% 0.0%
x264 [info]: i16 v,h,dc,p: 47% 22% 11% 20%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 12% 18% 6% 11% 11% 10% 7% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 14% 18% 6% 12% 11% 10% 6% 7%
x264 [info]: i8c dc,h,v,p: 65% 16% 17% 2%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 59.4% 14.2% 19.2% 7.1%
x264 [info]: ref B L0: 90.3% 7.7% 2.0%
x264 [info]: ref B L1: 96.1% 3.9%
x264 [info]: kb/s:4505.08

encoded 152 frames, 5.64 fps, 4505.94 kb/s

[JEEB]

Do not confirm.

Got the sample, used my 1834 patched build as well as the 64bit pure build that gets put on x264.nl, read with x264's ffms input as the source is progressive H.264. Output was practically the same.

x264 new.split.1.m2ts --b-adapt 2 --rc-lookahead 50 -o out.mp4
ffms [info]: 1920x1080p 1:1 @ 24000/1001 fps (vfr)
mp4 [info]: audio muxing feature is disabled.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:2 Avg QP:21.12 size: 97010
x264 [info]: frame P:42 Avg QP:23.46 size: 44139
x264 [info]: frame B:109 Avg QP:26.32 size: 16754
x264 [info]: consecutive B-frames: 0.7% 1.3% 23.8% 74.2%
x264 [info]: mb I I16..4: 25.5% 55.9% 18.7%
x264 [info]: mb P I16..4: 2.7% 7.5% 1.8% P16..4: 33.9% 10.2% 5.9% 0.0% 0.0% skip:37.9%
x264 [info]: mb B I16..4: 0.2% 1.0% 0.3% B16..8: 40.2% 4.7% 1.2% direct: 2.1% skip:50.3% L0:42.6% L1:51.5% BI: 5.9%
x264 [info]: 8x8 transform intra:61.8% inter:72.7%
x264 [info]: coded y,uvDC,uvAC intra: 66.0% 30.5% 4.0% inter: 14.2% 4.5% 0.0%
x264 [info]: i16 v,h,dc,p: 45% 25% 10% 20%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 12% 16% 6% 12% 12% 10% 8% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 14% 17% 6% 13% 12% 10% 6% 7%
x264 [info]: i8c dc,h,v,p: 64% 17% 17% 2%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 57.9% 14.9% 19.2% 8.0%
x264 [info]: ref B L0: 89.0% 8.7% 2.3%
x264 [info]: ref B L1: 94.8% 5.2%
x264 [info]: kb/s:4856.70

remux [100.00%], 3787/3787 KiB, 378722 KiB/s, total elapsed 0:00:00

encoded 153 frames, 3.47 fps, 4857.59 kb/s


Output file: clicky (http://www.mediafire.com/?fi6jxei4jabobwg)

Seems fine as far as I'm concerned, tested with both a libav*-based decoder as well as CoreAVC's VPx-based decoder. Doesn't seem to be a bug with x264, but with your input (It could also be the playback setup you use to play the output, but I'm betting on the first option as you seem to be using DirectShowSource).

I would like to mention here, that although DirectShowSource _does_ come with Avisynth, it surely isn't the best way of loading your sources. It isn't frame-exact in any way and is prone to whatever errors you might have in your DirectShow setup (as it uses DirectShow filter chains for input). Please try another way of input, f.ex. x264's ffms input, the ffmpegsource Avisynth plugin, or even the DSS2 plugin by Haali, which is pretty good on things that Haali's splitter splits as long as you have your DirectShow environment in a good condition and Haali's splitters installed for the container format you want to load (although I had visual corruption with DSS2 on Haali's splitters >=2010/05/20). Not to mention the H.264-related tools by Neuron2.

For MPEG-2 sources there are other plugins to load such streams via d2v files.

[rasmusb]

Thanks for your quick reply!

The problem goes away when using the .m2ts directly as you did (is this ffms input?). The problem is still there when I tried dss2. I use a recent Haali splitter, definately >=2010/05/20.

The reason I've been using DirectShowSource is that I've been using MeGUI and that's how it works. I'll do the video encoding from the command line until I find a way that works from the GUI.

Thanks again for your help!

[nurbs]

MeGUI comes with ffmpegsource (ffms). Use the file indexer and load the index that it produces in the Avisynth script generator.

[b66pak]

can you please investigate the HUGE timescale/timebase problem described here (http://forum.doom9.org/showthread.php?p=1479455#post1479455)?
_

[kemuri-_9]

can you please investigate the HUGE timescale/timebase problem described here (http://forum.doom9.org/showthread.php?p=1479455#post1479455)?
_

post your sample with the retarded timebase.

[b66pak]

here (http://www.mediafire.com/?dqr1ff7abcj8b8j) is a small sample...
_

[magic144]

Just been looking at an issue over at Donald Graft's forum...

There is a weird stuttering issue when trying to encode a particular clip from a BBC disc, using a script that involves DGSource() and srestore()...

I've uploaded all the relevent files for this issue here:-

http://www.mediafire.com/?e8s6eqse62n8u


It seems as if x264 is dropping some frames somehow?
If I load the (METHOD 2) test.avs script into VirtualDub, I can generate an .avi (HuffyYUV) with perfectly smooth playback.
I have also since discovered that if I use x264vfw from within VirtualDub, I can produce an .avi (h.264) with perfectly smooth playback (BUT ONLY if VirtualDub Hack is selected).

Here is the info on my initial experiment/findings describing the stuttering issue...


----

Source video clip is opening 30s of episode, video30s.mkv.
Index clip using DGIndexNV => video30s.dgi

2 approaches to encoding same clip:
METHOD 1. Convert via Huffyuv intermediate.

Convert the clip into a Huffyuv .avi using this script,
---huffy.avs---
LoadPlugin("C:\Users\User\Desktop\dgdecnv2038\DGDecodeNV.dll")
DGSource("video30s.dgi")
TRIM(0,150)
---
This produces (via VirtualDub using ffdshow/HuffYUV) video30s-huffy150fr.avi.

Now use a second script to encode to h.264.
NB the video30s-huffy150fr.grf file is produced using MONOGRAM GraphStudio (v0.3.2.0 Beta), just rendering video30s-huffy150fr.avi via FileSource (Async.), AVI Splitter and ffdshow (rev3721).
---testhuffy.avs---
Import("Srestore.avsi")
LoadPlugin("mt_masktools-26.dll")
LoadCplugin("C:\Program Files\MeGUI\tools\yadif\yadif.dll")
DirectShowSource("video30s-huffy150fr.grf",audio=false)
AssumeFPS(30000,1001) # as per source
yadif(mode=1,order=1)
srestore(frate=25,speed=-1)
---
This produces testhuffy-muxed.mkv, which plays back smoothly.


METHOD 2. Use this more straightforward script.
---test.avs---
LoadPlugin("C:\Users\User\Desktop\dgdecnv2038\DGDecodeNV.dll")
Import("Srestore.avsi")
LoadPlugin("mt_masktools-26.dll")
LoadCplugin("C:\Program Files\MeGUI\tools\yadif\yadif.dll")
DGSource("video30s.dgi")
yadif(mode=1,order=1)
srestore(frate=25,speed=-1)
TRIM(0,125) #125 is 150*5/6
---
This produces (via MeGUI) test-muxed.mkv. As you can see, there is a noticeable temporal stutter at the start of playback.


The question is, what induces the initial stuttering in approach 2. This is the preferred approach since it doesn't involve a very large intermediate file! Something, however, is not "playing nice".


FYI...

Command lines MeGUI generates when encoding the clips:-
----
"C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --preset slow --crf 20 --no-dct-decimate --sar 1:1 --output "D:\Temp\_org\Stutter\testhuffy.264" "D:\Temp\_org\Stutter\testhuffy.avs"
"C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --preset slow --crf 20 --no-dct-decimate --sar 1:1 --output "D:\Temp\_org\Stutter\test.264" "D:\Temp\_org\Stutter\test.avs"

Srestore() is found here:-
http://avisynth.org/mediawiki/Srestore
also requires Masktools2, found here:-
http://avisynth.org/mediawiki/MaskTools2



MASSIVE thanks if anybody can pinpoint what is going wrong here!
I'd like to use x264.exe CLI as I have always used it in the past without issue...

[kemuri-_9]

here (http://www.mediafire.com/?dqr1ff7abcj8b8j) is a small sample...
_

with an altered version of x264cli to get more output:


$ ./x264 -o ffms.mkv "F:\Download\sample\sample.mkv" --tcfile-out ffms_tc.txt && mv pts.txt ffms_raw_pts.txt
ffms [info]: 1280x532p 1:1 @ 23999/1001 fps (vfr)
ffms [info]: timebase = 1/1000000000



# timecode format v2
0.000000
42.000000
84.000000
125.000000
167.000000
209.000000



0
42000000
84000000
125000000
167000000
209000000



$ ./x264 -o lavf.mkv "F:\Download\sample\sample.mkv" --demuxer lavf --tcfile-out lavf_tc.txt && mv pts.txt lavf_raw_pts.txt
[matroska,webm @ 003fc330] Estimating duration from bitrate, this may be inaccurate
lavf [info]: 1280x532p 0:1 @ 24000/1001 fps (vfr)
lavf [info]: timebase = 1/1000



# timecode format v2
0.000000
42.000000
84.000000
125.000000
167.000000
209.000000



0
42
84
125
167
209


Overall lesson of the story (or simply TL;DR):
ffms outputs PTS that are 1,000,000x larger than lavf, so it needs a 1,000,000x larger timebase denominator.
(1000 of the final 1billion is x264cli compensating for ffms's large PTS output values)

though this behavior is only exclusive to mkvs with ffms's internal demuxer, as ffms has it's own mkv demuxer separate of lavf's.

There was recently some API added to ffms to support forcing the demuxer, but it's not used by x264cli, so ffms defaults to its internal mkv demuxer here.

[b66pak]

thank you for the explanation...
_

[b66pak]

it looks like lavf demuxer can deliver HUGE timescale/timebase too! (for .avi)...

example one:

mediainfo:
Format : AVI
Format/Info : Audio Video Interleave
File size : 349 MiB
Duration : 44mn 2s
Overall bit rate : 1 108 Kbps
Writing application : VirtualDubMod 1.5.10.2 (build 2540/release)
Writing library : VirtualDubMod build 2540/release

Video
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Muxing mode : Packed bitstream
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 44mn 2s
Bit rate : 966 Kbps
Width : 640 pixels
Height : 352 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.179
Stream size : 304 MiB (87%)
Writing library : XviD 1.2.1 (UTC 2008-12-04)

ffmpeg info:
Seems stream 0 codec frame rate differs from container frame rate: 23.98 (65535/2733) -> 23.98 (10000000/417083)

x264 lavf info:
lavf [info]: 640x352p 1:1 @ 10000000/417083 fps (vfr)

resulting mp4 (x264 gpac muxer) mp4box info:
Track # 1 Info - TrackID 1 - TimeScale 10000000 - Duration 00:00:41.708

_

[b66pak]

example two:

mediainfo:
Format : AVI
Format/Info : Audio Video Interleave
File size : 350 MiB
Duration : 42mn 32s
Overall bit rate : 1 149 Kbps
Writing application : transcode-1.0.6

Video
IFormat : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 2
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 42mn 32s
Bit rate : 991 Kbps
Width : 624 pixels
Height : 352 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.188
Stream size : 301 MiB (86%)
Writing library : XviD 1.2.1 (UTC 2008-12-04)

ffmpeg info:
Seems stream 0 codec frame rate differs from container frame rate: 23.98 (65535/2733) -> 23.98 (2997003/125000)

x264 lavf info:
lavf [info]: 624x352p 1:1 @ 2997003/125000 fps (vfr)

resulting mp4 (x264 gpac muxer) mp4box info:
Track # 1 Info - TrackID 1 - TimeScale 2997003 - Duration 00:00:41.708
_

[b66pak]

example three:

mediainfo:
Format : AVI
Format/Info : Audio Video Interleave
File size : 350 MiB
Duration : 41mn 53s
Overall bit rate : 1 168 Kbps
Writing application : transcode-1.0.4

Video
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 2
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 41mn 53s
Bit rate : 999 Kbps
Width : 624 pixels
Height : 352 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.190
Stream size : 299 MiB (86%)
Writing library : XviD 1.2.1 (UTC 2008-12-04)

ffmpeg info:
Seems stream 0 codec frame rate differs from container frame rate: 23.98 (24000/1001) -> 23.98 (2997003/125000)

x264 lavf info:
lavf [info]: 624x352p 1:1 @ 24000/1001 fps (vfr)

resulting mp4 (x264 gpac muxer) mp4box info:
Track # 1 Info - TrackID 1 - TimeScale 2997003 - Duration 00:00:41.708
_

[b66pak]

it will be nice o see timebase info in the vanilla builds too!

ffms [info]: timebase = 1/1000000000

lavf [info]: timebase = 1/1000
_

[kemuri-_9]

all these timebase issues you keep coming with seem to be arising from the fact that you are using files that are likely encoded from avisynth where directshowsource was used (it causes very VERY terrible fps without AssumeFPS usage)

use --fps on these .avi files to correct the framerate, they're not vfr anyway.

[b66pak]

how about lavf & ffms (or maybe x264) forcing timebase to 1/1000 (or 1/10000 if more precision is needed - my personal opinion is that miliseconds (1/1000) are enough) when HUGE timescale/timebase are detected?
_

[b66pak]

or even better, like this:

new_timebase = 1000/[int(1000/huge_timebase)]

for example one:

new_timebase = 1000/[int(1000/(417083/10000000)] = 1000/23976 = 125/2997

for example two & three:

new_timebase = 1000/[int(1000/(125000/2997003)] = 1000/23976 = 125/2997
_

[kemuri-_9]

it should be the user's job to handle quirks such as these in their input.

also, these avis are bad examples to prove a point with, use --fps on them.

[Juce]

x264 crashes with this:
x264 -q 0 -o video.mp4 checkerboard1280x720.avs

This works:
x264 -q 0 -o video.mkv checkerboard1280x720.avs

checkerboard1280x720.avs
ImageSource("checkerboard1280x720.png", 0, 49, 25)

checkerboard1280x720.png (http://img193.imageshack.us/img193/3010/checkerboard1280x720.png)

[LoRd_MuldeR]

x264 crashes with this:
x264 -q 0 -o video.mp4 checkerboard1280x720.avs

This works:
x264 -q 0 -o video.mkv checkerboard1280x720.avs

Might be related or not:
https://github.com/DarkShikari/x264-devel/commit/a073bb87aa56dab04829bb470d6e8dad7a6112e2

[kemuri-_9]

Might be related or not:
https://github.com/DarkShikari/x264-devel/commit/a073bb87aa56dab04829bb470d6e8dad7a6112e2

yes, that commit is to fix the reported issue.

[Juce]

Something wrong with dithering and/or colorspace conversion.

Encoding without dithering:
x264 rgb48.raw -o video1.mkv --demuxer raw --input-csp rgb --input-depth 16 --input-res 1280x720 --fps 25 --preset slow -q 0 --vf resize:,,,,yv12:8
raw [info]: 1280x720p 0:0 @ 25/1 fps (cfr)
resize [warning]: converting from rgb48le to yuv420p
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile High 4:4:4 Predictive, level 3.1, bit depth 8
x264 [info]: frame I:1 Avg QP: 0.00 size: 30762
x264 [info]: frame P:9 Avg QP: 0.00 size: 21888
x264 [info]: mb I I16..4: 98.5% 1.5% 0.0%
x264 [info]: mb P I16..4: 23.6% 1.4% 0.0% P16..4: 59.2% 1.3% 0.2% 0.0% 0
.0% skip:14.2%
x264 [info]: 8x8 transform intra:4.4% inter:89.1%
x264 [info]: coded y,uvDC,uvAC intra: 66.4% 72.2% 71.2% inter: 27.7% 64.7% 63.7%

x264 [info]: i16 v,h,dc,p: 56% 43% 1% 0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 5% 7% 52% 11% 8% 3% 5% 5% 3%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 0% 100% 0% 0% 0% 0% 0% 0%

x264 [info]: i8c dc,h,v,p: 32% 43% 25% 0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 96.2% 0.0% 3.6% 0.2% 0.0% 0.0%
x264 [info]: kb/s:4555.10

encoded 10 frames, 4.57 fps, 4565.54 kb/s

Encoding with dithering:
x264 rgb48.raw -o video2.mkv --demuxer raw --input-csp rgb --input-depth 16 --input-res 1280x720 --fps 25 --preset slow -q 0
raw [info]: 1280x720p 0:0 @ 25/1 fps (cfr)
resize [warning]: converting from rgb48le to yuv420p16le
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile High 4:4:4 Predictive, level 3.1, bit depth 8
x264 [info]: frame I:1 Avg QP: 0.00 size: 68428
x264 [info]: frame P:9 Avg QP: 0.00 size: 53652
x264 [info]: mb I I16..4: 98.4% 1.5% 0.0%
x264 [info]: mb P I16..4: 10.6% 1.0% 0.0% P16..4: 79.7% 3.4% 2.3% 0.0% 0
.0% skip: 3.0%
x264 [info]: 8x8 transform intra:5.0% inter:86.2%
x264 [info]: coded y,uvDC,uvAC intra: 64.5% 92.5% 92.3% inter: 28.2% 94.8% 94.6%

x264 [info]: i16 v,h,dc,p: 60% 39% 1% 0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 4% 7% 54% 12% 7% 3% 6% 5% 3%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 0% 100% 0% 0% 0% 0% 0% 0%

x264 [info]: i8c dc,h,v,p: 73% 8% 14% 5%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 87.6% 0.0% 8.7% 2.1% 1.0% 0.5%
x264 [info]: kb/s:11025.84

encoded 10 frames, 3.25 fps, 11036.28 kb/s

The bitrate increases but banding looks the same.

without dithering: http://img39.imageshack.us/img39/5747/video1i.png
with dithering: http://img198.imageshack.us/img198/811/video2a.png
orginal: http://img688.imageshack.us/img688/6218/frame000.png

rgb48.raw: http://www.mediafire.com/file/hbpe09m0u04v3g5/rgb48.raw

[b66pak]

starting with 1947 build the .mp4 output OOS...tested with:

x264 core:115 r1947 b5a8ad7 - gpac (x264.nl)

x264 0.115.1947+524M_L-SMASH a8e6471 - l-smash (x5-452 build)

x264 core:115 r1947+532 361db68 - l-smash (fushizen build)

x264 core:115 r1947kMod b5a8ad7 - gpac (komisar build)


my line:
x264 --profile main --level 3 --weightp 0 --ref 3 --b-pyramid 0 --no-weightb --vbv-maxrate 10000 --vbv-bufsize 10000 -o video4psp.mp4 video4psp.avs
_

[komisar]

b66pak, my clear build with "old-golgol777" gpac, kMod-build with l-smash. (and you test 32/64-bit?)

[b66pak]

tested the clear build too...the tests are for 32bit builds...i don't think is the muxers (gpac or l-smash) because are both affected...if i demux the resulting .mp4 to raw h264 and remux it again to mp4 the problem is gone...
_

[komisar]

b66pak, is the 1936 version is clear?

[b66pak]

sorry...if found that it is a problem for some media players unable to deal with .mp4 files created without "--dts compress"...adding "--dts compress" to the encoding line fixed the issue...
_

[upyzl]

Excuse me for my offensiveness

I think --merange should be restricted when using --me umh/esa/tesa

now --merange can be set to 2^31-1 (int upper limit), but it easily causes x264.exe crash because of user's RAM(maybe...)

and also, higher merange doesn't mean higher PSNR/SSIM(especially >64), so it really no need to use very high merange, then restrict it should have no side-effect

pic shot:http://i.imgur.com/61WCQ.png