x264 development

[Tommy Carrot]

Thanks for the clarification, i was thinking only about the encoding delay. :)

[Capirossi]

nice codec :cool:

[lithoc]

Since rev150, I can't playback anymore.
It only playback for less tha a second then it crashed.

mplayer says:
[h264 @ 008E8E08]reference picture missing during reorder

Disregard if this issues have been identified.

Thanks for the great codec, now just hope it's compatible with hd-dvd/avc hardware player when it release

:)

[Sharktooth]

Try updating mplayer...

[lithoc]

Originally posted by Sharktooth
Try updating mplayer...

I'm using mplayer dated 5th March from http://oss.netfarm.it/mplayer-win32.php

Problem still exist

[Chainmax]

Originally posted by Doom9
there is no application that can encode using the x264 codec and put the video data into the MP4 container. You'll need to either create a raw output and mux that into MP4 using a tool like mp4creator, or make an AVI, extract the AVC video using avi2raw, then mux the raw data into MP4.

I understand, but the FAQ says that AVC in AVI doesn't allow implementation of some AVC features. What I don't fully understand is wether these limitations can appear at the encoding level (thus creating "broken" encodes) or just at the decoding level (so just using your suggestions would solve the problem.


I also have another question: I see that the H.264 specs include RDO and my question is wether H.264's RDO is identical to Xvid's VHQ or if there can be different approaches to RDO. Also, can Trellis be implemented in x264 or am I just talking nonsense?

[akupenguin]

Originally posted by Chainmax
I understand, but the FAQ says that AVC in AVI doesn't allow implementation of some AVC features. What I don't fully understand is wether these limitations can appear at the encoding level (thus creating "broken" encodes) or just at the decoding level (so just using your suggestions would solve the problem.
It's on the decoding end. You can always demux H.264 from AVI, and the result is the same as if you put it in a different container to begin with.

I also have another question: I see that the H.264 specs include RDO and my question is wether H.264's RDO is identical to Xvid's VHQ or if there can be different approaches to RDO. Also, can Trellis be implemented in x264 or am I just talking nonsense?
No, the H.264 specs do not contain RDO. RDO is not something that can be specified in a standard. It's an encoding technique, and it could be applied to any lossy codec you've ever heard of. However, the H.264 format is very different from ASP, so fast RDO requires different tricks.
Trellis does not really apply to CABAC, and trellis for CAVLC is harder that for ASP.

[Chainmax]

Got it. I misread the FAQ when it said "RDO is not a tool defined by the AVC/H.264 specs....was first introduced by the H.264 reference software". Anyway, I don't know how hard would it be to implement VHQ in H.264, but what about leaving it as an option like in Xvid?

[stephanV]

that RDO comment is inappropriate there in the sticky... its confusing...

[RadicalEd]

x264 encoding support has just been patched into FFMPEG.

[Sharktooth]

New Pentium2 build available (no SSE) in the daily builds thread. I also added an Athlon Thunderbird build (no SSE).
Both use -ffast-math so please test them and report back if they crashes.

EDIT: P4 Prescott with SSE3 support build is also available.

[ivan_alias]

Originally posted by RadicalEd
x264 encoding support has just been patched into FFMPEG.

This is good news isn't it!

[springl]

x264 compilation by sharktooth, bobor, CD
From rev 144 on, I'm getting garbage a few frames after last I frame, with this settings:
default + update statsfile unchecked + max consecutive B-frames 1 + max reference frames 15 + deblocking unchecked.
Same settings + max reference frames 1 seems to be OK.
Here Athlon Thunderbird CPU + win98SE OS

Greetings
Springl

[IgorC]

rev164 doesn´t work full recompress in Virtual Dub. Only fast

[unmei]

this line from the changelog in the sticky should explain it:

(r164) VfW: reject YUY2 and RGB input formats

[planet1]

Originally posted by IgorC
rev164 doesn´t work full recompress in Virtual Dub. Only fast

from what I see there are two options (if source is not @ yv12):

either convert to yv12 via avisynth first,

or use Virtualdub 1.6.4 which has more colour depth options (setting output to YV12)

---> all recompression modes should work with x264 now

[dragongodz]

either convert to yv12 via avisynth first,
or use Virtualdub 1.6.4 which has more colour depth options (setting output to YV12)
and if you are using a different program ,not avisynth or virtualdub, that doesnt output yv12 ?

so what was the thinking behind making x264 only accept yv12 anyway ? seems a strange idea since most codecs accept multiple inputs.

[Ark]

Probably because x264 can't (yet i suppose) do RGB/YUY2/whatever to YV12 internal conversion.

[celtic_druid]

Revision 166:
revert 164. blame Spyder.

and for reference...
Revision 164:
VfW: reject YUY2 and RGB input formats

[dragongodz]

Probably because x264 can't (yet i suppose) do RGB/YUY2/whatever to YV12 internal conversion.
well thats strange since i just did a little test using RGB24 to x264 revision 150 and it not only encoded fine but played back fine with ffdshow(using libavcodec) fine aswell.

also how were people using earlier than 1.64 virtualdub versions and encoding fine ?

[EDIT]
revert 164. blame Spyder.
ahh so it should be back to accepting RGB and YUY2 then. cool.

[Sharktooth]

rev. 170 up.

[hpn]

Sharktooth, does your generic 170 build take advantage of the SSE optimization introduced the latest rev.170, or "generic" in this case means that there will be no speed improvement over 169? (I guess "SSE optimized chroma MC" in r170 means speed optimization only, but I maybe wrong). I don't know much about these CPU things, but always looking for the best build for my Atlhon XP that has SSE support. I also have no idea how celtic druid or bob0r compile their latest stuff (most likely generic too).

[Sharktooth]

I've compiled a SSE build too. Check it out.

[hpn]

Thanks!:)

[planet1]

Originally posted by dragongodz


also how were people using earlier than 1.64 virtualdub versions and encoding fine ?


its a VirtualDub 1.6.x glitch (1.5.x has a different colour handling) and also affects XviD & DivX:

http://forums.virtualdub.org/index.php?act=ST&f=15&t=9236&

[dragongodz]

virtualdub works in RGB in full processing mode, which is default so most people would actually be using it.

if you read above however you will see x264 does accept RGB and it has already been fixed back to being accepted.

[Yong]

Is the b_pyramid enable by default in x264vfw?
i got crashed decoding with ffdshow or mplayer if encode video using x264vfw...
The patch (libavcodec.bpyramid.7z)by Celtic druid doesn't work for me, strange.:(
BTW my own compile x264.exe cannot run,
when i execute it, i got "something entry point not found" then it closed.
(sorry, can't remember the message...)

[Sergejack]

I got a recurrent bug with the 170 rlz.

the ecnode just screw a part, then the vidéo get desync.

[Yong]

After reading the mplayer man page, b_pyramid=use b-frames as reference frame:rolleyes:
Why the name in vfw isn't same as mencoder?
It's make newbies confusing:(
After turn it off everything went fine:D

Here's the error message went i execute the x264vfw:
x264.exe - Entry point not found
The procedure entry point AVIFileExit cound not be located in the Dynamic link library MSVFW.DLL
What's wrong with it?
previous revision doesn't have this problem.

X264 development is very fast, now already r174, great:)

[virus]

Originally posted by Yong
After reading the mplayer man page, b_pyramid=use b-frames as reference frame:rolleyes:
Why the name in vfw isn't same as mencoder?
It's make newbies confusing:(
This is a deliberate choice.
Keep in mind that most n00bs out there approach the codec for the first time through VfW without knowing absolutely nothing about mencoder (which is still a tool for advanced encoding users like us :)).
So they should familiarize themselves with the term "reference" which is already a popular one (especially for AVC), instead of the pyramid thingie that, granted, sounds cool but also very very technical.
So technical that, for example, I've never heard sysKin using this name before akupenguin introduced it, despite the fact that on the topics of motion estimation and frametype decision, sysKin knows one or two things more than all of us ;)

Anyway, usually in VfW the names try to be as simple and direct as possible.

x264.exe - Entry point not found
The procedure entry point AVIFileExit cound not be located in the Dynamic link library MSVFW.DLL
Something is wrong here. This has something to do with bobololo's patch for AVI/AVS input in x264.exe afaict, though I've never heard of such problems. In fact the patch works ok for me, and mind you I'm on Win98SE. So if it works for me, it should work for everyone :)
(btw I have a library called msvfw32.dll *not* msvfw.dll, and I've been told that the name msvfw32.dll seems to be the right one under both 9x and NT kernels... are you sure you didn't screw up things? and which is the last revision which worked for you?)

[scorpdt]

I hope this is the right place to post my problem .... as I am not sure whether the problem lies with x264 codec or the mencoder itself.

The issue being ....

I have a movie which is 3 hours long, it is my plan to encode the whole movie using mencoder (MeGUI) into 2 CD. I had the audio encoded separately into aac_he 6 channel. Feeding the avs script and audio into MeGUI returned me the projected video bitrate of 886 kbit/s (I trust that value).

Before embarking on the whole movie encoding, I did a small sampling of 900 frames (using Trim in avs script) of a specific scene (music video) and run an Automatic 2 Pass @ 886Kbps bitrate (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log1.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-900Frames-886Kbps.avi).

Next I did another sampling of 12255 frames (adding 11355 frame to the above) and run an Automatic 2 Pass @ 886kbps (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log2.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-12255Frames-886Kbps.avi)(44MB).

Now should you are to compare the output you would expect the 1st 900 frames of the 2nd encoding would be close to the 1st sampling did above .... but they are not. The quality of the 1st 900 frames in the 2nd encoding is much much lower. Should you are to look at the skyline there are a lot of block pixels which points to lower bitrate. I did a cut-out of the 1st 900 frames using VDM and save the cut-out AVI file out (http://www.logisticshub.com/uploads/misc/VZ-0-900Frames-886Kbps.avi). Loading the cut-out file back on VDM, I found the average bitrate is 401kbps.

I am not sure what influence the kind of output I am getting .... so can someone help analyze and probably determine where the problem lies ... x264 or mencoder?.

FYI, I am using the latest x264 (build 177) and latest mencoder (dev-CVS-050315) ... the same problem happens on earlier builts for both.

Lastly, my apology if my explaination above confuses you. But please look at the files (both the log and AVI file) to understand the problem I mentioned above and please post you thought and possible solution.

Cheers!
Scorpio

[Ghim]

Originally posted by scorpdt
I hope this is the right place to post my problem .... as I am not sure whether the problem lies with x264 codec or the mencoder itself.

The issue being ....

I have a movie which is 3 hours long, it is my plan to encode the whole movie using mencoder (MeGUI) into 2 CD. I had the audio encoded separately into aac_he 6 channel. Feeding the avs script and audio into MeGUI returned me the projected video bitrate of 886 kbit/s (I trust that value).

Before embarking on the whole movie encoding, I did a small sampling of 900 frames (using Trim in avs script) of a specific scene (music video) and run an Automatic 2 Pass @ 886Kbps bitrate (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log1.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-900Frames-886Kbps.avi).

Next I did another sampling of 12255 frames (adding 11355 frame to the above) and run an Automatic 2 Pass @ 886kbps (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log2.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-12255Frames-886Kbps.avi)(44MB).

Now should you are to compare the output you would expect the 1st 900 frames of the 2nd encoding would be close to the 1st sampling did above .... but they are not. The quality of the 1st 900 frames in the 2nd encoding is much much lower. Should you are to look at the skyline there are a lot of block pixels which points to lower bitrate. I did a cut-out of the 1st 900 frames using VDM and save the cut-out AVI file out (http://www.logisticshub.com/uploads/misc/VZ-0-900Frames-886Kbps.avi). Loading the cut-out file back on VDM, I found the average bitrate is 401kbps.

I am not sure what influence the kind of output I am getting .... so can someone help analyze and probably determine where the problem lies ... x264 or mencoder?.

FYI, I am using the latest x264 (build 177) and latest mencoder (dev-CVS-050315) ... the same problem happens on earlier builts for both.

Lastly, my apology if my explaination above confuses you. But please look at the files (both the log and AVI file) to understand the problem I mentioned above and please post you thought and possible solution.

Cheers!
Scorpio

When you do a 2-pass encoding, you get a variable bitrate video, which is perfectly fine. It's up to the encoder and its rate control to give more or less bitrates for the different parts of the video. On the 12255 encode, the codec probably estimated that some parts after the 900 first frames required more bitrate (due to higher temporal or spatial complexity by example). That's why you get a lower bitrate (401 kbps) on the 900 first frames...
There is no problem at all in this behaviour....

[Sharktooth]

Try lowering the bitrate variability and see if it helps.

[scorpdt]

Thanks Ghim .... I aware that is what 2-pass encoding does, but could not figure out why the variation is so great. In fact I just completed encoding the 12255 frames sampling on Nero Recode (6 ref, 0 b-frame, cabac, macroblock,deblocking, chroma optimize and adaptive [auto smooth])and the result is comparable to that of the 1st sample I did except that Nero takes 2 hours to encode. BTW, should you look at the 1st pass of job2-1 i.e. the 2nd sampling, the it returns 2463.8 kbps ... so? Perhaps there might be a way to control this variation and this points to what Sharktooth suggest "lowering the bitrate variability .... so pardon me Sharktooth for my ignorance .... how do you do that .... which parameter must I tweak.

Thanks in advance.

Cheers!
Scorpio

[baer999]

I can see that x264 is still in development, but my question is if Nero Digitals 264er codec will become better or do they stop their development, because I haven't heard of them for quite a long time !

[IgorC]

it just simply says : bitrate varibiality 60% as default.

[Sharktooth]

Uhm, in mencoder it should be the ratecontrol sensitivity option.

[scorpdt]

Thanks IgorC .... saw that on VDM.

Sharktooth ... on mencoder i.e. via MeGUI ... that setting is disable for Automated 2pass .... perhaps Doom9 can help reason out why it is disable.

I doing another encode on VDM (should have thought about this earlier)

Cheers!
Scorpio

[Doom9]

from the mencoder manpage:
rc_sens=<0−100> (CBR only)
ratecontrol sensitivity (default: 4)
So, I have my doubts that this setting even corresponds to the bitrate variability setting in the VfW.

I think qcomp=<0−1>
quantizer compression (default: 0.6).
Corresponds to variability in the VfW.. the value and range matches, and quantizer compression basically does limit the bitrate variability. If you look at the manpage description of this switch:
This affects the ratecontrol: a lower value makes the bitrate more constant, while a higher value makes the quantization parameter more constant.And this setting is not disabled in any mode.

[Sharktooth]

Yes, it's the qcomp without any doubts :)

[virus]

yes, the equivalent of VfW's "bitrate variability" is called "qcomp" in mencoder, and qcomp = bitrate_variability / 100; in fact qcomp defaults to 0.6.

BTW mencoder's options are explained very clearly in Mplayer's documentation (http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html) ;)

EDIT: I hope noone will complain that choosing "bitrate variability" as a descriptive name for the option in VfW is confusing n00bs...

[scorpdt]

Thanks Guys it is clear.... get much better output from VDM with BV@ 0.15.
Trying out mencoder now via MeGUI with qcomm @ 0.2.

Cheers!
Scorpio

[Yong]

Originally posted by virus
...Anyway, usually in VfW the names try to be as simple and direct as possible.
Sorry for the late reply...
actually it was too simple for me :D
x264vfw don't have doc, don't have tool tips...
The doc is at Mplayer man page....

Something is wrong here. This has something to do with bobololo's patch for AVI/AVS input in x264.exe afaict, though I've never heard of such problems. In fact the patch works ok for me, and mind you I'm on Win98SE. So if it works for me, it should work for everyone :)
(btw I have a library called msvfw32.dll *not* msvfw.dll, and I've been told that the name msvfw32.dll seems to be the right one under both 9x and NT kernels... are you sure you didn't screw up things? and which is the last revision which worked for you?)
Sorry, typo:rolleyes:,
it's msvfw32.dll...
I'm on WinXP SP1,
I won't touch the source code, before i compile x264,
I thinks r15x... of x264.exe work for me...
recently i have many many problem with my own compiled x264vfw,
example:
1. it doen't shown up the "about" window when i click the x264vfw about button at VD/MOD and tmpgenc....
2. When i try to encode video using CBR mode or Constant Quant mode,
x264vfw pop-up a "console message": "could not find x264 2 pass stats file...":eek:
CBR or Constant quant need 2pass stats file?
3. the "console message" window too small,the "OK" and "Cancel" button were "truncated"...

[virus]

@Yong:

I have no clue about your problems, except for a single thing which may or may not be related.
You said that r15x worked for you and then you had problems. Well, I had some problems with mencoder+x264 around rev 150 or 151 too: mencoder kept crashing each time I started an encode. The "culprit" was apparently MingW 3.1+gcc 3.2.3 I was using. I updated to 3.2RC3+gcc 3.4.2 and everything worked again. Maybe you're using an old gcc too?

[Yong]

Originally posted by virus
@Yong:

I have no clue about your problems, except for a single thing which may or may not be related.
You said that r15x worked for you and then you had problems. Well, I had some problems with mencoder+x264 around rev 150 or 151 too: mencoder kept crashing each time I started an encode. The "culprit" was apparently MingW 3.1+gcc 3.2.3 I was using. I updated to 3.2RC3+gcc 3.4.2 and everything worked again. Maybe you're using an old gcc too?
I think i must update the Msys and Mingw32..
I never encountered crash with encoding mencoder+x264, when i was start compiling x264(start form r15x) and mplayer myself,
execpt some compiling problem with mplayer.
I will post the result on tomorrow(may be)...:)

[Yong]

@virus:
After upgraded to MinGW-3.2.0-rc-3 and binutil , all problem are gone except first problem(see my last post),
But still can view the "about" window via resource hacker:)

[Sergejack]

I've got a buggy video that crashes players.

http://users.skynet.be/EAF/naruto_39op30fpsV2ns.avi

params :
up to 4 B-frame, usable as reference; spacial prediction.
min max IDX : 100-1000
3 pass , first one not turned to fast mode.

[skal]

Hi,
Originally posted by Sergejack
I've got a buggy video that crashes players.

This bitstream seems to overflow picture buffer capacity (DPB_Size)...

-Skal

[ksnif]

Hi,

I've noticed that there is a native decoder missing from the x264 distribution. There is a decoder in the source code, but as the developers say, it is "unusable". Is there a reason for leaving the decoding side behind? is ffdshow covering all decoding needs?

I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?

regards

keep up the good work!

[bond]

ksnif, you might want to join #x264 on irc.freenode.net :)