x264: enhanced Avisynth input

[Dark Shikari]

You don't need Avisynth scripts anymore. At least not unless you're filtering.

$ ./x264 "c:\OldE\Sample X.Men.Origins.Wolverine.mkv" -o NUL
avs [info]: Trying FFmpegSource2... Indexing... succeeded
avs [info]: 1920x1080 @ 23.99 fps (1816 frames)

$ ./x264 "c:\OldE\LosslessKoishi.mkv" -o NUL
avs [info]: Trying FFmpegSource2... not found
avs [info]: Trying DSS2... succeeded
avs [warning]: converting input clip to YV12
avs [info]: 640x480 @ 60.00 fps (795 frames)

$ ./x264 "c:\OldE\vs720p.mpg" -o NUL
make: Nothing to be done for `all'.
avs [info]: Trying FFmpegSource2... not found
avs [info]: Trying DSS2... not found
avs [info]: Trying DirectShowSource... succeeded
avs [warning]: converting input clip to YV12
avs [info]: 1280x720 @ 59.94 fps (5138 frames)

$ ./x264 "c:\OldE\shortElephantsDream.avi" -o NUL
make: Nothing to be done for `all'.
avs [info]: Trying AVISource... succeeded
avs [info]: 1280x720 @ 24.00 fps (1001 frames)


Post questions and bug reports/issues here.

[Snowknight26]

Are fps values written as fractions when using this new input method or are they still written as decimals by default (like they have before unless you specified)?

[kemuri-_9]

General Comments:

1) Due to a limitation in the used Avisynth API, using Avisynth 2.6.x or higher will always result in the
avs [warning]: converting input clip to YV12
message to appear.

2) The patch supports and uses avisynth x64 when built for win64.
no, it does not magically bridge between x264 x64 and avisynth x86.
continue to use avs2yuv or w/e for this situation.

3) Failing to have avisynth installed or having a broken/superbly old build of it will result in the
avs [error]: failed to load avisynth
message to appear.

4) the oldest version of avisynth that is known to be supported is 2.5.5,
i did not try with older versions, they could very well be supported too.

[Dark Shikari]

Originally Posted by Snowknight26

Are fps values written as fractions when using this new input method or are they still writen as decimals by default (like they have before unless you specified)?

It blindly reads the fps num/denom from Avisynth.

[Audionut]

Built-in resizing would be nice.

[kemuri-_9]

Originally Posted by Snowknight26

Are fps values written as fractions when using this new input method or are they still writen as decimals by default (like they have before unless you specified)?

the original VFW interface to avisynth used fractional values, it just reported them as a decimal on the command line;
the same reporting format is used here.

the only difference is that avisynth automatically reduces the fps rate to relative primes, so x264 does not need to divide the numerator/denominator by their gcd like in the VFW version.

[kemuri-_9]

Originally Posted by Audionut

Built-in resizing would be nice.

A) which resizer? there's only about 9-11 of them depending on which avisynth you're using.

B) make a script for the purpose of anything beyond just opening a file, adding a filtering engine to x264 would just be needlessly cumbersome

[Audionut]

Originally Posted by kemuri-_9

A) which resizer?

Pointresize.

[ChronoCross]

Originally Posted by Audionut

Pointresize.

While we are at it we should add deen() to the default filtering

[buzzqw]

got some problem with ffmpegsource

avs [info]: Trying FFmpegSource2... not found

i have ffms2.dll (and ffmsindex.exe ) both in avisynth\plugins folder and in the same folder as x264 (that's the same folder of input)

any hint ?

EDIT:
one suggestion

add ffmpeg/mencoder as another source.
if dss/dss2/avisource/ffmpegsource.. if all fails
look if in folder is present ffmpeg/mencoder and use it to pipe raw to x264

that would be very handy

BHH

[G_M_C]

Originally Posted by Audionut

Built-in resizing would be nice.

Originally Posted by ChronoCross

While we are at it we should add deen() to the default filtering

Hmmm, basically you're almost asking DS to implement Avisynth into x264. I have the feeling that that he is not inclined to do that.

Slightly related; AVS is in the proces of updating to 2.6. That version includes more color-planes lyke YV16 (4:2:2) /YV22 (4:4:4). Might this new avs-input be the first step to implement broader chorma handling / wider color-planes in x264 ?

[Chikuzen]

I downloaded r1353 from x264.nl.
It can't output mp4.
The output file is rawfile.
mkv and flv seem to be no strange point.

[VFR maniac]

10L.

diff --git a/x264.c b/x264.c
index c857f58..0e7d728 100644
--- a/x264.c
+++ b/x264.c
@@ -545,7 +545,7 @@ static int select_output( char *filename, const char *pipe_format, x264_param_t
     if( !strcmp( filename, "-" ) )
         ext = pipe_format;

-    if( !strcasecmp( ext, ".mp4" ) )
+    if( !strcasecmp( ext, "mp4" ) )
     {
 #ifdef MP4_OUTPUT
         output = mp4_output; // FIXME use b_annexb=0

[JEEB]

Oh lol. So this is what the bug report on 2ch meant. Rebuilding.

[juGGaKNot]

I have 2.5.8 and i get

C:\x264\bin>x264 "C:\x264\movie.avi" -o NUL
avs [info]: Trying AVISource... succeeded
avs [warning]: converting input clip to YV12
avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.1
[32.1%] 473/1472 frames, 8.71 fps, 1992.08 kb/s, eta 0:01:54

Hmm or is 2.6.0 beta installed, weird.

also

C:\New Folder>x264 "C:\x264\movie.avi" -o lol.mp4
avs [info]: Trying AVISource... succeeded
avs [warning]: converting input clip to YV12
avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.1
mp4 [info]: initial delay 1 (scale 30)
[22.1%] 325/1472 frames, 9.68 fps, 1719.39 kb/s, eta 0:01:58

Is that normal ? delay ?

[MeteorRain]

curious

does it work with vfr material fine?

afaik roozhou's x264 builds support read timecodes from directshow interface.
ffmpeg supports vfr too, right? hmm...

anyway good job guys

[VFR maniac]

Originally Posted by juGGaKNot

Is that normal ? delay ?

That delay derives from B-frames, and it's normal.
If that annoy you,
1): insert EditBox/edts (EditListBox/elst).
2): set 0 on the first CTS offset and subtract it from the all CTSs with DTS hacking.

[roozhou]

@Dark Shikari

Is there any good of using an avisynth wrapper instead of directly reading from a DirectShow graph? FFMS2 also exports interface that allows a program to decode files and several programs are using it(e.g. AegiSub). And why do x264-devels stick to avisynth? With DSS you messed up with vfr file and those with inexactly fps in file header(e.g. 23.976fps VOBs show 29.97fps in DSS). You also lose AR information with avisynth but most dshow decoders will report it correctly.

@VFR maniac
Initial delay in mp4 and flv can be safely removed. IMO MPC-HC has problem dealing with initial delay.

[VFR maniac]

Originally Posted by roozhou

@VFR maniac
Initial delay in mp4 and flv can be safely removed. IMO MPC-HC has problem dealing with initial delay.

MPC-HC cannot play any flv videos removed initial decoding delay up to actual duration, but play up to duration MediaInfo gives.
MPC-HC's splitter is faithful about DTS+Offset and duration.

Originally Posted by MeteorRain

does it work with vfr material fine?

x264 does not parse their timestamps, so the encoded video is to become CFR.

[roozhou]

With MPC-HC initial delay is added to PTS and there will be AV async.