x264 development

[dimzon]

to all x264 developers:
please take look at this post:
http://forum.doom9.org/showthread.php?p=774869#post774869

Thanx!

[Manao]

x264 opens avs scripts through the vfw interface, so it doesn't work.

[dimzon]

x264 opens avs scripts through the vfw interface, so it doesn't work.
ok, thanx!

[Isochroma]

Is it possible for x264 to support encoding to 4:2:2 (YUY2) & 4:4:4 colorspaces? I know it's probably impossible to do RGB24, but some research this morning turned up support for the above two colorspaces in High profile extended fidelity extensions. Since x264 already supports at least one of the extensions (lossless), perhaps it could support more?

[akupenguin]

What makes you think RGB is any less possible than 4:4:4 ?

[Isochroma]

You may be correct (see below). Previously, I had assumed RGB wasn't supportable in any MPEG-4 standard because both 4:4:4 and 4:2:2 are mentioned as supported in the High profile extended fidelity extensions, but no RGB is ever mentioned for any MPEG stream - at least, I'd never heard of such a thing. Also, MPEG-2 supports 4:4:4 in High Profile.

From http://en.wikipedia.org/wiki/H.264:

"The JVT recently completed the development of some extensions to the original standard that are known as the Fidelity Range Extensions (FRExt). These extensions support higher-fidelity video coding by supporting increased sample accuracy (including 10-bit and 12-bit coding) and higher-resolution color information (including sampling structures known as YUV 4:2:2 and YUV 4:4:4). Several other features are also included in the Fidelity Range Extensions project (such as adaptive switching between 4×4 and 8×8 integer transforms, encoder-specified perceptual-based quantization weighting matrices, efficient inter-picture lossless coding, support of additional color spaces, and a residual color transform)."

[foxyshadis]

Dizmon is requesting input colorspace conversion, though, not direct storage of RGB or YUY2. :p

[Isochroma]

There's more than one way to cut a pie... x264 having more colorspace modes would solve his problem and simultaneously help preserve the quality of video much better than it currently can be - also giving it a significant advantage over other YV12-limited AVC and ASP codecs. I think that with the advanced compression capabilities of h.264 in general, and this implementation in particular, the extra input data should be of little concern.

The opportunities for very 'cheap' quality improvement and the widening of x264's scope to include professional archiving requirements (as has already been started by the introduction of one FREXT - lossless mode) should not be overlooked. Even 4:2:2 provides much better color sampling than 4:2:0 (I can see the chroma blocking due to YV12 between source and encoded frames with lossless mode).

I see at least the YUV 4:4:4 and 4:2:2 modes as mere extensions of the direction x264 is already moving in, and probably easy to implement. It seems RGB might be more difficult due to the different way colors are represented.

Also, the differences between 4:4:4 and RGB are bound to be almost indiscernably small (if any) so RGB support should probably be on the back-burner while YUY might be a higher priority.

[Manao]

Isochroma : most people only handle 4:2:0 material, so there's little use right now for support of the other colorspaces ( that falls into the scope "you need it, you code it" ).

[Isochroma]

They may start with 4:2:0 material, but many avisynth filters output yuy2 and some even rgb data. Having to downsample the chroma after processing is a disadvantage for certain. For example, I'm using two denoisers in sequence (fft3d and neat image) to process video. FFT3d gets fed YUY2 data from a resizer earlier in the filterchain, and outputs the same (I think). Neat Image takes the output (converted to RGB24 by the Imagewriter() plugin) and produces really nice 48-bit TIFFs which then get downsampled to 24-bit PNGs by Irfanview thru commandline interface. Chroma blocking is easily distinguished on output frames compressed in YV12 from the original, even losslessly.

In industry, 4:2:2 is considered just barely good enough for pro work, and 4:1:1 and 4:2:0 are used as capture and output only, respectively. DV50 is certainly superior to DV25, especially for multigeneration work. Also, it seems likely that avisynth 3.0 will support 4:4:4, which will give users yet another path to a better product; it may even support >8-bit per channel color!

It is my hope that all filters and codecs which only run in YUV colorspace will support 4:4:4, or at least 4:2:2, someday. When a complete non-downsampled path exists from source to finished product, these tools will be considered to have reached the pinnacle of their capabilities.

It will give professionals in NLE studios and others in industry even more reasons to incorporate the great works of open-source and free development into their workflow. In output compressors, (excluding lossless edit & storage types) the commercial products seem to include only 4:2:0, excepting Windows Media 9, which can do all of them (!). It seems a fertile field for independent innovators to make inroads...

[Manao]

Starting from a 4:2:0 video and wanting to encode it in 4:4:4 is dumb ( except if you use a filter that properly interpolate chroma, which you don't, since there's none ). If your input is really 4:4:4, it's another matter, but unless you're doing CGI animation, it won't be 4:4:4

It will give professionals in NLE studios and others in industry even more reasons to incorporate the great works of open-source and free development into their workflowNot at all. They'll never use x264, because they'll never go the open source way.

[Episodio1]

SW: III and SIN CITY were filmed with Sony HDC-F950 and HDC-950 respectively (4:4:4)
http://us.imdb.com/title/tt0121766/technical


I guess Sin City doesnt take advantage at all, as it is B&W and heavy filtered. xD

[Manao]

I doubt you have access to the 4:4:4 material for these movies anyway :p

You only have access to the DVDs ( 4:2:0 ), and HDTV ( 4:2:0, perhaps 4:2:2 sometimes, but I doubt it )

[Wilbert]

Also, it seems likely that avisynth 3.0 will support 4:4:4, which will give users yet another path to a better product; it may even support >8-bit per channel color!
Many filters in avs v2.60 are already working in YUV 4:4:4 (8 bit) :)

[Raptus]

It seems CLI x264 is less anal with levels than MeGUI is. For instance, while MeGUI won't let me use level 3 together with P4x4 x264 doesn't even issue a warning. Oversight or feature? In such cases where contradictory params are used, will x264 enforce or ignore levels?

On a sidenote, I'd appreciate if someone had a link to a detailed list of the different AVC level constraints. (I can't find the damn h.264 doc where they supposedly are specified in Appendix A. Best I dug up so far was: http://www.cdt.luth.se/~peppar/kurs/smd151/spie04-h264OverviewPaper.pdf )

[CruNcher]

Raptus also my problem with level 4 reading the level specs shows it should be fine so i force it on cmd no problem just lets wait for Standalones then we'll see whats correct :P

[Doom9]

For instance, while MeGUI won't let me use level 3 together with P4x4 x264 doesn't even issue a warning. Oversight or feature? In such cases where contradictory params are used, will x264 enforce or ignore levels?The level tag only flags the level in the resulting stream.. it does not actually limit the encoder to a certain level.

As far as the level constraints go, they are in this very forum.. I don't recall thread urls by heart but I know they're there since it's what I used to enforce levels in MeGUI (along with aku's help.. the P4x4 limitation was added after he suggested that it was required).

[Kostarum Rex Persia]

New build came out, data is below:

r429 | pengvado | 2006-02-10 22:58:43 +0100 (Fri, 10 Feb 2006) | 3 lines
Changed paths:
M /trunk/Makefile
M /trunk/common/amd64/predict-a.asm
D /trunk/common/amd64/predict.c
M /trunk/common/i386/predict-a.asm
M /trunk/common/i386/predict.c

amd64 mmx for some intra pred functions

So, I suppose that amd64 mmx predictions will speed-up encoding on Athlon 64 based computers, am I right. Sorry if I don't understand this very well, but I am not a programmer.

Can x264 32-bit version, now work without problems on Windows XP 64-bit edition?

[bob0r]

Kostarum Rex Persia will be happy:

VFW updated:
r430(and r431)
VfW: support trellis, brdo, nr, bime.
patch by Dan Nelson (dnelson at allantgroup dot com).

So About the missing option in the x264 VfW (http://forum.doom9.org/showthread.php?t=105899) can be updated , not in VFW:

- Constant quality mode
- Fast P-Skip
- Custom quantization matrices
- Buffer control
- Zones
- AQ (only available in Sharktooth's build, not an official x264 feature at this point)

[LoRd_MuldeR]

Kostarum Rex Persia will be happy:

VFW updated:
r430(and r431)
VfW: support trellis, brdo, nr, bime.
patch by Dan Nelson (dnelson at allantgroup dot com).

So About the missing option in the x264 VfW (http://forum.doom9.org/showthread.php?t=105899) can be updated , not in VFW:

- Constant quality mode
- Fast P-Skip
- Custom quantization matrices
- Buffer control
- Zones
- AQ (only available in Sharktooth's build, not an official x264 feature at this point)


Yeah! X-Mas and Easter on one day :D
Thank you very much !!!

Can't wait to try the new settings...

[Kostarum Rex Persia]

Wow, thanks. Great news, bob0r.

[celtic_druid]

I actually added those features to the build I included with my FairUse Wizard compile back in Dec or whenever.

I was just waiting to see if anyone would notice...

[LoRd_MuldeR]

Noticed a small bug with the new VFW settings:

If I check "Bidirectional ME" and klick "OK" and later go back to the config window, then "Bidirectional ME" is unckeckd. So it seems not to remember this setting. I got no idea if "Bidirectional ME" is enabled when I check it, click OK and don't go back to the config window before encoding. At least someone should take a look at this issue...

[Kostarum Rex Persia]

Yes, and I noticed that bug. I think that if "Bidirectional ME" is enabled when I check it, it's disabled when I start encoding, because encoding speed is same with or without checking Bidirectional ME. And we know that "Bidirectional ME" slowdown encoding speed.

And Trellis Quantization is only "on the Final MB", not on value "Always".

[LoRd_MuldeR]

And Trellis Quantization is only "on the Final MB", not on value "Always".

Is that a probelm?


The x264.nl notes say:
not in vfw: Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip)

Is there hope we'll get this soon?

[bob0r]

The Bidirectional ME and Max Ref. frames(try backspace and enter 2, its kinds fucked... or was) bugs are found and fixed, only have to be submitted.

@celtic_druid

^^ And your what? url?

But why not submit to x264 SVN? :)

[bob0r]

And Trellis Quantization is only "on the Final MB", not on value "Always".

Trellis 1 = recommended value. (So no thats not a problem or bug)

For EXTREME settings use x264.exe (with megui.exe if you will), then you can max out everything.

VFW must be simple and easy to use.

@all

Hopefully Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip) will be added to VFW shortly, Fast P-Skip is very easy, Quality-based VBR will take a bit longer.

Hopefully Dan will make us happy soon! (or at least bond)

Do you guys think this will be a good layout for Tab More... ?
http://files.x264.nl/x264_vfw_tab_more.jpg

[akupenguin]

maybe vertically align the checkboxes (chroma/pskip/mixed and cabac/trellis/deblock)

[SeeMoreDigital]

I think "Sample AR" boxes need to be wide enough to accommodate/display "three" numbers in each box.


Cheers

[bob0r]

Something like:
http://files.x264.nl/x264_vfw_tab_more_3.jpg

Btw, 4 more boxes are buggy with pressing backspace and adding new values.
Reported and confirmed, hopefully last submit about these issues soon, i should have tested some more :o

r434 buggy are:
VFW - Rate Control TAB: MIN QP
VFW - Rate Control TAB: MAX QP
VFW - Rate Control TAB: MAX QP Step
VFW - More... TAB: Threads

@SeeMoreDigital
I was too tired i forgot to press submit, so your idea is not in this concept :)

[LoRd_MuldeR]

Hopefully Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip) will be added to VFW shortly, Fast P-Skip is very easy, Quality-based VBR will take a bit longer.

Hopefully Dan will make us happy soon! (or at least bond)

I'm looking forward :D

[LoRd_MuldeR]

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....

[nm]

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....
I had a strange blocking problem (http://forum.doom9.org/showthread.php?p=773296#post773296) with it at all settings, with larger values (over 100) causing significant problems in some scenes. It could be just something in my systems because there were no other similar reports. I haven't tried x264 noise reduction since those tests, so it could be fixed now, if there ever was a bug. If you are using it for anything important, watch the result through to make sure there are no strange artifacts.

As for the values, I wouldn't recommend going over 500 for normal DVD sources. At high values --nr will introduce smaller 4x4 blocks all over the image as can be seen here (http://forum.doom9.org/showthread.php?p=773241#post773241).

[Kostarum Rex Persia]

Bob0r, can you include sub me 7 in your future builds, like Shark tooth in revision 408? And, or course, let us to choose between Trellis quantization values, "On The Final MB" or "Always" value.

[shon3i]

And CQM, is there any option to add decoding function in vfw like xvid, so we can manipulate with x264 files in virtualdub.

[LoRd_MuldeR]

And CQM, is there any option to add decoding function in vfw like xvid, so we can manipulate with x264 files in virtualdub.

You can use ffdshow to open x264 videos in VirtualDub. Of course they need to be in AVI. All you have to do is, enable H.264 support in ffdshow's VFW configuration. Or isn't that what you need?

AFAIK x264 (VFW and CLI) is for encoding only and does not include any kind of decoder.

[Kostarum Rex Persia]

I think that shon3i don't think on that, he has something else in mind. Shron3i, please explain in details your idea.

[shon3i]

is for encoding only and does not include any kind of decoder. I know that but xvidwfv can be a decoder. So i think why can be x264vfw has own decoder

[LoRd_MuldeR]

I know that but xvidwfv can be a decoder. So i think why can be x264vfw has own decoder

Because it is not needed. ffdshow is x264's decoder...

I think there is a decoder on the x264 CVS, but it has not been developed any further. Last change was 1 year ago. If I remember correctly, sombody said the decoder doesn't even compile...

[shon3i]

Ok but you want open x264 avi file i virtual dub to split there is error message.

[Kostarum Rex Persia]

Correct, VirtualDub always show error message when I try to open x264 encoded AVI file. Error message:

"Couldn't locate decompressor for format H264(unknown). VirtualDub requires a Video for Windows(VFW)compatible codec to decompress video. Directshow codecs, such as those used by Windows Media Player, are not suitable".

But I installed ffdshow from december and put ffdshow plug-in in VirtualDub folder.

[LoRd_MuldeR]

Ok but you want open x264 avi file i virtual dub to split there is error message.

What is the error message ???
I think you are just missing a VFW decoder that supports H.264

Do you have an up-to-date build of ffdshow installed? If not so, you'll have to do this!
And after ffdshow is installed, go to START -> Programs -> "ffdshow" -> "VFW codec configuration" and enable "H.264" on the Decoder tab (you need to change value from "disabled" to "libavcodec")
This will work :)

BTW: The "ffvdub" plugin is needed to use the ffdshow video-filters in VirtualDub, it is *not* required for the decoding!

[Kurtnoise]

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....
.....zzz

[LoRd_MuldeR]

With the cli, min=0/max=16...

Now I'm confused :scared:

You say the Noise Reduction value should be between 0 and 16.
Other people talk about values of 100 or even much higher...

So, what is correct ???

[Kurtnoise]

Sorry,...I was confused by the << and <>.

[LoRd_MuldeR]

Sorry,...I was confused by the << and <>.

So this means I should look for a good setting in there range of 0 to about 100, correct?

[celtic_druid]

Well mencoder uses 0, 100,000 but yes x264 does appear to use 0, 1<<16.

[LoRd_MuldeR]

Well mencoder uses 0, 100,000 but yes x264 does appear to use 0, 1<<16.

:eek: :confused:

And what does the x264 VFW inrerface use?

[celtic_druid]

It doesn't use anything. There is no limit, although that doesn't mean that you can really use a value of 56487897897984948949889489879878998. It is just that it will let you enter it.

[LoRd_MuldeR]

It doesn't use anything. There is no limit, although that doesn't mean that you can really use a value of 56487897897984948949889489879878998. It is just that it will let you enter it.

Arrrghhh, please be a little more patient with me :(

I already noticed that it lets my enter whatever I want to. But what values are actually supported and do make sens?
Is the range where I can find a "good" setting only between 0 and 16 or can/should I go much higher, like 100 and even above? I still don't got that...

:thanks: