sex264 (updated almost daily by now)

[Sirber]

Originally posted by Ark
I tested more for this blocking issue, and saw that it only happen with 2-pass encodings, with 1-pass fixed quantizer i can set 1, 2 or 3 b-frames and it's all perfect! Can't we use sex264 as a decoder instead of ffdshow? It should supports itself...

[bond]

Originally posted by IgorC
where can i get gui? there is nothing http://celticdruid.no-ip.com/xvid/mplayer/sex264 is a vfw wrapper for the x264 video encoder. another different wrapper is mencoder, which you can find via the link you pointed to

Originally posted by Sirber
Can't we use sex264 as a decoder instead of ffdshow? It should supports itself...whats wrong with installing ffdshow?
x264 doesnt include a decoder (of course encoder and decoder doesnt need to be combined or offered together when we are talking about an open standard (like mpeg-4), as all decoders following the standard should decode the stream). still x264 has a decoder, but its very weak
also when you look at aku's additions to ffmpeg's avc decoder, it can be seen as "x264's decoder"

[Ark]

Originally posted by JoeBGermany
I also have blocking with b-frames. Only when I choose 0 b-frames it´s ok. But would be nice to have b-frames support :)

Actually what i meant is that b-frames (1,2,3 or whatever) seems to be well supported, but only in 1-pass mode.
In fact in 2-pass mode they show the blocking issue i mentioned some posts ago (i also attached a screenshot), that it's not the usual blocking caused by too low bitrate, but a wrong allocation of macroblocks (i think...), they seems like a puzzle with pieces in the wrong place...

[sysKin]

Hi,
I'm glad to tell you that whole VfW code, as you've seen it yesterday plus two other changes, made it into x264's repository.

Changelog:
- removed subpixel refinement 0, as core doesn't support it anymore (thanks virus)
- changed x264's homepage to "the real one" (thanks virus)

At this moment, I concider sex264 round one closed. My next goal is to start hacking the core, and I will open sex264 round two to let you have fun with whatever bugs I invent.

The result of round one (ie the same x264 that is in CVS, revision 89) can be downloaded from the usual place http://syskin.is.dreaming.org/x264/

Thank you everyone for your time spent on testing and discussing this vfw library :D

Radek

[chilledoutuk]

I encoded a music video with this codec but I noticed black blocks apearing on the video when the camera zooms out very fast.

here is a clip of the encode where the blocks can be seen
http://www.aoul98.dsl.pipex.com/rachel clip.avi

Here is a clip from the source mpeg2 ts.
http://www.aoul98.dsl.pipex.com/source.mpg

these are the settings used
http://www.aoul98.dsl.pipex.com/sex264config.png

[IgorC]

by default 4x8 8x4 4x4 P frames turned off. what does it mean?
has it some problem or it too slow that´s why is turned off.

untill now i didn´t notice visual bug of this oprtions maybe becuase of others like Bframes

[akupenguin]

Originally posted by IgorC
by default 4x8 8x4 4x4 P frames turned off. what does it mean? They used to reduce compression on some sources, but that should be fixed now. I just haven't rebenchmarked them to decide if they're always worth the speed cost. (It's not too slow, but they don't usually have a huge effect either.)

[CruNcher]

@chilledoutuk
known skip problem its being worked on

[Sergejack]

What does the "Every '1' th INTRA becomes a keyframe" ?
Isn't '1' meaning that each INTRA will be uncompressed ? (EDIT : I'm talking about a temporal compression here of course)
Because if that's trhe case, maybe '1' isn't a good choice for high compression.

[stephanV]

Intra frames are not uncompressed although they do tend to take up more space then a P or B frame. Anyway, in H.264 i-frames are not necessarily keyframes as with the multiple references a p-frame after that i-frame can refernce to a p-frame before it. Seeking from that i-frame is therefor impossible. To solve this a new frame type was introduced called an IDR frame. P frames after an IDR-frame are not allowed to reference a frame before the IDR frame, even if multiple references are used. Therefor, IDR frames can be used as seeking points.

Forcing every intra frame to become a keyframe will ensure that when a codec decides to insert an I-frame it is in fact an IDR-frame. This improves seekability of the file, while giving up a little bit of quality.

[akupenguin]

Intra frames always use no temporal prediction (that's what intra means.) But unlike previous formats, H.264 uses multiple reference frames, so just being intra does not guarantee that you can decode the following frames. So there's another kind of frame "IDR" which additionally guarantees seeking by blocking old references. Usually there's little or no loss from always using IDR on scenecuts, but sometimes (e.g. flashes or very high motion), the movie cuts back to the previous scene a few frames later. And then it can save some bits with multiple references if it didn't IDR.
If you are not using multiple refs, always set this to 1.
If you are, then I will eventually make this decision adaptive, but until then there isn't a good setting. (1 => wastes bits in high motion, 2 => wastes bits in low motion.)

[708145]

what about setting a max_idr_distance?
So worst case seekability is configurable but codec is still not forced to use a IDR too often.

bis besser,
Tobias

[akupenguin]

Yes, that's the plan. I'm just spending more time discussing it than implementing it.

[Sirber]

x264 dev? nice :D Are you using the videolan svn?

[akupenguin]

Yes, the official repository is the one on videolan.

[akupenguin]

I might have just fixed people's problems with blocks in B-frames. Or I might not. If not, someone will have to send me a sample, because I can't reproduce the bug here.

[JoeBG]

Originally posted by akupenguin
I might have just fixed people's problems with blocks in B-frames. Or I might not. If not, someone will have to send me a sample, because I can't reproduce the bug here.

Wow, that´s good news, you have my admiration :). What do I have to update for MeGUI and for sex264 to begin with testing? (sorry if this is a stupid question):(

[bond]

Originally posted by JoeBGermany
What do I have to update for MeGUI and for sex264 to begin with testing? (sorry if this is a stupid question)you have to wait till someone compiles a new version of sex264 or mencoder :)

[hellfred]

Originally posted by JoeBGermany
Wow, that´s good news, you have my admiration :). What do I have to update for MeGUI and for sex264 to begin with testing? (sorry if this is a stupid question):(
To get latest x264 improvements using MeGUI you need to get a mencoder.exe which was linked to a libx264.a build from x264 rev 92.
If you want it right away, you have to take it up with compiling mplayer/mencoder yourself. It is not that hard, as the howto i posted before tells you what to do step by step. Leave out all libs you do not need as you do not want to use the feature conneted to the lib. So if you e.g. do not plan to encode from a set of jpeg/gif/png pictures, there is no need to build those libraries.
So no need for
Step 2 ogg and vorbis
Step 3 freetype (for osd font rendering)
Step 4 zlib, libregif, libpng, libjpeg
Step 6 live.com rtsp streaming support

Which leaves you with
Step 1 Mingw and msys
downloading and installing MSYS/MinGW.
(Windows installer, one will ask you to type in some information)
Step 2 directx headers
(enhanced)Step 5
Just do the steps needed to build nasm and x264
Step 7 MPlayer
Try it, it is not that hard.

Hellfred

EDIT: directx may be mandatroy, too, as they are just needed for playback, but downloading an unpacking an archiv is not that much work to get an very fast player addidional to mencoder.exe.

[sysKin]

Originally posted by JoeBGermany
Wow, that´s good news, you have my admiration :). What do I have to update for MeGUI and for sex264 to begin with testing? (sorry if this is a stupid question):( OK, revision 92 (with today's date) uploaded. Just for you.

This time, I compiled it with MinGW / GCC. In theory, this binary should be much faster, because all optimized assembler code is compiled - contrary to MSVC build which is unable to compile optimized motion compensation (not fully ported to nasm yet...).

Have fun,
Radek

[JoeBG]

Originally posted by sysKin
OK, revision 92 (with today's date) uploaded. Just for you.
Wow ;) :thanks:

So noone else is allowed to use? :rolleyes:

[celtic_druid]

Revision 93:
Changes the mechanics of max keyframe interval:
Now enforces min and max GOP sizes, and allows variable numbers of
non-IDR I-frames within a GOP.

Seems to work ok, however I did have to change codec.c, codec.h and x264vfw.h to match the new x264.h (no more i_idrframe and iframe).

[sysKin]

..and another update :)

This is still revision 92 (so doesn't contain new keyframe code) but with a simple change, discovered by virus (thanks! hehe, again): removed profiling code, which calculates how long different parts of the core take to complete.

Result - ~7% faster for me and *many many times* faster for virus.

New binary, along with a diff (vs revision 92 or 93, doesn't matter), available at the usual place.

[len0x]

Can someone tell me how does x246's one pass encoding comparing to XviD's one pass in terms of quantizers? They probably not the same, aren't they? (as range is 0-51 vs 1-31)

[virus]

:) <--- virus

Eh-eh, all the countless hours spent trying to understand why my PC was the only one where sex264 was 3x slower than any other machine around finally produced the result: I found the problem!

It lurks on encoder.c, and more specifically in 6 static 64-bit variables that measure the encoding times internally. Removing them, as well as the associated logging, produced an increase in performance which ranges from 2.5x to 3.6x depending on the options... but, as sysKin already said, looks like that you all are going to enjoy a bit of extra-speed, and that's great :)

Just don't ask me why that happened, and why so badly only on my machine. The code I trashed is slow, and maybe it even made the ASM b0rk or get misaligned, who knows... :rolleyes:

cheers :)
virus

And remember: every year thousands of programmers are killed by static variables. Help us save them! Don't use static variables in your code!

[Sirber]

to play with sex264, I just need SVN client and M$VC++ 6?

[Leak]

Originally posted by virus
And remember: every year thousands of programmers are killed by static variables. Help us save them! Don't use static variables in your code!

Nononono...

It's spelled "Every time you mis-use a static variable, god kills a kitten." ;)

[sysKin]

Originally posted by Sirber
to play with sex264, I just need SVN client and M$VC++ 6? Yup. For SVN, I use Tortoise SVN (http://tortoisesvn.tigris.org/). M$VC 6 will let you compile, but using MinGW, you can compile a faster binary. Your choice.

Radek

[hellfred]

Originally posted by Sirber
to play with sex264, I just need SVN client and M$VC++ 6?
Compiling x264 using MinGW/Msys is a piece of cake!
Help yourself to a svn.exe from out of one of the win32 binary archives from tigirs and place it to /mingw/bin to be able to use it.
Than a very simple skript sould do it:

#!/bin/sh

# Script for automatic downloading/updating of x264,
# compiling and installing it so that mplayer's config script will find it.
svn co svn://svn.videolan.org/x264/trunk x264
cd x264/build/cygwin
make
cp bin/libx264.a /mingw/lib
cd ../..
cp x264.h /mingw/include
The last three lines are just to move the libx264.a and x264.h to a place where mplaysers configure-script will detect them and build mencoder whith ability to encode using x264 (MeGUI).
I have never tryed to include building syskins vfw interface up to now.
Does it come with a makefile, or just with dsp?

Hellfred

[gotaserena]

Have virus' modifications been commited to svn yet?

[Sirber]

got the sources, installing MSVS6sp6. I will start playing with it tonight. Been a while for C++ :) I will use another compiler if I produce binaries :D

[virus]

Originally posted by gotaserena
Have virus' modifications been commited to svn yet?
well, let's leave akupenguin sleep a bit, he did a commit tonight... not to mention that the fix has been found less than 3 hours ago ;)

[gotaserena]

It's 4:30 PM here! He can't be sleeping! :P

Only joking, of course. I've just thought of doing a psnr shoot-out with my copy of "black hawk down", and having a faster code would help.

But I shouldn't complain: mencoder got 3x faster since I've moved from FC2 to gentoo...

[Sirber]

from gentoo, you simply "emerged" it?

[gotaserena]

Yup, but I installed cvs on top of it afterwards. Saved me the time of finding fonts, win32 codecs, etc. and configuring the gui.

[Sirber]

just looked at the todo... :eek: is there a good PDF about h264 so I can get some concepts? :D

[edit]

Might just play with the GUI :rolleyes:

[SeeMoreDigital]

I've been generating SExh264 encodes using MPEG Mediator... And just wanted to check if the GUI's and function settings I'm seeing, are the same as everybody else is seeing?

http://img132.exs.cx/img132/8449/sex264codec0yu.gif


Cheers

[Sirber]

set max bf to 1, and max reference 16 :D

[IgorC]

sex264 (12 jan.)

b-frames work good. i tried 2-3 bframes and 15 ref

while Xvid 1.1 and Nero AVC have a frames as IBBP IBP IBBPBBBP
sex264 has a strange consecuence of frames like IPBBP IPBBBP

first is I frame (it´s normal) then P-frames is followed by b-frames (strange??)

i used ffdshow (12 jan Celtic Druid has a bug with OSD turned on) for decode xvid, nero avc,

sex264.

there´s no differnces in time of coding between 10 jan. and 12 jan. versions of sex264.
(celeron4 sse2)

[Sirber]

the celtic ffdshow I have has a bug with bframes, with AVC and sex264.

[edit]

which is squares :)

[jdobbs]

At the risk of sounding as clueless as I probably am... I tried this codec by using VDub to encode a small video segment. When I try to play back the resulting -- AVI my system reboots.

Am I too stupid to be helped?

EDIT: Perfect timing... I just tried the newer (FASTER) version and it works..

[Ark]

@SMD

Yup, these are the correct windows, for what i can see all is in the right place.

[dvd_maniac]

I was wondering if anybody here has moved from doing there encodes from Nero Digital's AVC to this codec? I am getting fustrated with ND and the Audio sync errors, Low Volume ACC and encoding speeds.

Can somebody give me an idea of the Pros & Cons of switching to this one?

I use ND to encode my dvd collection onto hard drive at about 300MB/hour of video. Somewhere around 750kbps.

[Joe Fenton]

Originally posted by gotaserena
But I shouldn't complain: mencoder got 3x faster since I've moved from FC2 to gentoo...

The only way that would happen is if you were using an old binary compiled for i386 in FC2. Gentoo generally builds from source, so you probably went from an unoptimized i386 build of an older version to a new build for i686 with extensions. If you had built mencoder on FC2 instead of fetching a binary from the respository, you'd have seen the same speedup. ;)

[Sirber]

Originally posted by gotaserena
Yup, but I installed cvs on top of it afterwards. Saved me the time of finding fonts, win32 codecs, etc. and configuring the gui. good. from source it's always better :D

[akupenguin]

Originally posted by Sirber
is there a good PDF about h264 so I can get some concepts?
http://vcodex.com/h264.html is a pretty good overview.

[Sirber]

cool, thanks :D

[gotaserena]

anybody played with the 3-pass mode? Is it worth the extra time?

[Yong]

x264vfw always crash for me if i resize the video to resolution
768x576(this res is 16mod and 4:3), PreciseBibubic=0.75, with virtualdub1.63/mod...
the source video is 800x600.

But doesn't crash mencoder if i using the same resize parameter.:)
Bug?

[JoeBG]

How can I properly deinstall the programm. I still have blocks with b-frames in 2 pass mode and I want to check if it´s getting better after deinstall and reinstall again.