To GUI developers: x264 API change

[Dark Shikari]

A totally useless option disappeared a few minutes ago. (http://git.videolan.org/?p=x264.git;a=commit;h=5fb6417309febda6f73a98494cb935379129e15d)

Though most GUIs don't seem to have this option, some do. I will demonstrate what needs to be done in visual form. ;)

http://i43.tinypic.com/2q892ec.png

[kemuri-_9]

for those who use x264 through CLI...
this is the --direct-8x8 option
as it no longer exists for r1085+,
remove it from your options to prevent the standard unknown parameter error (if you have been using it).

[Sagekilla]

Wow, that almost seems like the quality improvement per CPU cycles spent for direct-8x8 is -worse- than --me tesa.

[Dark Shikari]

Wow, that almost seems like the quality improvement per CPU cycles spent for direct-8x8 is -worse- than --me tesa.Not "almost", it actually is.

[Selur]

Thanks for the Info, will remove it from sx264. :)

Cu Selur

[Atak_Snajpera]

Small question: Is there any reason why these two options are not combined?
--partitions i8x8 --8x8dct

[Chengbin]

Wow, that almost seems like the quality improvement per CPU cycles spent for direct-8x8 is -worse- than --me tesa.

Are you saying me tesa does not provide noticeable quality improvement than umh?

[Sharktooth]

i wonder why they didnt call it --me placebo ...

[Sagekilla]

@Chengbin: No, I'm saying --me tesa is actually better than --direct-8x8.

[tobinaka]

i wonder why they didnt call it --me placebo ...

--tesa is NOT placebo. see my test result collections.
http://www.tobinaka.com/files/x264rev1057exp1mix_options_test.zip

I want to test all options of x264 but I've not finished yet. But it's a good time to release it. You can see there the results of me and me-prepass. On some video, --me tesa with --me-prepass is better than any others.

[lexor]

--tesa is NOT placebo. see my test result collections.
I think Sharktooth was talking about the now defunct 8x8 switch.

[kemuri-_9]

--tesa is NOT placebo. see my test result collections.
http://www.tobinaka.com/files/x264rev1057exp1mix_options_test.zip

I want to test all options of x264 but I've not finished yet. But it's a good time to release it. You can see there the results of me and me-prepass. On some video, --me tesa with --me-prepass is better than any others.

1. --me-prepass is an experimental option not a part of the repository, don't involve it for realistic testing.
2. since you're using .yuv sources, pass them off to x264 directly rather than going through avisynth.

Small question: Is there any reason why these two options are not combined?
--partitions i8x8 --8x8dct

are you trying to eliminate the possibility someone might want 8x8dct but not i8x8 ?

[Dark Shikari]

Small question: Is there any reason why these two options are not combined?
--partitions i8x8 --8x8dcti8x8 is on by default when using 8x8dct.

They're not combined because we shouldn't require that someone use partitions when using 8x8dct.

For example, --partitions none --8x8dct is a good tradeoff (8x8dct gives better quality-per-speed improvement than any of the partitions, so it should be one of the first options turned on when starting from max speed and raising quality from there).

[roozhou]

I wonder why x264 keeps changing its API. Why not just keep useless options as null parameters so the GUI makers and users do not have to upgrade their programs frequently.

[Dark Shikari]

I wonder why x264 keeps changing its API. Why not just keep useless options as null parametersBecause then we'd be like ffmpeg and have an incredibly convoluted header file that's almost impossible for people using the library to parse because it's utterly covered with options that are deprecated.

-me_method phods anyone?

[Atak_Snajpera]

I wonder why x264 keeps changing its API. Why not just keep useless options as null parameters so the GUI makers and users do not have to upgrade their programs frequently.
Those changes are peace of cake. I have no problem if developers decide to remove useless options.

[tobinaka]

I think Sharktooth was talking about the now defunct 8x8 switch.

I get it now.

1. --me-prepass is an experimental option not a part of the repository, don't involve it for realistic testing.
2. since you're using .yuv sources, pass them off to x264 directly rather than going through avisynth.

1. You're right. I'll post and discuss about --me-prepass on another thread at next time. But I'll say --me tesa with --me-prepass isn't unrealistic to test comparing it to the official options. It's needed to be tested because it's experimental.

2. As you know, some x264 options can't be used with --interlaced. But some VQEG test sequence videos are YUV 4:2:2 interlaced. I want to use them to options test because of respecting copyrights and availability. So I de-interalced them into AVI, and input the AVI with AviSynth. Certainly, I think it's better to use --thread-input for single-thread.

If there is another way to get some video good to test without the problems of copyrights and availability, please tell me for the future. I'll accordingly improve my tests.

But this thread is not for it. Even my responce is too long for here...