x264 Avisynth input

[Dark Shikari]

$ ./x264_avs.exe e:\LosslessKoishi.mkv -o test.mkv
avs [info]: Trying AVISource... failed
avs [info]: Trying FFmpegSource2... failed
avs [info]: Trying FFmpegSource... not found
avs [info]: Trying DirectShowSource... succeeded
avs [info]: 640x480 @ 60.00 fps (795 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
[10.3%] 82/795 frames, 17.21 fps, 3559.24 kb/s, eta 0:00:41






(thoughts?)

[Inspector.Gadget]

This looks very useful for tasks where you need only a source filter...saves prep time, certainly.

Edit: and I concur with LM immediately below about maybe adapting to the extension of the input file; at worst it will foul up a few newbies who shouldn't be using common file extensions for the wrong types anyway...

[LoRd_MuldeR]

1. Maybe try DSS2() before falling back to "normal" DirectShowSource?

2. What about MPEG2Source() and AVCSource() for .d2v and .dga files?

[kemuri-_9]

this is a patch i'm working on,
i just haven't gotten around to checking or commenting on d9 about it. :cool:

but I'm open to suggestions on what extensions map to what filter or filter sequence.

though i'll probably just keep ffmpegsource, ffmpegsource2, DSS2, and DSS as a list of 'all purpose filters' to try if none of the specific ones work

the exact details of the patch is to interface with the avisynth scripting engine directly, which can allow such things as
1. pick-and-choose on input filters for non-scripts (what we see above)
2. better error detection in general: i.e. you typo'd your script at x
3. automatic YV12 conversion

[ajp_anton]

What about:

x264.exe --script "avisource(^d:\video.avi^).bob().morefilters" -o out.mkv

[Dark Shikari]

What about:

x264.exe --script "avisource(^d:\video.avi^).bob().morefilters" -o out.mkvWay too complicated. Just save an Avisynth script if you want to do that.

[kemuri-_9]

something like that would have to be done in 1 of 2 ways:

1) write the script to a file and import that as normal
2) implement a parser to handle it properly through the avs interface.

i'm not going to do 2) and 1) would be just as easily done by the user with something like

echo "avisource(^d:\video.avi^).bob().morefilters" > script.avs && x264.exe script.avs -o out.mkv

[Kurtnoise]

what happens when none source filters are able to open the input file ?

[juGGaKNot]

Great, i only need AVISource since all i use is uncompressed 4:4:4 rgb

[LoRd_MuldeR]

Great, i only need AVISource since all i use is uncompressed 4:4:4 rgb

Then you still need a create "custom" Avisynth script, unless x264 automatically appends ConvertToYV12() to AVISource() ;)

[smok3]

x264 file.avi
and/or
x264 --optional template.avs file.avi
and/or
x264 --optional template.avs --force 'intermediate uncompressed thingy when directshowsource is selected' file.avi

where template could be:
yadif(0)
fancyresize(576,320)
#this part is for x264 only:
# sar 1243:3487
# bitrate 2340


p.s.
i'd actually prefer some easy to use way to pipe ffmpeg input with all the filters ffmpeg has (that should also be usefull on more that just windows).

dunno, something like
x264 'pipe from ffmpeg if there is one in the system and also use deinterlace and crop ffmpeg filters' file.avi

[J_Darnley]

Then you still need a create "custom" Avisynth script, unless x264 automatically appends ConvertToYV12() to AVISource() ;)
It will, and it will warn you that it does so.

[kemuri-_9]

It will, and it will warn you that it does so.

yes, it warns like:

$ echo "version()" > version.avs && ./x264.exe -o version.mkv version.avs
avs [warning]: converting input clip to YV12
avs [info]: 428x80 @ 24.00 fps (240 frames)
x264 [warning]: width or height not divisible by 16 (428x80), compression will suffer.
...



Oh and since ConvertToYV12 has an interlaced param, i've made it use b_interlaced as the value for it,
so --interlaced will have avisynth use the interlaced resizers here instead of the assumed progressive ones.


what happens when none source filters are able to open the input file ?

this is easily displayed with my avs environment where i've disabled plugin autoloading:

$ ./x264.exe -o version.mp4 version.mkv
avs [info]: Trying FFmpegSource2... not found
avs [info]: Trying FFmpegSource... not found
avs [info]: Trying DSS2... not found
avs [info]: Trying DirectShowSource... not found
avs [error]: unable to find source filter to open 'version.mkv'
x264 [error]: could not open input file 'version.mkv'


p.s.
i'd actually prefer some easy to use way to pipe ffmpeg input with all the filters ffmpeg has (that should also be usefull on more that just windows).

dunno, something like
x264 'pipe from ffmpeg if there is one in the system and also use deinterlace and crop ffmpeg filters' file.avi

actually there's another patch in the works to have x264 use ffmpeg's framework to open files through it as well, so this would work well for linux.

btw the error reporting is more useful for those script users (which is most of everyone)


$ echo "version(" > version.avs && ./x264.exe -o version.mkv version.avs
avs [error]: Script error: syntax error
(version.avs, line 1, column 0)
x264 [error]: could not open input file 'version.avs'

[TheFluff]

something like that would have to be done in 1 of 2 ways:

1) write the script to a file and import that as normal
2) implement a parser to handle it properly through the avs interface.

3) eval()

[kemuri-_9]

3) eval()

yes i had originally forgotten about eval when i wrote that post,
however, x264 currently and even with the patch in its current form decides on which input demuxer to try based purely on the input filename
i'm not fond of altering this system to where it can be excepted by some other option.

[Keiyakusha]

I read somewhere that with avisynth 2.6 x264 always shows warning about converting to yv12. Don't remember where I read these, but why this happening? It's impossible to check avisynth version somehow and disable this warning?

[kemuri-_9]

I read somewhere that with avisynth 2.6 x264 always shows warning about converting to yv12. Don't remember where I read these, but why this happening? It's impossible to check avisynth version somehow and disable this warning?

the message is because it IS doing a version check and compensating for the lack of some colorspace identification capability in the utilized api.

[Keiyakusha]

maybe I don't understand the whole thing, but why not disable any kind of colorspace conversion when the input is an .avs script?

[LoRd_MuldeR]

maybe I don't understand the whole thing, but why not disable any kind of colorspace conversion when the input is an .avs script?

...because x264 is limited to the YV12 colorspace. But there's absolutely no guarantee that the source is in that color format!

In case x264 opens a custom .avs script, it could simply reject the file, if the final output isn't YV12. So the user would have to append ConvertToYV12() to the .avs file himself.

However you can now (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=380a201e8e8ba5a13022aeeeaf4b7501e1c79279) simply throw an arbitrary media file on x264 and it will built the required Avisynth script automatically. x264 will also append ConvertToYV12(), if that may be needed.

Last but not least note that appending ConvertToYV12() never hurts, because ConvertToYV12() is a NOP, if applied on a YV12 clip...

[Keiyakusha]

...because x264 is limited to the YV12 colorspace. But there's absolutely no guarantee that the source is in that color format!

But IMHO its better to throw an error. For example I don't care about colorspace if all that I want is to specify input file and get my encode. But if .avs has non-YV12 colorspace as output it means something wrong on my side and I don't want to start the encode. Someone also may or may not want to do this conversion in some special way.

EDIT:

In case x264 opens a custom .avs script, it could simply reject the file, if the final output isn't YV12. So the user would have to append ConvertToYV12() to the .avs file himself.
Yes. This would be great.


However you can now (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=380a201e8e8ba5a13022aeeeaf4b7501e1c79279) simply throw an arbitrary media file on x264 and it will built the required Avisynth script automatically. x264 will also append ConvertToYV12(), if that may be needed.
I never do any encodes without some filtering with avisynth...

Last but not least note that appending ConvertToYV12() never hurts, because ConvertToYV12() is a NOP, if applied on a YV12 clip...
Well, in the way it works now It can hurt. Of course this will be my mistake but... Also I don't feel very comfortable when every time I see this warning, even if no actual conversion is done.

[LoRd_MuldeR]

But IMHO its better to throw an error. For example I don't care about colorspace if all that I want is to specify input file and get my encode. But if .avs has non-YV12 colorspace as output it means something wrong on my side and I don't want to start the encode. Someone also may or may not want to do this conversion in some special way.

It's as easy as that:
* If Avisynth doesn't output YV12, the video can not be encoded with x264
* If Avisynth does output YV12 and you apply ConvertToYV12() anyway, then absolutely nothing will happen

Conclusion: Applying ConvertToYV12() in any case where it may be needed is a good idea. Better than failing with error.
Also x264 doesn't apply the color conversion silently. That's what the aforementioned warning is good for.

Last but not least, in case you throw a media file on x264 (not an Avisynth script!) you can't apply ConvertToYV12() yourself.
So in that case x264 must do it for you! Otherwise you couldn't open any files that aren't decoded to YV12 directly!

Of course, you could always open non-YV12 sources through a custom script and explicitly apply the color conversion.
But that's exactly what the new enhanced Avisynth input (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=380a201e8e8ba5a13022aeeeaf4b7501e1c79279) is intended to avoid...

In case x264 opens a custom .avs script, it could simply reject the file, if the final output isn't YV12. So the user would have to append ConvertToYV12() to the .avs file himself.Yes. This would be great.

Making x264 fail on a case that it currently handles fine would be great? :confused:

However you can now simply throw an arbitrary media file on x264 and it will built the required Avisynth script automatically. x264 will also append ConvertToYV12(), if that may be needed.I never do any encodes without some filtering with avisynth...

A feature that is useful for many users should be removed, just because one single user doesn't need it ???

Last but not least note that appending ConvertToYV12() never hurts, because ConvertToYV12() is a NOP, if applied on a YV12 clip...
Well, in the way it works now It can hurt. Of course this will be my mistake but..

How can a colorspace conversion hurt, if it is required anyway?

The one and only alternative of converting non-YV12 sources to YV12 is not encoding (with x264) at all :p

[Keiyakusha]

I agree about media files. I'm taking only about custom .avs script. I still not understand, If I have custom script, this means I know what I'm doing, why x264 should apply conversion instead of returning an error? Sorry, I don't see where this is a good idea.

A feature that is useful for many users should be removed, just because one single user doesn't need it ???
No. I just pointed my opinion to the developers. Everything else: you asking, I'm answering. Just wanted you to understand my point.

[LoRd_MuldeR]

I still not understand, If I have custom script, this means I know what I'm doing, why x264 should apply conversion instead of returning an error?

Because the conversion is required anyway. There is no difference between the user having to add it manually to the end of the script or x264 doing the unavoidable automatically.

Only that the former method is more annoying for the user (especially newbie users) and thus increases the number of "x264 doesn't open my AVS" threads :p

[Keiyakusha]

There is a plenty ways how chroma can be scaled durring conversion.
By the way, how fullrange thing works now? Is there a way to specify matrix? If someone forgot to do this in script - he will notice this only after encode is done?

[LoRd_MuldeR]

By the way, how fullrange thing works now? Is there a way to specify matrix?

You can still call ConvertToYV12() in your custom AVS script and specify whatever matrix you like. Nothing has changed in this regard, except that you can skip a "standard" conversion now.

The same way you will still have to use a custom script, if you want to apply filters to your source. But in many cases, where no filters are needed, you don't need to write a custom script anymore.

So there's absolutely nothing that worked before, but will not work now! At the same time using x264 is much more comfortable for many applications/users now. So I can't see why you complain.

(IMO it's kind of silly to complain about additional functionality, especially if it doesn't break any existing functionality. Therefore all this discussion smells a bit like trolling to me)

[Keiyakusha]

OK. I understand what do you mean. But still I though my point was clear enough (sorry if not) and worth mentioning. I have nothing more to say.

[kemuri-_9]

Ok, the problem is that the C API that i used for the patch is currently only compatible with avs 2.5

with this api and the way the new colorspaces were added in avs 2.6,
ALL OF THE PLANAR COLORSPACES are flagged as 'YV12' even if it's Y8, Y411, and etc.

so rather than let x264 think it's getting YV12 input when it could getting YV24 or something along those lines,
force a call to ConvertToYV12 which will convert them to YV12.

as LoRd_MuldeR already stated, if it's already YV12 in this situation, the forced call does nothing.

if this case was not covered, avs 2.6 users could experience corrupted output.

[Keiyakusha]

Thanks kemuri-_9! I completely forgot about new colorspaces.