Current Patches, Where to get them, How they affect speed/output

[qyot27]

Originally Posted by J_Darnley

Well since cygwin and msys are unix-like, setting CC should work fine. Certainly using --cc when configuring ffmpeg gets it to use my gcc 4 which is installed in the same folder as 3.4.5

Downloaded TDM SJLJ GCC 4.4.1 core and g++ packages.*
Extracted them, and appended -4.4.1 to the end of each.
Put them in /bin.

cd x264
CC=gcc4.4.1 ./configure (or CC=gcc4, doesn't matter)
No working C compiler found.

Neither does it work if I unpack them without renaming to /gcc4 and add an entry to fstab that points there. Still no working C compiler. Like kemuri-_9 said, you have to constantly rename the gcc bin files back and forth for which one you want to use at the time, or use full pathnames (and CC= and --cross-prefix are not the solutions to that). I knew that already, which is why I said separate installations are the easiest to deal with. Then no renaming is necessary - just fire up your GCC 4.4.x-enabled installation, or your GCC 3.4.5-enabled one, which don't talk to each other at all and have a complete MSys each that's are all their own.

Cygwin and MSys may both be Unix-like, but MSys =/= Cygwin. If you want to explain how you got multiple GCC versions working under a single install of MSys without having to rename anything and only calling CC= or --cc=, then I'd be more than happy to hear it. But from where I'm standing (including wasting all of this morning trying to no avail), it's not possible.




*I even grabbed komisar's GCC 4.4.2 build and extracted it out to the empty /mingw directory and pointed it there - still no dice.

[J_Darnley]

CC=gcc-sjlj ./configure works4me.
Is gcc actually called "gcc4.4.1.exe" or "gcc4.exe"?
I think I just extracted the 4.2.1 archives (from mingw) into the my mingw folder and they just worked. They already had the -sjlj suffix.

[kemuri-_9]

if you only download the different gcc and don't have the libs and include files in the new gcc's search path,
you can cheat by adding the library and include paths from your full installation to the commandline,

i.e.:
CC=gcc-blah ./configure --extra-cflags=-I/mingw/include --extra-ldflags=-L/mingw/lib

where there's a full installation at /mingw and the CC you give is only the compiler (no runtime and no headers in its search path)

you won't have to do this if you extract the gcc to the same prefix as your current installation (granted the executable names are different and won't overwrite anything)

[qyot27]

Ok, thanks. Everything's working now the way it should. Now I just have to get 4.4.2 in there instead of 4.4.1.

[techouse]

Another way to permanently change the default CC is via /etc/fstab

[[ReX]]

My x264 r1376 builds.

GCC 4.5.0 (experimental) builds

Generic (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff

-march=core2 (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff


(NEW) GCC 3.4.6 build

Generic (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff


ICC 11.1.051 builds
Thanks to MasterNobody and XhmikosR.

Generic (fprofiled)
Patches used: x264_icc_r1373.diff and x264_hrd_pd_interlace.16_r1369.diff

/QaxSSSE3 /O3 (fprofiled)
Patches used: x264_icc_r1373.diff and x264_hrd_pd_interlace.16_r1369.diff

/QxSSSE3 /O3 (fprofiled)
Patches used: x264_icc_r1373.diff and x264_hrd_pd_interlace.16_r1369.diff

[techouse]

x264_x86_r1376_vanilla_gcc_techouse
GCC 4.4.2 20091019 (x86.generic.Komisar), unpatched, generic, fprofiled

x264_x64_r1376_vanilla_gcc_techouse
GCC 4.4.2 20091019 (x86_64.generic.Komisar), unpatched, generic, fprofiled

---------------------------------------------------------

x264_x86_r1376_gcc_techouse | INFO
GCC 4.4.2 20091019 (x86.generic.Komisar), generic, fprofiled

x264_x64_r1376_gcc_techouse | INFO
GCC 4.4.2 20091019 (x86_64.generic.Komisar), generic, fprofiled

Patches used:

x264_hrd_pd_interlace.16_r1369.diff

---------------------------------------------------------

x264_x86_r1376_vanilla_icc_techouse
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x64_r1376_vanilla_icc_techouse
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff

---------------------------------------------------------

x264_x86_r1376_icc_techouse | INFO
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

x264_x64_r1376_icc_techouse | INFO
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff
x264_hrd_pd_interlace.16_r1369.diff

[techouse]

Originally Posted by kemuri-_9

if you only download the different gcc and don't have the libs and include files in the new gcc's search path,
you can cheat by adding the library and include paths from your full installation to the commandline,

i.e.:
CC=gcc-blah ./configure --extra-cflags=-I/mingw/include --extra-ldflags=-L/mingw/lib

where there's a full installation at /mingw and the CC you give is only the compiler (no runtime and no headers in its search path)

you won't have to do this if you extract the gcc to the same prefix as your current installation (granted the executable names are different and won't overwrite anything)

If you're doing more than 1 build with the same CC it's probably a good idea to export it before running configure and then use it as default.

[olapanekala]

Happy Holidays to everyone

[aegisofrime]

My version of x264 (r1376) feels old Are the x264 developers planning a Christmas present for us?

[Fr4nz]

Probably they're on vacation like us...

[Sharc]

Originally Posted by aegisofrime

My version of x264 (r1376) feels old Are the x264 developers planning a Christmas present for us?

What improvements / features are you waiting for?

[Dark Shikari]

Download this clip, open it in VLC or MPC-HC, and seek anywhere in the video. Oh and it has no keyframes.

[LoRd_MuldeR]

Interesting. What does "PIR" stand for please? And is there any loss in compression efficiency?

[Dark Shikari]

Originally Posted by LoRd_MuldeR

Interesting. What does "PIR" stand for please? And is there any loss in compression efficiency?

Periodic Intra Refresh. The loss exists, but it's not that large when compared to having a similar keyframe interval (e.g. keyint=35 for a PAL SD video.)

More importantly, combined with other changes, this allows:

1. Zero encoder, decoder, and buffer latency.
2. Error resilience up to 20-25% packet loss rates, using one-slice-per-packet.
3. No keyframes beyond the first, so constant or capped framesize are both possible.
4. Realtime HD encoding at zero latency.

In other words, x264 is now the greatest encoder in the world for realtime video applications, like videoconferencing, and anyone who uses anything else needs to have their head examined

[LoRd_MuldeR]

I see. But I guess we won't use that for "movie" encodes with (almost) unrestricted key-frame interval and no "zero latency" requirement, right?

BTW: The DivX H.264 Decoder crashes when seeking in that stream

[TEB]

Originally Posted by Dark Shikari

Periodic Intra Refresh. The loss exists, but it's not that large when compared to having a similar keyframe interval (e.g. keyint=35 for a PAL SD video.)

More importantly, combined with other changes, this allows:

1. Zero encoder, decoder, and buffer latency.
2. Error resilience up to 20-25% packet loss rates, using one-slice-per-packet.
3. No keyframes beyond the first, so constant or capped framesize are both possible.
4. Realtime HD encoding at zero latency.

In other words, x264 is now the greatest encoder in the world for realtime video applications, like videoconferencing, and anyone who uses anything else needs to have their head examined

Awesomely cewl, do u have any reccomendations for a HD-SDI input card that would work with x264 in a workflow that can spew out Multicast? I wanna show the guys at work how good quality X264 can do vs a HW encoder for RT HD coding , Now we just need to make a good RT workflow that will mux audio and put it into a container
TE

[Disabled]

That looks and sounds awesome. That feature is part of the extended profile, is it? Would it be possible to refresh in different patterns than from top to bottom? Like in an interlaced pattern?
And do you know of any software using x264 for streaming? Like a videoconference app?

[Dark Shikari]

Originally Posted by Disabled

That looks and sounds awesome. That feature is part of the extended profile, is it?

No, it's an encoder-side feature unrelated to profile.

Originally Posted by Disabled

Would it be possible to refresh in different patterns than from top to bottom? Like in an interlaced pattern?

Only if we enabled constrained intra prediction. All patterns that don't use constrained intra prediction must work from the top left to the bottom right (in some variation).

Originally Posted by Disabled

And do you know of any software using x264 for streaming? Like a videoconference app?

There are at least three low-latency x264-using apps in development.

[Blue_MiSfit]

Nice Merry Christmas, DS - and all the trolls on doom9

~MiSfit