x264 development

[nDman]

VSSH uses packed B-frames, which are not supported by libavcodec's h264.
In other words: no, that clip is broken, but you can fix it by remuxing.

thanks for info :)

[puffpio]

Since I didn't find information about this - is x264 in the current version not supposed to be able to output mp4 files bigger then 4 gigabyte? I tried encoding huge files, but the resulting output always only plays back until around 4 gigs into the file, than all video players I tried just close/crash. Jumping via timeline to a later point also crashes the players. I tried with x264 in the v333 and v375b plus megui, different splitters and versions of ffdshow for playback with negative results.
Encodes of nero recode 2 of that file sizes play fine under the same conditions.
is your hard drive formatted with the NTFS file system? If you are still using a FAT32 file system, it's largest file can only be 4GB....there is a program called fat2ntfs or fat3tontfs or something that can convert your hard drive..it comes with windows 2000 or windows xp

otherwise..if you are using windows 98 or older..you are out of luck as they don't work with ntfs

[rig_veda]

is your hard drive formatted with the NTFS file system?

Yes. I'm using NTFS on WinXP, hence my question. As I said, nero is able to write readable mp4 beyond 4 gigabyte, x264 in my case was not, the file was only playable till around 4 gig into the file, and after that point, when jumping there by timeline or getting there through normal playback, would crash the player.

[Hyper Shinchan]

The problem is x264 default level is 5.1 and MeGUI doesnt pass --level command line option to x264.exe
Well, in the past build it outputs the video as L4, now it outputs it as L5.1
nobody ever told me about level and allowable values...
Is it possible to include it in a future release? Or can I change the level with some program^_^ ? Tnx.

[Doom9]

Is it possible to include it in a future release?If somebody tells me how to do it, sure. Is it just putting the level in the commandline, like 1.2, 2.5, whatnot or is there anything else that needs to be taken into account?

[charleski]

Yeah, I thought of adding --level when I did the levels enforcement code for MeGUI, but since I couldn't find any comment about what the form of the parameter should actualy be I left it alone.

[Hyper Shinchan]

I've tried making a pair of tests. It's sufficient to include the command "--Level x.x", but to make it really compliant you have to check the vbv bitrate and buffer, but if you selcet a level in megui it's already setted automatically. These are a pair of command-line that I've made:

C:\>"x264.exe" --bitrate 384 --ref 2 --mixed-refs --bframes 2 --subme 7 --b-rdo
--weightb --analyse p8x8,b8x8,i4x4 --vbv-bufsize 10000 --vbv-maxrate 10000 --lev
el 1.3 --progress --no-psnr --output "C:\Documents and Settings\Shinchan\Documen
ti\Progetto MP4\PSP\test_AVC\video.264" "C:\Documents and Settings\Shinchan\Docu
menti\Progetto MP4\PSP\test_AVC\video.avs"

C:\>"x264.exe" --bitrate 384 --ref 2 --mixed-refs --bframes 2 --subme 7 --b-rdo
--weightb --analyse p8x8,b8x8,i4x4 --vbv-bufsize 2000 --vbv-maxrate 768 --level
1.3 --progress --no-psnr --output "C:\Documents and Settings\Shinchan\Documenti\
Progetto MP4\PSP\test_AVC\video.264" "C:\Documents and Settings\Shinchan\Documen
ti\Progetto MP4\PSP\test_AVC\video.avs"

I don't know if there is something else to be keep in account (of course resolution and frame rate, but it's already setted with the "convalidate level" button).

[Doom9]

well.. all the level checks are already included (vbv, bitrate, resolution etc.), the only thing missing is the -leve on the commandline.

[Doom9]

he man page of mencoder in CVS is always up to date, with no more than a day or two of delays between the addition of a new 264 feature and sync of mencoder.Got a working link? I've been having issues with the mplayer homepage for months, and I have no CSV tools so something on the web would be nice.

[redfordxx]

Just an idea: Now x264 writes encoding speed in fps at the end. How about the speed and/or time of CPU only.
So that, when there are more processes running, I still know exactly the performance.

[Doom9]

How about the speed and/or time of CPU only.Please elaborate exactly how this would work and what the output would signify.

[redfordxx]

what the output would signify.Examle, I have seen many posts here and there, that this or that param is faster for encoding than other. And referring to fps. But when other processes are running, it is not so relevant.

Of course I know, it is cosmetics.

[LigH]

Calculating the application's CPU time "only" would probably require to monitor the process performance development (its relation to 100% time). In my opinion - too much efforts for too less use. If you want maximum speed, let the encoder run alone / if you want to work along, the speed won't be your primary target.

[redfordxx]

Calculating the application's CPU time "only" would probably require to monitor the process performance development (its relation to 100% time). In my opinion - too much efforts for too less use. If you want maximum speed, let the encoder run alone / if you want to work along, the speed won't be your primary target.
I meant at the end only. When writing the final report, look to elapsed process CPU time, take number of frames and divide.

[Doom9]

look to elapsed process CPU time, take number of frames and divide.And what's the significance of that? Furthermore, we have three performance counters, % privileges time, % processor time and % user time. Still, we have different hardware that plays a significant role as well, so FPS is only significant when you rule out hardware anyway. And then there's the thing that windows performance counters are a W32 thing, and x264 is platform agnostic, so there'd have to be a lot of extra platform specific code.

[redfordxx]

lot of extra platform specific code.understood... :D shortsighted

[charleski]

Since I didn't find information about this - is x264 in the current version not supposed to be able to output mp4 files bigger then 4 gigabyte? I tried encoding huge files, but the resulting output always only plays back until around 4 gigs into the file, than all video players I tried just close/crash. Jumping via timeline to a later point also crashes the players. I tried with x264 in the v333 and v375b plus megui, different splitters and versions of ffdshow for playback with negative results.
Encodes of nero recode 2 of that file sizes play fine under the same conditions.I know nothing about the x264 code, but this sounds as if there's a unsigned int used somewhere that is restricting the maximum filesize. I ran across a similar problem with another program and had to recompile it after changing a bunch of uints to longs to get it to read a large file from Recode.

[IgorC]

I have a bug with AQ here.

Source. Matrix 2. Progressive 23.98 fps. Chapter 20

avscript. AVS 2.5 from GK 0.35 pack 2.
mpeg2source("C:\MATRIX_RELOAD\prj\mx20.d2v")
trim(1425,2575)
crop(0,58,720,360)
LanczosResize(720,304)
Undot()

x264 rev 380 Sharktooth Build
The same settings for 1 and 2 pass.
Decoder : Nero 6.6.0.18 , ffdshow bobor build 26 noviembre. Both produce a bug.

x264 mx20.avs -o 2x380_aq.mp4 --pass 3 --bframes 3 --ref 16 --filter -1:-1 --bitrate 800 --stats --qcomp 0.75 --analyse all --weightb --me umh --subme 7 --b-rdo --mixed-refs --8x8dct --trellis 2 --progress --stats passes.log --aq-strength 0.5 --aq-sensitivity 15



Videosample http://rapidshare.de/files/8385446/2x380_aq.mp4.html
No problem without AQ http://rapidshare.de/files/8386156/2x380.mp4.html

Problematic frames are 600,601,....
No problem for 1 pass.

[Sharktooth]

can you post a screenshot? i cant see what's the "problem".

[IgorC]

During playback it's difficult to notice http://img463.imageshack.us/my.php?image=aqbug9jm.png
No bug for 3d pass

[Sharktooth]

i was looking at the wrong frames. it's from frame 652 to frame 659.

[charleski]

Colour Coefficients

Does h.264 use the same colour coefficients (Rec. 601) as Xvid and Divx?
I.e., should we be using Wilbert's ColorMatrix (http://forum.doom9.org/showthread.php?t=82217&page=1&pp=20) filter in the scripts when converting from MPEG2?

I suspect the answer is Yes, but I want to check.

[Edit] Hmm, bah, just realised it might be better simply to use the --colormatrix bt709 option. Does anyone use this?
(BTW, I have been seeing brightness shifts with my encodes, and was correcting them rather artificially in the past.)

[Sharktooth]

it's not about color, but artifacts.

[puffpio]

hmm intersting..I have also been noticing that my encodes get slightly darker.

sources are MPEG2 TS files captured from my cable box...

I'll give this a whirl

[puffpio]

Colour Coefficients

Does h.264 use the same colour coefficients (Rec. 601) as Xvid and Divx?
I.e., should we be using Wilbert's ColorMatrix (http://forum.doom9.org/showthread.php?t=82217&page=1&pp=20) filter in the scripts when converting from MPEG2?

I suspect the answer is Yes, but I want to check.

[Edit] Hmm, bah, just realised it might be better simply to use the --colormatrix bt709 option. Does anyone use this?
(BTW, I have been seeing brightness shifts with my encodes, and was correcting them rather artificially in the past.)
there might not a media player that will respect the colorspace flag...
that's what the vui.txt implies

w/o any tests who knows? maybe the ffdshow decoder respects the colorspace flag when converting from YUV to RGB for display?

it not..ColorSpace() looks like it will do the trick

[charleski]

there might not a media player that will respect the colorspace flag...
that's what the vui.txt implies

w/o any tests who knows? maybe the ffdshow decoder respects the colorspace flag when converting from YUV to RGB for display?

it not..ColorSpace() looks like it will do the trick
Just did a test (encoded a clip with and without the --colormatrix option), and no, ffdshow doesn't use it.

[ChronoCross]

hmm IDK if this is the right place to put this.. MEGUI x264 fails to open up avs file. Installer from rev.381. Here's the error. Worked with all the 280 installers. Also works with the latest "stable" release of full MeGUI.

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.InvalidCastException: Specified cast is not valid.
at MeGUI.VideoPlayer.InitializeComponent()
at MeGUI.VideoPlayer..ctor()
at MeGUI.MeGUI.openAvisynthScript(String fileName)
at MeGUI.MeGUI.inputOpenButton_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/microsoft.net/framework/v1.1.4322/mscorlib.dll
----------------------------------------
megui-x264
Assembly Version: 0.2.3.1018
Win32 Version: 0.2.3.1018
CodeBase: file:///C:/Program%20Files/x264/megui-x264.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system.windows.forms/1.0.5000.0__b77a5c561934e089/system.windows.forms.dll
----------------------------------------
System
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------
System.Drawing
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system.drawing/1.0.5000.0__b03f5f7f11d50a3a/system.drawing.dll
----------------------------------------
System.Xml
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system.xml/1.0.5000.0__b77a5c561934e089/system.xml.dll
----------------------------------------
rgc13lar
Assembly Version: 0.0.0.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------

************** JIT Debugging **************
To enable just in time (JIT) debugging, the config file for this
application or machine (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the machine
rather than being handled by this dialog

[berrinam]

@ChronoCross: Reproduced here. I've posted a bugfix on the MeGUI dev thread.

[Tima]

I get this error after playing one of my video files (x264 in mkv, produced by x264 CLI):

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Assertion failed!

Program: C:\Bin\Media Player Classic\mplayerc.exe
File: libavcodec/h264.c
Line: 2590

Expression: pic->data[0]

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)
---------------------------
Прервать Повтор Пропустить
---------------------------


Some of my friends told me thery also had this error (on some other videos).

For splitting I tried Haali Media Splitter and built-in MPC splitter. For decoding I use official ffdshow 2005-11-29.

If it's necessary, I can upload the sample that shows the problem.

[Sirber]

C:\x264\encoder\set.c(27) : fatal error C1083: Cannot open include file: 'inttypes.h': No such file or directory
c:\projets\x264\common\frame.h(27) : fatal error C1083: Cannot open include file: 'inttypes.h': No such file or directory

Where can I find that file? I'm trying to compile with VC++ 8. Thanks!

[Manao]

Define HAVE_STDINT_H and include x264/extras/stdint.h instead

[squid_80]

The start of frame.h should look like this:#ifdef HAVE_STDINT_H
#include <stdint.h>
#else
#include <inttypes.h>
#endif instead of just #include <inttypes.h> . I think you'll also have to add the quant and deblock assembly files to the project if you haven't already.

[Sirber]

------ Build started: Project: libx264, Configuration: Debug Win32 ------
Compiling...
analyse.c
c:\Projets\x264\extras\stdint.h(136) : warning C4005: 'SIZE_MAX' : macro redefinition
C:\Program Files\Microsoft Visual Studio 8\VC\include\limits.h(92) : see previous definition of 'SIZE_MAX'
c:\projets\x264\encoder\cabac.c(197) : error C2059: syntax error : '}'
..\..\encoder\analyse.c(1723) : warning C4244: '=' : conversion from 'int64_t' to 'int', possible loss of data
cabac.c
c:\Projets\x264\extras\stdint.h(136) : warning C4005: 'SIZE_MAX' : macro redefinition
C:\Program Files\Microsoft Visual Studio 8\VC\include\limits.h(92) : see previous definition of 'SIZE_MAX'
..\..\encoder\cabac.c(197) : error C2059: syntax error : '}'
Generating Code...
Build log was saved at "file://c:\Projets\x264\build\win32\Debug\BuildLog.htm"
libx264 - 2 error(s), 3 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
:(
static const int i_mb_bits[9*3][7] =
{
{ 1,1,0,0,0,1 }, { 1,1,0,0,1,0, }, { 1,0,0 }, /* L0 L0 */
{ 1,1,0,1,0,1 }, { 1,1,0,1,1,0 }, {}, /* L0 L1 */
{ 1,1,1,0,0,0,0 }, { 1,1,1,0,0,0,1 }, {}, /* L0 BI */
{ 1,1,0,1,1,1 }, { 1,1,1,1,1,0 }, {}, /* L1 L0 */
{ 1,1,0,0,1,1 }, { 1,1,0,1,0,0 }, { 1,0,1 }, /* L1 L1 */
{ 1,1,1,0,0,1,0 }, { 1,1,1,0,0,1,1 }, {}, /* L1 BI */
{ 1,1,1,0,1,0,0 }, { 1,1,1,0,1,0,1 }, {}, /* BI L0 */
{ 1,1,1,0,1,1,0 }, { 1,1,1,0,1,1,1 }, {}, /* BI L1 */
{ 1,1,1,1,0,0,0 }, { 1,1,1,1,0,0,1 }, { 1,1,0,0,0,0 }, /* BI BI */
};
the line with "{ 1,1,0,1,0,1 }, { 1,1,0,1,1,0 }, {}, /* L0 L1 */"

[squid_80]

If you look back in this thread, you'll see me posting about the same problem and akupenguin advising that putting any number in the empty braces will make it go away.

[Sirber]

in this 75 pages thread? ;)

ok thanks :D

[molinacabaleiro]

Is there any way of setting zones (for the credits)?

[redfordxx]

Is there any way of setting zones (for the credits)?http://forum.doom9.org/showthread.php?t=94922
and read carefully not to be suspended :D

[bond]

http://forum.doom9.org/showthread.php?t=94922
and read carefully not to be suspended :D :p ;)

[redfordxx]

:p ;)Hey Bond, don't laugh, you still think the answer was there after all my additional posts there? I do not. ;)

[bond]

Hey Bond, don't laugh, you still think the answer was there after all my additional posts there? I do not. ;)of course the answer was there. you just misunderstood how zones work (as doom9 wrote)

[redfordxx]

of course the answer was there. you just misunderstood how zones work (as doom9 wrote)I think I did understand but I wanted more...
But it is OT, at least in this thread, sorry for it...

[DarkFoon]

I've noticed a few wierd things going on with Sharktooth's x264 build 381.
It seems that after about 1 hour of encoding, (on any pass without 'turbo' turned on)
the fps just begins to slow down. I'd call it a memory leak, except it isn't. Its like a processor leak, if such a thing exists.
It doesn't even matter what the source is, anime or 'real' video. Or how long it is, ~30mins or ~60 mins. Just after 1 hour of encoding (not one hour of source, mind you), the fps starts dropping from about 7 fps until it reaches something like .96 fps. It would probably drop even further if it weren't for the encode being done.
I've only noticed this problem since I upgraded to Sharktooth's build 381. The earlier one worked just fine.
Is this a known issue? (am I in the right thread?)

EDIT:
I've seen this problem in every build I use from bob0r or Sharktooth. Even on different systems (p3 windows ME / p4 windows 2k).
does anybody know the cause?

[Selur]

What are the min/max values for aq-sensitivity and aq-strength ?

Is the statement form the mplayer manpages accurate?
turbo=<0-2>
Fast first pass mode. During the first pass of a two or more pass encode it is possible to gain speed by disabling some options with negligible or even no impact on the final pass output quality.
0
disabled (default)
1
Reduce subq, frameref and disable some in- ter-macroblock partition analysis modes.
2
Reduce subq and frameref to 1, use a dia- mond ME search and disable all partition analysis modes.
Level 1 can increase first pass speed up to 2x with no change in the global PSNR of the final pass com- pared to a full quality first pass.
Level 2 can increase first pass speed up to 4x with about +/- 0.05dB change in the global PSNR of the final pass compared to a full quality first pass. Quelle: http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html#VIDEO%20FILTERS

The x264CLI does support the turbo option, doesn't it?
(it's not mentioned in the help; x264.exe -h)

Cu Selur

[charleski]

'Turbo' mode is managed by whatever front-end you use (like MeGUI or mencoder) which constructs the command line that's fed to x264.

[Selur]

Ok, thx for the info. :)

Cu Selur

Ps.: Does any decoder honor the flags set in the vui of x264?

[redfordxx]

Let's say, the encoder is creating a frame for example at qp=20. When it is searching for a reference for any block and finds one which is enough for qp=20, does it stop searching even when there could be another and perfect match for example for qp=10 quality?

[akupenguin]

"fast pskip" works something like that. It predicts the motion vector for the current block. After the first round of motion search (16x16, ref #0), if the best mv found is equal to the predicted mv, and it's "good enough", then it stops searching.

[Marsu42]

@x264 devs: It would be nice if an "average fps" mode would be made possible.

I guess it would make sense for real time encoding, but for my personal x264 usage "re-encode a video during the night" or "re-encode a video in the background" it is rather hard to choose the quality options because one never knows how long it will take. On the one hand, I often use different filters in the avisynth script, so the only way to get an idea of the speed to be expected would be to measure each script's throughput with avstimer. On the other hand, it seems to me that the speed of x264 ittself is rather tricky to predict with different sources. If there was an option "--fps" in addition to "--bitrate", the encoder could dynamically add or drop options like --b-rdo or e.g. change the # of --ref frames to achieve the desired filesize with the maximum possible quality for a predetermined time frame.

Unfortunately, I am unable to code this stuff myself, so I can only post the idea as a request. But eventually there are others out there who also think that this option might be useful?

[Sharktooth]

no codecs have such a feature and it's quite impossible to add it.

[akupenguin]

Not at all impossible. libx264 supports changing encoding options on the fly. My intended method of realtime streaming (if I ever implement it) is: Have some list of presets at different speeds, and select between them based on how full the encoding buffer is. That would be "constant fps"; I don't plan to implement "average fps", but it wouldn't be any harder.