x264 filtering test thread

[kemuri-_9]

as part of x264cli's goal of becoming a more general-purpose encoding tool, I've been working on a new filtering API.

I now have (afaik) a working x264 build with 2 filters:

• resize: as the name sounds is a generic resizer (no crop/pad support yet)
  this is being worked on at specific request for the upcoming --device support that'll require resizing the video for display on the devices at their supported resolutions.
• select_every: this should be familiar to avisynth users, as this is exactly a port of SelectEvery()
  this wasn't really a request but more of an easy-to-implement 'something-or-other' to test a required input frame caching system
  for future planned filters that have a x:y input:output frame ratio (unlike the resizer which is purely 1:1)

for the time being (likely to change)
the options that are added to x264cli for this are

• --cli-filter <string>: specify a filter chain here and the input video will be filtered in the given order
• --cli-filter-help <string>: print out a short message on how to use the specified filter

e.g.:

Code: [Select]

$ ./x264 -o test.mkv ../foreman_cif_352x288.yuv --cli-filter select_every:1,0,0/resize:704x576
yuv [info]: 352x288p 0:0 @ 25/1 fps (cfr)
select_every [info]: new fps rate = 50/1
resize [info]: resizing to 704x576
[....]
encoded 600 frames, 58.27 fps, 1882.30 kb/s

will apply select every and then resize, whereas

Code: [Select]

$ ./x264 -o test.mkv ../foreman_cif_352x288.yuv --cli-filter resize:704x576/select_every:1,0,0
would apply resize and then select every
(this order would consume more memory as select every would cache input frames at 704x576 instead of the original 352x288)

provide feedback here, as I will not be on irc all that often until i get situated after moving...

[Sepp]

Code: [Select]

x264_filter.exe --preset slow --crf 17 --b-pyramid normal --cli-filter resize:704x464 --output %1_f.mkv %1Resizer works great so far.

[Chikuzen]

Bug?report

source: http://media.xiph.org/video/derf/y4m/720p/720p50_shields_ter.y4m

Code: [Select]

x264_filter.exe source.y4m --demuxer y4m --cli-filter resize:512x288 -o resized.mkv
result: http://www.mediafire.com/download.php?tqzyqjyij4k

[kemuri-_9]

thx for the report, i'll look at it when i can finish dling that y4m and find some time for it :/
does it still happen with --no-asm?
(i have swscale use cpu flags that x264 is running with, so wondering if it's an issue around that)

[Chikuzen]

does it still happen with --no-asm?
(i have swscale use cpu flags that x264 is running with, so wondering if it's an issue around that)

when i tested with --no-asm, it was not reproduced.

[checkers]

Filter request: crop

[kemuri-_9]

when i tested with --no-asm, it was not reproduced.

very strange. i finished dling the sample and was able to replicate it having issues with asm locally...
i'll see if i can figure out the issue when i can get to compiling it again (don't have my usual build env with me)

Filter request: crop

had you more clearly read my first post you would've noticed that crop/pad support will be eventually done, i haven't gotten to it yet.

[Chikuzen]

additional report

Code: [Select]

x264_filter.exe source.y4m --demuxer y4m --cli-filter resize:640x160 -o 640x160.mkv
x264_filter.exe source.y4m --demuxer y4m --cli-filter resize:632x160 -o 632x160.mkv
x264_filter.exe source.y4m --demuxer y4m --cli-filter resize:624x160 -o 624x160.mkv
x264_filter.exe source.y4m --demuxer y4m --cli-filter resize:624x160 --no-asm -o 624x160_no-asm.mkv
result:


i suspect that cause of this issue is code of libswscale.

[kemuri-_9]

i suspect that cause of this issue is code of libswscale.

or me somehow not knowing how to set its cpu flags properly, I'll try and work on it today....

[checkers]

had you more clearly read my first post you would've noticed that crop/pad support will be eventually done, i haven't gotten to it yet.

I don't want crop as part of the resize filter, I want crop as a standalone filter that's useful for cropping black bars.

[Dark Shikari]

I don't want crop as part of the resize filter, I want crop as a standalone filter that's useful for cropping black bars.

Why does it matter to you how it's implemented internally?

[kemuri-_9]

or me somehow not knowing how to set its cpu flags properly, I'll try and work on it today....

i hate it when i'm right: it was something fairly retarded....
i wasn't setting the MMX flag along with the MMX2 flag, i was unaware that it would have corruption like this, but changing that seems to have fixed the issue.
uploaded a new build, but as it's with rather fewer optional features (no mp4 and no ffms) it's a different build

[Chikuzen]

okay, i tested the new build about resizing 1280x720 to 1980x1080/ 1280x720/ 704x396/ 640x360/ 512x288/ 480x272/ 352x192, and it seemed to work fine in all case.
(to ffmpeg guys: sorry for suspecting swscale...)

select_every also seemed to work well.
i had compared its output in some patterns with the case to use avisynth, and those results were completely corresponding.

[checkers]

Why does it matter to you how it's implemented internally?

The implementation doesn't matter so long as cropping-when-resizing doesn't use data from the cropped portion of the image (like avisynth's implementation).

[kemuri-_9]

The implementation doesn't matter so long as cropping-when-resizing doesn't use data from the cropped portion of the image (like avisynth's implementation).

sure, before i get started on it, then you should make sure you express how you want it to work.
i was planning on adding cropping/padding to the resize filter and it would apply in the specified order....
so for:

Code: [Select]

resize:crop(2,2,2,2),704x480,pad(0,8,0,8,008080)
it would crop, then resize, then pad...

similarly...

Code: [Select]

resize:pad(0,8,0,8,008080),704x480,crop(2,2,2,2)
would pad, then resize, then crop (this doesn't make much sense for a real use case, but useful for getting the idea).

i'm still going over thoughts on how to do the padding color/style as it will vary for different colorspaces....
so continue to put forth your ideas and feedback.

[Audionut]

What resizer is used?

[kemuri-_9]

What resizer is used?

bicubic for now, i was also thinking of allowing the user to set this from what's available in libswscale.

[Numien]

bicubic for now, i was also thinking of allowing the user to set this from what's available in libswscale.

That would be a nice touch. Different algorithms are better for different things.

[kemuri-_9]

Ok, i had actually expected to be able to do some of the things i had planned on this over the weekend,
however work decided to deny me of that planned time at the last minute.

I'm tossing out the current revision of the patch which has gone through a few slight changes trying to clean up a few things here and there as
A) I had meant to do so already
B) I no longer see myself being able to work on it in a timely fashion with how work is piling up.

x264_filtering.diff

there's a large number of changes to things and i'll try to come by every once in a while to answer questions
(i may be able to hop on irc sometime to answer things but no guarantees on that)

[buzzqw]

i will like to add support to microx264 gui for this kind of filter(s)

when will be added pad/crop ?

anyone is working on this ?

will be possibile to use something like resize:640x-1 (or -2) as mplayer ?

BHH

[kemuri-_9]

afaik no one is working on this atm as
A) this is originally a feature i started
B) I am under an incredible time crunch for a project IRL; said project is due by Monday the 22nd, so after or around then i expect to have time to work on it again.
C) no one else has notified me that they started working on it.

I never use mplayer so i am not familiar with how it accepts resizing flags but the current planned way would not allow that.

[buzzqw]

thansk kemuri-_9

i will wait. these features are very neat

the -1/-2 allow mplayer to automatic resize to correct aspect ratio (given crop and width)

BHH

[J_Darnley]

http://users.telenet.be/darnley/x264/x264_filtering_03_r1442.diff
http://users.telenet.be/darnley/x264/x264-filter3.exe
http://users.telenet.be/darnley/x264/x264_filtering_04_r1442.diff
http://users.telenet.be/darnley/x264/x264-filter4.exe

This is an new version of the patch.  It has been ported to rev 1442.  I have also added a choice of three resize methods: bilinear, bicubic (default) and lanczos.
Usage is now: "resize:WxH:method"

Version 4 fixes a glaring bug that causes a crash when the encoder can't be opened.  It also adds 3 special casesfor the dimensions which are based on mplayer, or at least what I think the mplayer html doc says.

The help says:

Code: [Select]

resize: resizes frames to the given size
syntax: resize:widthxheight:method
available methods: bilinear
                   bicubic (default)
                   lanczos
special-case dimensions:  0 -- scale this by the same factor as the other
                         -1 -- do not scale
                         -2 -- scale this to get square pixels

[kemuri-_9]

is there a particular demand for padding support?
sure cropping is definitely wanted, but padding?

I'm mostly asking as there's a fair bit of work that'll be required of padding and i'm not particularly thrilled at doing it if it's not really desired.

[buzzqw]

@J_Darnley

thanks!

@Kemuri
better to pad with avisynth

for me is a unneeded fuction

BHH

[Dark Shikari]

You don't have to do padding.  Really, once we get this committed, anyone will be able to write it.

[RiCON]

Padding is kinda needed for those hardwares that don't support aspect ratio. And the point of adding these filters to x264 was to enable direct encode to hardware without needing Avisynth, no?

[J_Darnley]

I for one won't be writing a padding filter.  I do plan on taking a stab at cropping though.  That is unless anyone else has got code to share about that.

Also, I need to ask a question the resizing and sar.  Should the filter correct/change the sar when the aspect ratio of the frame changes?  Do you agree that it should be corrected when "special case -2" is used?

[kemuri-_9]

You don't have to do padding.  Really, once we get this committed, anyone will be able to write it.

fine fine, I'll just do the swscale specific things like being able to flag all the available resizers.
cropping and padding can come in a later commit.
i'm not planning to do that weird mplayer style resizing, someone else can commit that after i get this in.

[rack04]

Is there anyway to make this patch compatible with x264_NAL-HRD.1.30?  I can't apply both together.