x264: enhanced Avisynth input

[Dark Shikari]

You don't need Avisynth scripts anymore. (http://git.videolan.org/?p=x264.git;a=commit;h=380a201e8e8ba5a13022aeeeaf4b7501e1c79279) 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]

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]

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]

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]

A) which resizer?

Pointresize.

[ChronoCross]

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]

Built-in resizing would be nice.

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]

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]

@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.


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.

[poisondeathray]

got some problem with ffmpegsource

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 ?

Do you have the ffms2.avsi in the avisynth/plugins folder?

ffmpegsource() is a written function from the .avsi script that combines audiodub().

ffvideosource() and ffaudiosource() are the proper functions that come frome the ffms2.dll

[VFR maniac]

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

Oh yes, MPC-HC's mp4 splitter presents the frames at CTS but not PTS, while Haali's does them at PTS.
(though PTS doesn't exist in MP4's spec..., here PTS == CTS - initial delay.)
And MPC-HC doesn't support parsing edts.
Therefore, it is necessary to set 0 on the first CTS offsset and subtract it from the all CTSs for creating compatible AVsynced MP4 now.
DtsEdit and my tc2mp4Mod mount the algorithm.
BTW, MP4Box cannot give valid duration to VFR MP4 sometimes. This patch (http://www.esnips.com/doc/289dd010-e74d-4a19-8141-29f9185e91c1/gpac_fix_vfr_duration) fix this problem.

Already off topic... sorry.

[buzzqw]

that's good!

i missed the FFMS2.avsi in \plugins folder

thanks!

(even if i feel strange that this script is needed.. and x264 don't call directly ffmpegsource dll)

BHH

[roozhou]

Therefore, it is necessary to set 0 on their first CTS offsset for creating compatible AVsynced MP4 now.
DtsEdit and my tc2mp4Mod mount the algorithm.
I removed initial delay in x264's output modules and they work fine. For MP4 it only requires a big enough timescale. Mediainfo seems too lazy to compute and sort pts of each frame but shows weird framerates based on dts.

Also off topic. Stop here.

[Yoshiyuki Blade]

This is great! Now I don't have to create any more 1-liner scripts to encode lossless clips that are already prepared.

[kemuri-_9]

(even if i feel strange that this script is needed.. and x264 don't call directly ffmpegsource dll)

it was chosen to use ffms2 as an avs plugin this way for some off-in-the-future plans related to audio.

there is another patch that's been in the works by someone else to use FFMS2 and ffmpeg's libraries directly to decode files for use in x264cli.

[JoeH]

Whenever I use DirectShowSource to open up a VFR file, I need to add the FPS= and then convertfps=true to avoid audio-video sync problems.

Does this new version of X264 take care of this for us? Thanks.

[roozhou]

Whenever I use DirectShowSource to open up a VFR file, I need to add the FPS= and then convertfps=true to avoid audio-video sync problems.

Does this new version of X264 take care of this for us? Thanks.
Of course you have to write an avs script and add it yourself as I pointed out in the previous post.

Use this (http://85.230.118.136/showthread.php?t=141441) and you will produce a perfect vfr mp4/mkv/flv from an vfr source.

[buzzqw]

it was chosen to use ffms2 as an avs plugin this way for some off-in-the-future plans related to audio.

there is another patch that's been in the works by someone else to use FFMS2 and ffmpeg's libraries directly to decode files for use in x264cli.

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

thanks kemuri.

What do you think about my suggestion ?

thanks again

BHH

[kemuri-_9]

What do you think about my suggestion ?

I'm not particularly fond of the idea of having x264 spawn mplayer/ffmpeg processes on its own accord...
I think this would be best be left to the user to do on their own if none of the automated input methods work.

[buzzqw]

in that way (using ffmpeg/mencoder) an user could use x264.exe without avisynth installed...

and ffmpeg/mencoder is often update too (just to have a very good decoder always ready to use, as last line of defense)

just an idea

BHH

[LoRd_MuldeR]

You can use FFmpeg/MEncoder to decode the source and then pipe it directly into x264.exe ;)

There are no changes needed for that purpose on x264's side, as x264 already supports reading the input from STDIN.

[roozhou]

You can use FFmpeg/MEncoder to decode the source and then pipe it directly into x264.exe ;)

There are no changes needed for that purpose on x264's side, as x264 already supports reading the input from STDIN.

Why not just use Mencoder alone?

[buzzqw]

You can use FFmpeg/MEncoder to decode the source and then pipe it directly into x264.exe ;)

There are no changes needed for that purpose on x264's side, as x264 already supports reading the input from STDIN.

Why not just use Mencoder alone?

because using x264 alone is easier then remember how to pipe with mencoder/ffmpeg, and is easier then configure mencoder/ffmpeg to get the same options as x264
and public avaiable mencoder build aren't so often update.

BHH

[roozhou]

because using x264 alone is easier then remember how to pipe with mencoder/ffmpeg, and is easier then configure mencoder/ffmpeg to get the same options as x264
and public avaiable mencoder build aren't so often update.

BHH

But you have to remember how to deal with different sources by different scripts, installing various codecs, plugins and mux tools, solving annoying AV sync issues. With Mencoder a single executable does everything and it is cross-platform.

Since there is ffmpeg2theora, why not build a light-weighted ffmpeg2x264 or mencoder2x264?

[Dark Shikari]

But you have to remember how to deal with different sources by different scripts, installing various codecs, plugins and mux tools, solving annoying AV sync issues. With Mencoder a single executable does everything and it is cross-platform.

Since there is ffmpeg2theora, why not build a light-weighted ffmpeg2x264 or mencoder2x264?We're working on it.

[buzzqw]

thanks DS! :)

an ffmpeg2x264 or mencoder2x264 would be awesome!

BHH

[henryho_hk]

Since we have ffvideosource(), can we also have some new parameters to use its builtin post-processing, deinterlacing and resizing?

P.S. We are now making use of these builtin ff-facilities right at the ffvideosource() call with some parameter strings.

[kemuri-_9]

if you want any customization beyond just plainly opening up the file and possibly converting it to YV12 if not already,
then you'll need to create your own script.

[buzzqw]

would be possibile for x264 to search decoders (dgdecodec/ffmpegsource2/dss2 ...) not only in the avisynth plugins folder, but also in the same x264 folder or inputfolder and in PATH folders ?

BHH

[juGGaKNot]

So now its about
AVIsource() or whatever is needed
ConvertToYV12()

What about also adding
Crop(0, height%2, -width%2, 0)
Just in case the source is 1920x1081 for example ( this would crash the encode but if the crop was added it would be 1920x1080 and work )

To make sure any non mod2 resolutions are mod2, user error when rendering from NLE or other error alog the way.

[kemuri-_9]

would be possibile for x264 to search decoders (dgdecodec/ffmpegsource2/dss2 ...) not only in the avisynth plugins folder, but also in the same x264 folder or inputfolder and in PATH folders ?

no, that would involve x264 loading plugins itself and I don't want to have the hassle of looking around for the plugins to load.
use a script to load them yourself.

What about also adding
Crop(0, height%2, -width%2, 0)
Just in case the source is 1920x1081 for example ( this would crash the encode but if the crop was added it would be 1920x1080 and work )
A) attempting to use a non-mod2 resolutions does not crash the encode, there is already mod2 checks in place in x264 to prevent it from encoding with non-mod2 resolutions
- there was already one in the validate_parameters check
- and I added one in the avisynth input to prevent AVS 2.6 converting RGB to YV24 with the forced ConvertToYV12 call on non-mod2 resolutions

B) no, i'm not adding it because not everyone crops the same way.
use a script to crop the way you want.

[juGGaKNot]

I do not want to crop i just want to make sure the encode will not fail because of user error. cropping one pixel to make sure it encodes is needes, very few cases but stii needed

If the user wants to crop he will make a script but a mod2 automatic crop would be k ( again, only one pixel )

[DarkZell666]

I do not want to crop i just want to make sure the encode will not fail because of user error. cropping one pixel to make sure it encodes is needes, very few cases but stii needed

If the user wants to crop he will make a script but a mod2 automatic crop would be k ( again, only one pixel )

A user error has to be corrected by the user, not by the program IMHO.

[JoeH]

Of course you have to write an avs script and add it yourself as I pointed out in the previous post.

Use this (http://85.230.118.136/showthread.php?t=141441) and you will produce a perfect vfr mp4/mkv/flv from an vfr source.

Thanks a lot roozhou. I appreciate it.

[kemuri-_9]

If the user wants to crop he will make a script but a mod2 automatic crop would be k ( again, only one pixel )

there's 8 different ways of handling non-mod2 resolutions to make them mod2 compliant:
crop left/top
crop top/right
crop right/bottom
crop left/bottom
pad left/top
pad top/right
pad right/bottom
pad left/bottom

because they are numerous ways of fixing the issue, there's not one magically always correct way,
so it's up to the user to specify the way themselves.

on this point I may go back and add a stipulation to the ConvertToYV12 call to look at the user specified VUI settings to choose a matrix to convert with.