x264 development [Archive] - Page 6

SeeMoreDigital

26th September 2005, 20:53

just enable h.264 decoding in VFW config...Thanks for the confirmation Sharktooth.... It seems I have a problem MPEG-4/AVC in .AVI encode :eek:

I've been generating some video "test cards" from still images using an application called JPGAvi, however it seems to be adding an unwanted text element along with the video stream. Here's a sample (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/PAL_480(1024)x576.zip) encode.

I was hoping to use VirtualDubMod with FFdshow (20050920.exe) to re-mux the stream, so I could get rid of the unwanted text element.... but one (or both) of the applications doesn't like this idea!

I've also tried using AVI-mux to re-mux, but for some reason this application appears to be generating streams with borked headers and 4CC codes. Here's what appears in Nic's 4CC changer reports: -

http://img246.imageshack.us/img246/8330/h264avimuxremux0ea.png

And we you manually try to re-write the 4CC code, the encode becomes completely unusable!

Cheers

stephanV

26th September 2005, 21:07

The test file you uploaded can be remuxed perfectly with VirtualDub 1.6.10 and AVIMux GUI 1.17.1.5

SeeMoreDigital

26th September 2005, 21:22

The test file you uploaded can be remuxed perfectly with VirtualDub 1.6.10 and AVIMux GUI 1.17.1.5That's interesting!

With the AVI-Mux re-mux, does Nic's 4CC changer report the correct 4CC code values?

Could you e-mail the re-muxed file to me at SeeMoreDigital@msn.com please?

PS... Now I've forgotton how to set-up FFdshow to auto AR MPEG-4 media!

Cheers

stephanV

26th September 2005, 21:59

Heh, no it seems you are right. AVIMux GUI makes weird fourcc codes out of it, but the file CAN be opened in VirtualDub... I'll email them to you ASAP.

To enable AR signalling in ffdshow you have to the enable overlay mixer.

but this is kinda getting OT...

SeeMoreDigital

26th September 2005, 22:25

Thanks stephanV,

When trying to play the JPGAvi.avi source it appears VDM is trying to use Panasonic's DV codec: -

http://img317.imageshack.us/img317/7518/vdmobservation4dx.png

But thanks for clarifying the AVI-Mux 4CC code issue ;)

In the meantime I'll try removing Panasonic's DV codec to see what happens!

Cheers

stephanV

26th September 2005, 22:35

Ah yes, that old problem. Basically that codec will try to decode anything if another decoder is not found. (Try to change the fourccs of some random file to BEER and see what codec will popup ;) )

SeeMoreDigital

26th September 2005, 23:24

The problem seems to only occur with H.264 in AVI encodes generated by JPGAvi (ie: the ones that include the "text" element).

http://img272.imageshack.us/img272/8647/h264graphedit3hn.png

All my other H264 in AVI encodes appear to work perfectly in VDM, FFdshow, GraphEdit etc.... And sadly this is what confused me!

I'll have to get in contact with Alexander Noé regarding the borked 4CC data codes it's producing, because it also seems to be doing the same with MPEG-4/SP and ASP encodes!

I'll also have to work out how to de-install the Panasonic DV codec.. but I'm having trouble finding it :scared:

Thanks Stephan

foxyshadis

27th September 2005, 02:27

I'll also have to work out how to de-install the Panasonic DV codec.. but I'm having trouble finding it :scared:
Control panel->sound and audio->hardware->video codecs. From there you can uninstall, but it doesn't always work; if not, try vcswap (http://www.videohelp.com/tools?tool=614).

If the applet isn't there (it's not on mine, goofily), it's %systemroot%/system32/mmsys.cpl.

CEC

27th September 2005, 09:40

There must be something wrong in VFW! When I am encoding using fast first pass I have only 14.30 fps and when I encode with x264.exe in turbo mode (using the same settings always), I have 30,20 fps!!!! There must be something messed up in VFW!! :(

I use r304 from x264.nl

Sharktooth

27th September 2005, 13:26

VFW settings for fast first pass are different from those used in MeGUI for the CLI encoder. You will also notice the CLI encoder has more option than VFW...
Nothing is messed up, but CLI is more up to date.

LigH

27th September 2005, 14:46

Maybe too late, but in general:

@ SMD:

The tiny little "FourCC Changer" is stupid. It expects the FourCC at a specific position in the file. But AVI is a rather flexible format, made of chunks which may have different sizes and positions.

Better try "abcAVI" to inspect and change AVI header details. Or "Yet Another Avi Info" (YAAI).

SeeMoreDigital

27th September 2005, 15:30

SMD:

The tiny little "FourCC Changer" is stupid. It expects the FourCC at a specific position in the file. But AVI is a rather flexible format, made of chunks which may have different sizes and positions. The main problem I seemed to be experiencing appeared to be with AVI-mux not generating the correct 4CC code during re-muxing (not just with MPEG-4/AVC in AVI but with MPEG-4/SP/ASP in AVI too)....

Plus, now I've managed to remove Panasonic's DV codec, and use VDM for re-muxing everything appears to be working fine now ;)

Personally I've not had much trouble with Nic's 4CC Changer but I will see if the other tools you mentioned are any better at correcting the 4CC code data produced by AVI-mux....

Cheers

stephanV

27th September 2005, 15:32

SMD:

I emailed you about this issue, it is really the fault of the fourcc changer you use.

http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/en_faq.php

relevant passage:
Q: Why does an AVI file created with 1.16 work, but not one created with 1.17?
A: AVI-Mux GUI 1.17 introduces a feature to track down lazy coders: AVI files will, per default, have some junk before the first header, which is perfectly allowed and spec compliant, but might break a few programs. If this happens, disable "add JUNK..." in settings -> output -> AVI -> page 2, and file a bug report to the author of the program that failed on such a file.

SeeMoreDigital

27th September 2005, 15:42

SMD:

I emailed you about this issue, it is really the fault of the fourcc changer you use.

http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/en_faq.php

relevant passage:Yes I got your e-mail.... however the "AVI-mux" re-muxed file appears to be slightly borked "before" the 4CC code is changed!

Plus while I had Panasonic's DV codec installed, even the VirtualDub re-muxed sample you e-mailed me could not be opened in GraphEdit, which was a bit weird because all my other MPEG-4/AVC in AVI samples could.

Cheers

stephanV

27th September 2005, 15:54

Nope, the file is not b0rked. MS AVI splitter is. It works fine with gabest's splitter.

SeeMoreDigital

27th September 2005, 16:59

Nope, the file is not b0rked. MS AVI splitter is. It works fine with gabest's splitter.I guess this would make far more sense :D

Thank you everyone for helping me out with this...

Cheers

LigH

28th September 2005, 03:35

Nope, the file is not b0rked. MS AVI splitter is. It works fine with gabest's splitter.
And as well with Haali's Media Splitter.

Confirm this problem - has been discussed in the german board as well.

planet1

28th September 2005, 22:27

Not that I care much about AVC in AVI, but last time I checked Haali's AVI splitter was quite picky when it comes to dshow decoders ... :eek:

Marsu42

30th September 2005, 05:49

I've found a minor issue w/ mkv output in x264: The language in the video track seems to be auto-set to "eng" which in most cases makes no sense (video w/o hard subtitles) or might be plain wrong (video w/ non-english hard subtitles). Of course, one can change this when remuxing in mmg, but I think the default setting should be "und" = undetermined.

And if you, like doom9, think real l33t programmers don't care about stuff like that, just ignore this post :-)

akupenguin

30th September 2005, 06:43

Marsu42

30th September 2005, 07:31

ok, it might as well be something mmg is doing. All I can tell is that when you drop a mkv generated by x264 into mmg, it is set to "eng" while some avi produces "und"... can't tell about mp4 since I don't use these.

bond

1st October 2005, 13:40

can't tell about mp4 since I don't use these.the .mp4 files output by x264 have the language set to "undefined" for the video track

Sharktooth

2nd October 2005, 17:37

In my next builds i will gradually add some installer options and features. Please test those options/features so i can ask akupenguin to submit (once it's finished) the new install script to the SVN.
First addition: In rev311B the installer looks for a previous installation directory. If it exists it automatically set it as the default for installing the new version.

Kyle_Katarn

2nd October 2005, 22:52

I'm expecting a lot of VfW unstability issues.... would it be possible to have the debug log saved somewhere ?

Kyle_Katarn

2nd October 2005, 22:54

hpn

4th October 2005, 04:43

I have a question. In the CLI help (x264 -h) I read the following:

-A, --analyse <string> Partitions to consider ["p8x8,b8x8,i8x8,i4x4"]

As far as I understand p8x8,b8x8,i8x8,i4x4 is the default option according to the help. But i8x8 is part of the high profile, so is it really active by default or it's an error in the CLI help?

akupenguin

4th October 2005, 05:06

When I say that i8x8 is enabled by default, I mean that it is used if you enable --8x8dct.

berrinam

4th October 2005, 07:15

I find it peculiar that x264-cli will let you specify a CQM when encoding in lossless mode. Aren't CQMs meant to specify which details are kept and which are not, something irrelevant in lossless encoding.

akupenguin

4th October 2005, 08:10

There are lots of combinations that x264cli silently fixes, because it's easier than writing an error message for each one. lossless disables CQM.

hpn

4th October 2005, 08:38

When I say that i8x8 is enabled by default, I mean that it is used if you enable --8x8dct.
Thank you, It makes sense this way.

Now some thoughts for those who have time to rack their brains (the rest just ignore):
I have no idea how "--analyse" without any string like "all", "none" etc. is programmed to behave in CLI, but in my tests seems it equals "--analyse none". Also "--analyse --8x8dct" ignores the --8x8dct part and produces encode without 8x8 transform equal to "--analyse none" (withough --8x8dct) or "--analyse" (withouth any string at all). So IMHO if "--analyse" behaves like "--analyse none" then "--analyse --8x8dct" shouldn't ignore the "--8x8dct" part and should produce encode iqual to "--analyse none --8x8dct" (with 8x8 transform). Of course I may be wrong. I also noticed that Doom9 in MeGUI when (in High Profile) disabling all five MB patritions and enabling only "Adaptive DCT" generates a commandline "--analyse --8x8dct" which produces an encode equal to "--analyse none". So in this case even if --8x8dct is enabled in MeGUI the resulting encode doesn't use --8x8dct, so basically it's may be a bug in MeGUI and Doom9 should change the commandline to "--analyse none --8x8dct". But if the CLI gets changed to make "--analyse --8x8dct" equals to "--analyse none --8x8dct" (which I think is correct) then the problem is not in the MeGUI, but in the CLI.

Note: There is no practical reason to ever use something like "--analyse none --8x8dct", but just for the sport of it.

foxyshadis

4th October 2005, 18:39

Personally, I would make it so that when an unknown string was crunched after --analyse (or any other option expecting an enum-type string), throw an error. It's a bad command line and almost certainly a bug in the caller, after all.

hpn

4th October 2005, 21:16

After a few more tests I think I got it. There is actually no error in CLI (there is a small one in MeGUI x264 however), but due to the silent way CLI handles exceptions (as akupenguin said), one may end up with some unexpected results if inadvertently feeds CLI with a wrong command line. Examples:

(1)
x264 --bitrate 700 --analyse none --progress -o a.mp4 a.avs
A valid command line with progress and everything :)

(2)
x264 --bitrate 700 --analyse unknownstring --progress -o a.mp4 a.avs
The general case with some wrong, unknown string. In this case "--analyse unknownstring" is silently replaced with the valid "--analyse none"

(3)
x264 --bitrate 700 --analyse --progress -o a.mp4 a.avs
No valid string after "--analyse", but CLI thinks that "--progress" is its string, and because it's not valid, CLI replaces it with "--analyse none", then discards "--progress" and encodes without showing any progress info.

(4)
x264 --bitrate 700 --analyse --8x8dct --progress -o a.mp4 a.avs
Again no valid string after "--analyse" and CLI thinks that "--8x8dct" is this string, so it replaces it with "--analyse none", then discards "--8x8dct" and the resulting encode is the same as in (3), this time with progress.

As I mentioned in my previous post, example (4) also leads to an incorrect command line in MeGUI "x264 --bitrate 700 --analyse --8x8dct ....", that should be replaced with "x264 --bitrate 700 --analyse none --8x8dct ....". Although this bug exists it's only theoretical, cause no one will ever use such combination :)

jellysandwich

6th October 2005, 21:03

There's no .inf install script in the Lite r315 zip. Is it okay to use the one in r314?

js

celtic_druid

7th October 2005, 09:05

Yes. You could also just copy over the old dll.

bugmenotwillyou

7th October 2005, 09:56

i am trying to find the x264 source code for windows,
need help,
suggestions anybody

Haze_NZ

7th October 2005, 10:57

There's a link on the x264 website.

Getting x264

The latest x264 source code can always be found by anonymous SVN repository:

# svn co svn://svn.videolan.org/x264/trunk x264

bugmenotwillyou

7th October 2005, 11:23

thanks
but tried that
doesn't work

bugmenotwillyou

7th October 2005, 11:52

found source at
http://ffdshow.faireal.net/mirror/x264/

but when i try to compile the code using the libx264.dsw
i recieve errors of the sort
../..\common/common.h(305) : error C2485: 'align' : unrecognized extended attribute
../..\common/common.h(305) : error C2059: syntax error : '('

in the code

/* Current MB DCT coeffs */
struct
{
DECLARE_ALIGNED( int, luma16x16_dc[16], 16 );
DECLARE_ALIGNED( int, chroma_dc[2][4], 16 );
// FIXME merge with union
DECLARE_ALIGNED( int, luma8x8[4][64], 16 );
union
{
DECLARE_ALIGNED( int, residual_ac[15], 16 );
DECLARE_ALIGNED( int, luma4x4[16], 16 );
} block[16+8];
} dct;

bugmenotwillyou

7th October 2005, 11:53

does that seem familiar to any one
suggestions any one

celtic_druid

7th October 2005, 12:16

MSVC project files may be out of date. Most people I think use mingw to compile.

Sharktooth

8th October 2005, 16:19

"8x8 DCT" is hardly a feature belonging to the "I-frames" group ;)
(and I still prefer the term "integer transform" or simply "transform" instead of DCT. H.264 does not use the DCT at all)

Also, the name "Quality" for the quantization limits (min/max qp and max step) is highly misleading imho.
Fixed.

There aren't any options specific to I-frames (other than ratecontolr/scenecut). The "8x8 intra search" and "4x4 intra search" flags apply only to P & B-frames. I-frames always use all available MB types.
Fixed.
get the patch here: http://www.webalice.it/f.corriga/x264/vfw_patch.diff

peteag

9th October 2005, 12:06

hello. sorry for this break. but, is there any way of running x264 on "tiger"?

el divx

9th October 2005, 20:10

Sharktooth, could you update your patch to move the slider and the two text elements under it two pixels down so that the text box showing the slider's value doesn't get overlapped when the slider is selected.

I did it myself on my builds by modifying resource.rc but I don't know how to make .diff files in order to make a patch for it.

Here's what I did:
IDD_TAB_BITRATE DIALOGEX 0, 0, 200, 188
STYLE DS_SETFONT | DS_FIXEDSYS | WS_CHILD
FONT 8, "MS Shell Dlg", 0, 0, 0x0
BEGIN
CONTROL 108,IDC_LOGO,"Static",SS_BITMAP,31,12,136,39,WS_EX_CLIENTEDGE
COMBOBOX IDC_BITRATEMODE,30,66,138,66,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP
LTEXT "Average Bitrate (kbps)",IDC_BITRATELABEL,30,84,90,12
CONTROL "",IDC_BITRATESLIDER,"msctls_trackbar32",TBS_BOTH | TBS_NOTICKS | WS_TABSTOP,24,98,150,18
EDITTEXT IDC_BITRATEEDIT,144,84,24,12,ES_AUTOHSCROLL | ES_NUMBER
LTEXT "0",IDC_BITRATELOW,30,116,66,12
RTEXT "5000",IDC_BITRATEHIGH,108,116,60,12
CONTROL "Update Statsfile",IDC_UPDATESTATS,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,12,138,72,12
LTEXT "Statsfile name",IDC_STATIC,12,156,48,12,SS_CENTERIMAGE
EDITTEXT IDC_STATSFILE,60,156,102,12,ES_AUTOHSCROLL
PUSHBUTTON "...",IDC_STATSFILE_BROWSE,168,156,18,12
END

Sharktooth

9th October 2005, 20:16

Oh well.. it doesnt overlap ... maybe it depends on the visual style you're using...
however ill update it in the next build

el divx

10th October 2005, 06:44

Thanks.

Question: How do you remove a patch?

leowai

10th October 2005, 08:08

Thanks.

Question: How do you remove a patch?
Under MinGW, I use following commands for patching.

patch -p0 <./Input_patch.diff

You can try following command to reverse the APPLIED patch:

patch -R -p0 <./Input_patch.diff

or simply type

patch --help

for more information

Sagittaire

10th October 2005, 15:02

x264 use AQ : ready for HVS optimisation ... ???

Sharktooth

10th October 2005, 15:03

AQ is a Haali's patch and it wasnt committed yet.

Manao

10th October 2005, 15:08

afaik, it doesn't use adaptive quantization.

giandrea

11th October 2005, 02:28

hello. sorry for this break. but, is there any way of running x264 on "tiger"?

Sure, with MPlayer/MEncoder. I use it this way. First compile and install the library (get it from SVN), then compile and install MPlayer (get it from CVS), and you have an up-to-date tool to encode H.264, in AVI (unfortunately) via CLI.

Sharktooth

13th October 2005, 04:56

Im not an OSX expert but there should be encoding GUIs supporting x264.
Handbrake: http://handbrake.m0k.org/index.php
Handbrake port for tiger: http://handbrake.darwinports.com/

akupenguin

13th October 2005, 05:44

Does Handbrake count? It doesn't have any codec options at all other than bitrate/qp/pass ...

Sharktooth

13th October 2005, 15:34

well... i never used handbrake so i dont know about its (in)ability to (not) take advantage of the codec options and settings.
however there are also
mConverter: http://mconverter.sourceforge.net/ (dont know if it works on tiger though)
Dvision: http://www.apple.com/downloads/macosx/video/dvision.html
and more...

el divx

16th October 2005, 16:20

Does gprof has to be enabled all the time or only when building with --enable-debug?

Manao

16th October 2005, 17:20

gprof is usefull only to developpers. Using it for a real encode will only slow things down

JnZ

18th October 2005, 21:07

Hi guys,

today I've encoded Band Of Brothers HD to x264 and found strange error.
As you see on frame in attachment. The green rectangles.

Settings:
Input: AVS file:

LoadPlugin("decomb.dll")
OpenDMLSource("BoB1.avi",audio=false)
Trim(712,126914)
Telecide(order=1,guide=1).Decimate()

Output: AVI encoded in VDM 1.5.10.2, 1280x720 res.
x264 settings: x264 r327
2-Pass encoding at 4061kbps
- rate controll default
- 8x8 transform, 2 ref. frames, 3 B frames,Use as reference
- Partition decision: 6 RDO, Hexagonal search, deblock filter off
- every other settings at default

This errors appears only in encoded avi, only in black areas. In AVS opened in VDM not.

EDIT:
Today I found, that error isn't in x264 codec, because when I encoded same AVS script by XVID codec, same green blocks in same frames appears.

jellysandwich

19th October 2005, 23:12

Today I found, that error isn't in x264 codec, because when I encoded same AVS script by XVID codec, same green blocks in same frames appears.

Did you check to see if it's in the source?

js

el divx

22nd October 2005, 09:08

Sharktooth, here's the output when applying your Constant Rate Factor patch:
$ patch -p0 < x264_crf.0.diff
patching file `encoder/encoder.c'
Hunk #2 succeeded at 417 (offset 1 line).
patching file `encoder/ratecontrol.c'
patching file `x264.c'
Hunk #2 FAILED at 471.
Hunk #3 succeeded at 503 (offset 12 lines).
Hunk #4 succeeded at 577 (offset 3 lines).
1 out of 4 hunks FAILED -- saving rejects to x264.c.rej
patching file `common/common.c'
patching file `x264.h'
Hunk #2 succeeded at 207 (offset 3 lines).

Of course, when trying to build it gives out an error.

PS: I had already applied Adaptive quantization V1, ME and RD skip on sub16x16 blocks if 16x16 was found to be a SKIP (core) and RD patch V2 before applying this one.

Sharktooth

22nd October 2005, 14:58

i know. i fixed it manually. but if you dont apply th AQ patch it works as it is.

el divx

22nd October 2005, 15:38

i know. i fixed it manually. but if you dont apply th AQ patch it works as it is.

Can you give out the solution, pleeeaaase?

Edit: Cancel that. I found it:
#define OPT_ADAPTIVE_QP 315
#define OPT_AQ_STRENGTH 316
#define OPT_AQ_SENSITIVITY 317
#define OPT_CRF 318

sr78

24th October 2005, 11:01

Compile x264 on windows

Did anyone compile the x264 on visual studio lately?
I get the following linking errors:

Linking...
xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe'
x264.obj : error LNK2001: unresolved external symbol _strncasecmp
libx264.lib(encoder.obj) : error LNK2001: unresolved external symbol _x264_quant_init
bin/x264.exe : fatal error LNK1120: 2 unresolved externals
Error executing xilink6.exe.

x264.exe - 3 error(s), 0 warning(s)

I know that usually it means I need to add files to project or libraries to link to
but I did not find the proper solution.

Manao

24th October 2005, 11:15

The function is defined in :common/quant.c
common/quant.h

squid_80

24th October 2005, 11:23

From memory, to get it work with visual studio do the following:
1. Add set.c and quant.c (found in the common directory) to the libx264 project, ideally under the core folder.
2. Add a line near the bottom of x264.h like so:#ifdef __X264__
# ifdef _MSC_VER
# define inline __inline
# define DECLARE_ALIGNED( type, var, n ) __declspec(align(n)) type var
// Add this next line:
# define strncasecmp(s1, s2, n) strnicmp(s1, s2, n)
# else
# define DECLARE_ALIGNED( type, var, n ) type var __attribute__((aligned(n)))
# endif
#endif
See how you go with those tips, there might be more that I can't remember.

sr78

24th October 2005, 14:01

Thanks , It compiles.

I had to remove the flag HAVE_MMXEXT though.
Is there a problem with the mmx implementation?
With the flag I get these errors:

Linking...
xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe'
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_8x8_core16_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_4x4_core16_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_4x4_dc_core32_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_2x2_dc_core32_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_8x8_core32_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_4x4_core32_mmx
bin/x264.exe : fatal error LNK1120: 6 unresolved externals
Error executing xilink6.exe.

I looked around in the code , and indeed I see no implementation of any of these functions.am I missing something here?

Manao

24th October 2005, 14:05

Tou need to add the file "common/i386/quant-a.asm" to the vcproj, and to configure it to be compiled with nasm ( as the other asm files are, copy'n'paste their configuration to quant-a.asm's one )

Manao

24th October 2005, 14:07

Tou need to add the file "common/i386/quant-a.asm" to the .dsp, and to configure it to be compiled with nasm ( as the other asm files are, copy'n'paste their configuration to quant-a.asm's one )

squid_80

24th October 2005, 14:22

I knew there was something I'd forgotten. You can also try defining HAVE_SSE2 if you want the SSE2 pixel routines to be used.

sr78

26th October 2005, 08:07

thank a lot :)

giandrea

28th October 2005, 00:10

Now that crosscompile is in, can someone make builds of X264 for Mac/PPC? :) :)

QuadraQ

29th October 2005, 22:51

I've been having some trouble getting MeGUI to work for me, and in the process discovered that the avs script I was using was missing the fps information. Now technically this shouldn't happen of course, but what was interesting was what x264.exe did when passed this avs script. It showed the resolution followed by 0.0 fps and then went into some kind of infiinite loop (with lot's of hard drive activity as well) taking up virtually all of the processor time.

So it's a tiny thing (especially at this point in the development) but I would think that an error of some kind would be preferable behaviour.

max-holz

30th October 2005, 15:57

I have a silly question, beg pardon. In the x264's build thread by Sharktooth I found patches as files with the extension .diff. After I have downloaded the source code from videolan.org, in which way must I use these files for merging patches with the original source?

Sharktooth

30th October 2005, 16:06

supposing you have put the .diff files in the same x264 sources directory:
cd x264_sources_directory
patch < filename.diff -p0
(or patch -i filename.diff -p0)

el divx

30th October 2005, 16:07

Or check leowai's post earlier in this thread:here (http://forum.doom9.org/showthread.php?p=721978#post721978)

EDIT:BTW, Sharktooth, Your "Build Changes" log file found on your x264 builds sticky stops at revision 336.

max-holz

30th October 2005, 16:12

Thanks, I have never compiled x264 source before and I don't know the exactly use of MinGW.

sr78

1st November 2005, 06:43

Does the x264 support the FMO feature?

foxyshadis

1st November 2005, 06:59

This just came up a few days ago.

http://forum.doom9.org/showthread.php?t=101908

Answer: No.

Sharktooth

1st November 2005, 14:43

EDIT:BTW, Sharktooth, Your "Build Changes" log file found on your x264 builds sticky stops at revision 336.
What's wrong with that? It means there are only SVN changes.

el divx

4th November 2005, 18:34

I'm not complaining, I just thought it had been corrupted or something.

Anyway, the newest version of your aq patch fails to apply on "encoder/encoder.c", line 409.

Code in patch:
}
h->param.analyse.i_chroma_qp_offset = x264_clip3(h->param.analyse.i_chroma_qp_offset, -12, 12);
h->param.analyse.i_mv_range = x264_clip3(h->param.analyse.i_mv_range, 32, 2048);
+ if( h->param.analyse.b_aq && h->param.analyse.f_aq_strength <= 0 )
+ h->param.analyse.b_aq = 0;
if( !h->param.b_cabac )
h->param.analyse.i_trellis = 0;

Code in encoder.c, x264 rev.362:
}
h->param.analyse.i_chroma_qp_offset = x264_clip3(h->param.analyse.i_chroma_qp_offset, -12, 12);
if( !h->param.b_cabac )
h->param.analyse.i_trellis = 0;

{
const x264_level_t *l = x264_levels;
while( l->level_idc != 0 && l->level_idc != h->param.i_level_idc )
l++;
if( l->level_idc == 0 )
{
x264_log( h, X264_LOG_ERROR, "invalid level_idc: %d\n", h->param.i_level_idc );
return -1;
}
if( h->param.analyse.i_mv_range <= 0 )
h->param.analyse.i_mv_range = l->mv_range;
else
h->param.analyse.i_mv_range = x264_clip3(h->param.analyse.i_mv_range, 32, 2048);
}

Sharktooth

4th November 2005, 18:38

Some patches are somwhat b0rked. i mean they have to be manually adjusted (usually only few lines shifted) to be applied coz i made them "compatible" with the other patches.
however try the new one (v5)

el divx

4th November 2005, 19:58

Yup, it works geat.

The RDO for b-frames patch though doesn't:
$ patch -p0 < x264_brdo.3.diff
patching file `encoder/analyse.c'
Hunk #1 succeeded at 77 (offset 1 line).
Hunk #3 succeeded at 269 (offset 1 line).
Hunk #5 succeeded at 492 (offset 1 line).
Hunk #7 succeeded at 638 (offset 1 line).
Hunk #9 succeeded at 1292 (offset 1 line).
Hunk #11 succeeded at 1554 (offset 1 line).
Hunk #13 succeeded at 1631 (offset 1 line).
Hunk #15 succeeded at 2111 (offset 155 lines).
Hunk #17 succeeded at 2153 (offset 155 lines).
Hunk #19 succeeded at 2189 (offset 155 lines).
Hunk #21 succeeded at 2208 (offset 155 lines).
Hunk #23 succeeded at 2410 (offset 155 lines).
patching file `x264.c'
Hunk #1 FAILED at 253.
Hunk #2 FAILED at 477.
Hunk #3 succeeded at 521 (offset 10 lines).
Hunk #4 succeeded at 735 (offset 2 lines).
2 out of 4 hunks FAILED -- saving rejects to x264.c.rej
patching file `x264.h'

It must be something similar to this (http://forum.doom9.org/showthread.php?p=727178#post727178).

Sharktooth

4th November 2005, 20:29

yeah... coz it adds options to the CLI interface... see the rejected hunks and apply them manually (the file is x264.c)
they should be:
+#define OPT_B_RDO 316
(316 is already used by another option: AQ, replace it with another number - 318 - and add the line manually)

and

+ { "b-rdo", no_argument, NULL, OPT_B_RDO },
(add it as it is under "subme")

P.S.: remove the "+" sign....

el divx

5th November 2005, 07:40

Did it and worked.

BTW, shouldn't some of the features start making it to the VFW interface? Maybe it's just me, but I think they are starting to pile up(which is good for x264 feature-wise).

Sagittaire

5th November 2005, 10:45

For the first time x264 is little better than NDAVC for OPSNR test (RDO + B-RDO + trellis powerfull) and I use NDAVC HP in full quality mode ... very good job

however NDAVC is always better for SSIM (and IMO for my eyes too) ... perhabs the time for HVS optimisations

IgorC

5th November 2005, 12:06

In fact if OPSNR is higher then x264 is better. It´s simple. Actually higher OPSNR , higher quality ;)

Sagittaire

5th November 2005, 13:03

In fact if OPSNR is higher then x264 is better. It´s simple. Actually higher OPSNR , higher quality ;)

in fact +/- 0.05 db for x264 vs NDAVC -> no possible conclusion with OPSNR.

but NDAVC is always the best for SSIM. Psy mode for NDAVC seem very powerfull ... :)

however x264 HP is very better than NDAVC MP or VP7 for metric (OPSNR and SSIM) and at this time x264 HP is the best codec available for metric

squid_80

6th November 2005, 02:10

r355 seems to have broken encoder/cabac.c for Visual Studio:
Compiling...
cl : Command line warning D9002 : ignoring unknown option '/G6'
cabac.c
\x264\encoder\cabac.c(198) : error C2059: syntax error : '}'
---------------------- Done ----------------------

Build: 0 succeeded, 1 failed, 0 skippedIt's talking about this: 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 compiler doesn't seem to like the empty braces. Any ideas?

Richard Berg

6th November 2005, 02:57

@Sharktooth: I can't get the AVI input in your builds to work. Tried several files with different codecs, always get this error:

avis [error]: unsupported input format (hfyu)
could not open input file 'C:\Vid\Storage\keep\colorbars-huff.avi'

(with different FOURCC & filenames, of course)

Avisynth input works fine.

Richard Berg

6th November 2005, 04:04

I looked at the source code. Apparently only FOURCC == YV12 is supported. That may actually be ok...what I eventually want is to write out the raw frames during the 1st pass so that we don't have to execute the AVS script again on the 2nd/3rd passes. I've made some changes to MeGUI to assist with this, but it looks like it might be easier if I modify x264 too.

akupenguin

6th November 2005, 04:34

The compiler doesn't seem to like the empty braces. Any ideas?
Put something in them. It doesn't matter what.

squid_80

6th November 2005, 04:36

Zeroes it is then. :cool:

sr78

6th November 2005, 11:28

does x264 uses only one slice for each encoded frame?

I looked at the code and I couldn't find the place in which a frame
is devided into more then one slice.

Also , it seems like a SPS is written for each new IDR slice/frame ,is that the case?
shouldn't there be one sequence parameter set for the entire stream?

I am sorry if all these questions are two much , I am trying to get into the details of
the code and will appreciate your patience.

p.s - is there a tool where I can analyze the encoded stream? that is , see the SPS , PPS , number of NAL unit etc.. ?

thanks

akupenguin

6th November 2005, 11:56

does x264 uses only one slice for each encoded frame?
I looked at the code and I couldn't find the place in which a frame
is devided into more then one slice.
encoder/encoder.c: x264_slices_write()

Also , it seems like a SPS is written for each new IDR slice/frame ,is that the case?
shouldn't there be one sequence parameter set for the entire stream?
x264 outputs a SPS for each IDR. If muxing to a format that only wants one for the stream (MP4 or Matroska), then the muxer throws away the duplicates.

p.s - is there a tool where I can analyze the encoded stream? that is , see the SPS , PPS , number of NAL unit etc..?
For bitstream-level analysis, I use JM (http://iphome.hhi.de/suehring/tml/) in trace mode (http://students.washington.edu/lorenm/src/x264/jm.trace.diff).

bond

6th November 2005, 12:55

sr78

6th November 2005, 15:54

[QUOTE=akupenguin]encoder/encoder.c: x264_slices_write()

I looked into x264_slice_write() and I did not see any loop going
over more then one slice. The only loop I see in the code
is going over MB's.

Also , when I look at the stream with an hex editor I see 1 slice per frame.
(I know hex editor is not the easiest way to do it , I just wanted to go deep into the stream).

Sharktooth

6th November 2005, 16:07

Kopernikus

6th November 2005, 16:09

in slice_write() one slice is processed by one Thread.
slices_write() partitions the frame in slices and starts slice_write().

sr78

6th November 2005, 16:35

I can't find slices_write only slice write , was this added lately?
I will try updating my version from the svn

sr78

6th November 2005, 16:49

Sorry , I was using a VERY old version
My mistake.

thank you both for your help

Richard Berg

6th November 2005, 18:18

Yes, I have a Huff VFW codec installed, but it decodes to YUY2 of course. Maybe I can get it to work by using ffvfw and changing the output settings...

bond

6th November 2005, 18:46

Yes, I have a Huff VFW codec installed, but it decodes to YUY2 of course. Maybe I can get it to work by using ffvfw and changing the output settings...i think it should work with any vfw codec tough?

stephanV

6th November 2005, 18:59

bond

6th November 2005, 21:24

I'm pretty sure you can only feed x264 with uncompressed YV12 AVIs, for the reason that not any other AVI seems to work.

[edit]Looking through the source code it is quite obvious that anything else but YV12 won't work.good to know :)

redfordxx

6th November 2005, 23:07

I just tried to encode const quant=1
What's this problem?

Next job job15 is a video job. encoder commandline:
"x264.exe" --qp 1 --ref 4 --bframes 2 --nf --no-cabac --weightb --analyse all --8x8dct --me umh --cqmfile "C:\Program Files\x264\eqm_avc_hr.cfg" --progress --no-psnr --output "D:\_download\WMV\T2_1080-lossless.mkv" "D:\_download\WMV\T2_1080-exc.avs"
successfully set up video encoder and callbacks for job job15
----------------------------------------------------------------------------------------------------------

Log for job job15

avis [info]: 1280x544 @ 23.98 fps (212 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [error]: OVERFLOW levelcode=4251
x264 [error]: OVERFLOW levelcode=4265
x264 [error]: OVERFLOW levelcode=4365
x264 [error]: OVERFLOW levelcode=4283
x264 [error]: OVERFLOW levelcode=4363
x264 [error]: OVERFLOW levelcode=4495
x264 [error]: OVERFLOW levelcode=4447
x264 [error]: OVERFLOW levelcode=4165
x264 [error]: OVERFLOW levelcode=4299
x264 [error]: OVERFLOW levelcode=4281
x264 [error]: OVERFLOW levelcode=4201
x264 [error]: OVERFLOW levelcode=4219
x264 [error]: OVERFLOW levelcode=4553
x264 [error]: OVERFLOW levelcode=4487
x264 [error]: OVERFLOW levelcode=4327
x264 [error]: OVERFLOW levelcode=4459
x264 [error]: OVERFLOW levelcode=4343
x264 [error]: OVERFLOW levelcode=4575
x264 [error]: OVERFLOW levelcode=4331
x264 [error]: OVERFLOW levelcode=4327
x264 [error]: OVERFLOW levelcode=4143
x264 [error]: OVERFLOW levelcode=4151
x264 [error]: OVERFLOW levelcode=4201
x264 [error]: OVERFLOW levelcode=4245
x264 [error]: OVERFLOW levelcode=4263
x264 [error]: OVERFLOW levelcode=4251
x264 [error]: OVERFLOW levelcode=4111
x264 [error]: OVERFLOW levelcode=4141
x264 [error]: OVERFLOW levelcode=4151
x264 [error]: OVERFLOW levelcode=4245
x264 [error]: OVERFLOW levelcode=4359
x264 [error]: OVERFLOW levelcode=4239
x264 [error]: OVERFLOW levelcode=4277
x264 [error]: OVERFLOW levelcode=4339
x264 [error]: OVERFLOW levelcode=4309
x264 [error]: OVERFLOW levelcode=4241
x264 [error]: OVERFLOW levelcode=4449
x264 [error]: OVERFLOW levelcode=4401
x264 [error]: OVERFLOW levelcode=4113
x264 [error]: OVERFLOW levelcode=4211
x264 [error]: OVERFLOW levelcode=4307
x264 [error]: OVERFLOW levelcode=4149
x264 [error]: OVERFLOW levelcode=4297
x264 [error]: OVERFLOW levelcode=4235
x264 [info]: slice I:21 Avg QP: 0.00 size:341750
x264 [info]: slice P:172 Avg QP: 1.00 size:311998
x264 [info]: slice B:19 Avg QP: 3.00 size:233094
x264 [info]: mb I I16..4: 6.9% 14.1% 79.0%
x264 [info]: mb P I16..4: 4.8% 11.5% 41.0% P16..4: 5.6% 7.3% 16.2% 7.5% 5.3% skip: 0.7%
x264 [info]: mb B I16..4: 2.5% 7.8% 18.5% B16..8: 19.6% 14.9% 34.3% direct: 0.9% skip: 1.4%
x264 [info]: 8x8 transform intra:19.4% inter:6.5%
x264 [info]: ref P 86.4% 7.6% 3.6% 2.4%
x264 [info]: ref B 95.4% 3.1% 1.0% 0.6%
x264 [info]: kb/s:59052.7

Actual bitrate after encoding without container overhead: 59055.69

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

akupenguin

7th November 2005, 00:05

Short reason: qp=1 + cavlc + cqm.
Short fix: don't ever use qp=1. it's way beyond perceptually transparent, but it's not really lossless, and often higher bitrate than qp=0.

Long reason:
When entropy_coding_mode_flag is equal to CAVLC and QPy is less than 10 and profile_idc is equal to 66, 77, or 88, the range of values that can be represented for the elements of cij of c is not sufficient to represent the full range of values of teh elemts dcYij of dcY that could be necessary to form a close approximation of the content of any possible source picture by the use of the Intra_16x16 macroblock type.
However, the overflow seems to occur in x264 only when CQM is used (high profile), and the standard says it should be an issue only when not using high profile, so I don't actually know what's wrong.

squid_80

7th November 2005, 00:17

ChronoCross

7th November 2005, 02:23

364A Crashes x264 with the HQ-Insane Profile. I've narrowed it down to the RDO Level 2. Changing it to 6 instead of 7 takes away the crash.

Quarkboy

10th November 2005, 06:43

I have a question about max refs...

I use x264 for anime encoding, and I've found significant size differences at constant quant=25 tests (with subme 7, rdo for b-frames, umh, 3 b-frames... etc...)...
about 3.6% decrease with refs=8 versus refs=4, and about 4.6% with refs 16 versus refs 4.

I haven't noticed any significant playback speed decreses with refs=16 either.

However, I'm wondering how the references are actually stored in the file? am I wasting 3 bits almost every frame by using refs=16?

Manao

10th November 2005, 06:58

The reference can change for every 8x8 block. However, you don't need 4 bits for each macroblock ( all references aren't equally used, so, for example, the most used, the first one, will be written with 2 bits ( i don't know exactly how many in fact ) ). Furthermore, cabac complicates the matter and reduces greatly the bits wasted on the reference. Finally, references can also be predicted ( a 8x8 block whose neighbours all use the nth reference will be likely to use that one too )

Quarkboy

10th November 2005, 07:13

akupenguin

10th November 2005, 07:34

In CAVLC, selecting the 1st ref always takes 1 bit per partition, regardless of the number of refs to choose from (except of course when there's no choice). Selecting the 2nd ref takes 1 bit if #refs=2, or 3 bits if #refs>2. The costs of the rest are independent of the number of choices. While it may be possible for x264 to make suboptimal decisions, there are no ref-related penalties inherent to the standard beyond #refs=3.
In CABAC, things are simpler (from the user's POV): costs adapt to the real usage frequencies, so there are no penalties for allowing refs that aren't needed. (They can take less than 1 bit each if predicted well)

CABAC compresses everything (except the <5byte frame header).

hpn

10th November 2005, 22:29

I guess before every first pass x264 should check if there is a "x264_2pass.log" from a previously successful encode (usually from the same source but with different options) in the same folder and delete it.

p.s. The previous log file is now deleted (overwritten) by x264_2pass.log.temp only when the first pass is successfully complete, but it could cause a problem on some rare occasions. For example I make multiple 2pass tests via .bat files and sometimes I manage to crash the encoder during the first pass after a few frames (in some extreme -t 2 -rdo --b-rdo tests with HD content), so the first pass is not finished, but the second one starts automatically and usually completes successfully because a former valid log (but made with different options) is present, so this way I get an encode without the desired parameters and what is worse, I may overlook the error in the command prompt and think everything encoded fine. To work around this I always delete the previous log manually, before starting a 2(3)pass .bat, so in case the first pass crashes I just get an error and the encoding stops:
x264 [error]: ratecontrol_init: can't open stats file
x264_encoder_open failed

_xxl

11th November 2005, 14:30

http://www.elecard.ru/movies/Olesya..._SIF_90kbps.mp4
ffdshow avc h.264 mobile
Microsoft Visual C++ Runtime Library
Assertion Failed!
Program...Media Player Classic 6.4.8.6 and Media Player 2
File libavcodec/h264.c
line 7755
EXPRESSION Pict--Data[0]
Amd XP 1600+ winXP Sp2
Tested with:
Milan's compiled fdshow-20051109.exe ICL8 and bob0r's fdshow-20051109.exe sse GCC.

Sharktooth

11th November 2005, 14:33

@drevil_xxl: it's a ffdshow problem, not a x264 problem. your post is on the wrong thread.

sr78

15th November 2005, 15:18

bond

15th November 2005, 15:21

h264 general question (Sorry I did not find it in the ITU-T )
I know that 0x000001 is the start code for a new NAL unit.
but , since few NAL units can build uo to one frame , how does the decoder
decide that a new frame is reached (i.e - this NAL unit is from a new frame)?

thanksfor this either you use access unit delimeters or there is a flag telling whether a NAL is a new picture or part of the last one

sunilraman

17th November 2005, 01:51

hi sharktooth thanks for the win32 builds. one question, if it has not been answered already, what is your view on SSE3 optimisation in addition to 3dnow, SSE, SSE2 ?

Sharktooth

17th November 2005, 11:31

I dont think SSE3 will bring more benefits, however you may ask akupenguin (pengvado on IRC) or Alex_W coz they already had a SSE3 pixel routine code patch.

giandrea

18th November 2005, 16:16

Hello, what's this "RD mode decision for B-frames" added in the368 commit?
Any comment, test?

Sharktooth

18th November 2005, 18:41

Rate/Distortion optimization on b-frames too (when RDO is enabled -> --subme 6 or 7).
It's like b-vhq in xvid 1.1...

redfordxx

19th November 2005, 17:09

Why I have this message?
I have unrestricted level, MeGUI settings based on Sharktooth's HQ profiles...
Should I care for it?

gino25

20th November 2005, 12:06

what is GPAC? I can read this in changelog of x264.

20th November 2005, 13:13

http://gpac.sourceforge.net/

bond

20th November 2005, 13:38

Why I have this message?
I have unrestricted level, MeGUI settings based on Sharktooth's HQ profiles...
Should I care for it?there is no such thing as "unrestriced level" in avc, meaning you always have to set a level

propably megui tells you that your encode breaks the highest level possible in the mentioned way?

Doom9

20th November 2005, 13:42

propably megui tells you that your encode breaks the highest level possible in the mentioned way?It's not MeGUI, that message comes directly from the encoder. It's curious that you're getting this message though. Are you sure nothing is set in the VBV fields (x264 configuration, 2nd tab)?

redfordxx

20th November 2005, 15:41

Are you sure nothing is set in the VBV fields (x264 configuration, 2nd tab)?I am making some short test encodes"x264.exe" --qp 20 --keyint 240 --ref 16 --mixed-refs --bframes 3 --b-pyramid --nf --subme 7 --b-rdo --weightb --trellis 2 --analyse all --8x8dct --me umh --progress --no-psnr --output "blox-smooth-umh-ref16-range16.mkv" "blox-smooth.avs"
avis [info]: 1280x544 @ 24.00 fps (2071 frames)
x264 [warning]: DPB size (16711680) > level limit (12582912)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [info]: slice I:48 Avg QP:17.00 size: 5682100:00
x264 [info]: slice P:1534 Avg QP:20.00 size: 26136
x264 [info]: slice B:489 Avg QP:21.86 size: 14839
x264 [info]: mb I I16..4: 16.2% 67.2% 16.6%
x264 [info]: mb P I16..4: 17.5% 32.9% 3.6% P16..4: 27.9% 8.4% 2.8% 0.1% 0.0% skip: 6.8%
x264 [info]: mb B I16..4: 4.2% 6.7% 2.1% B16..8: 57.3% 1.7% 2.1% direct: 3.0% skip:22.9%
x264 [info]: 8x8 transform intra:60.6% inter:89.0%
x264 [info]: ref P 70.8% 10.0% 5.0% 3.1% 1.9% 1.7% 1.2% 1.5% 0.8% 0.9% 0.6% 0.7% 0.5% 0.5% 0.4% 0.4%
x264 [info]: ref B 75.0% 9.7% 4.2% 2.2% 1.9% 1.3% 1.3% 0.7% 0.8% 0.6% 0.8% 0.4% 0.3% 0.3% 0.4%
x264 [info]: kb/s:4641.5

encoded 2071 frames, 0.26 fps, 4641.64 kb/sAnother surprise. this video has 23.995fps. When I encode it to mp4, it is or "looks like" 25fps...??? After transmux to mkv, 23.995 again... Maybe FFDShow is confused?

falcon2000eg

21st November 2005, 00:28

any update for vfw?

bond

21st November 2005, 00:33

any update for vfw?whats that? :p

falcon2000eg

21st November 2005, 01:06

i think adding subme 7 ,b-rdo and Trellis in vfw will be great .
I know h.264 in avi is :devil:

Kostarum Rex Persia

21st November 2005, 01:26

I agree.Updated vfw is very good idea.

CiNcH

21st November 2005, 01:47

Not to forget Adaptive Quantization and Custom Quantization Matrices.

Or probably just a ToDo list for the VfW interface, so that it is more obvious which features are missing, maybe I find some time to include them...

bond

21st November 2005, 01:50

another option missing is the automatic formating of the users harddisc when he tries to use the vfw version of x264

i think megui is easy enough to use, to not have to go with vfw

Tommy Carrot

21st November 2005, 02:10

But megui needs .NET framework, and i certainly can understand if someone is reluctant to install that (because i am too :D), and also AFAIK it cannot output avi (you know, still the best choice for editability :)). VFW has some advantages just as some disadvantages, so if some people want to use it, let them, it's always good to have some alternatives.

falcon2000eg

21st November 2005, 02:34

Tommy Carrot
:thanks: :goodpost:

celtic_druid

21st November 2005, 04:00

Could also just remove VfW from the svn, that way no one would complain that it was out of date and everyone would be forced to use the cli.

Maybe its time to updated the x264 cli gui that was based on the VfW source? No .NET, same user interface, no VfW and no avi.

Kostarum Rex Persia

21st November 2005, 12:18

redfordxx

21st November 2005, 12:48

No,no,no. :mad: That's not very good idea.I know 50 people who use x264,and no one uses CLI.Everybody like vfw.I started recenly with x264.
Soon I prefered MeGUI --- more options, although I didn't understood them all.
I think the interface is growing fast together with codec, so it is not absolutely well arranged. But IMHO it should be solved only after the list of features will be finished. The work on the encoder itself is more important and thanks for it.
Very important for me is the show commandline option... that way I learned the CLI.
Now I prefer CLI, it's much faster when modifying and copying jobs (saved in .BAT files) When there is an error I can restart the batch instantly (for MeGUI I have to go to the jobs directory and change the status/error flag, then restart MeGUI). You can also insert DOS commands into batch file for example x264 pass 1 ...
copy stats ...
x264 pass 3 ...
pause

You and your 50 friends should try it.
I use GUI only for experimenting.

Doom9

21st November 2005, 12:55

But megui needs .NET framework, and i certainly can understand if someone is reluctant to install thatNo, irrational fear is no excuse. I used to be like that 2.5 years ago before my first .NET installation, but I have not found a single reason not to install it since (that is if you need it of course, if you have no software there's no need for it, but insisting on non .NET software isn't healthy.. it's a well known fact that unmanaged languages, with all their advantages, are more error and security leak prone).

I've asked for AVI output in x264.exe.. current coders have no interest in that but volunteers are always welcome. And MeGUI supportx x264 in AVI, you just need to use mencoder (which has a limited x264 featureset I'm afraid).

I know 50 people who use x264,and no one uses CLI.Are those the same people that fill the container forum with issues they wouldn't have if they used a more appropriate container? I have no beef with AVI, none at all, but you should pick a container in relation of what you're going to do later on. AVC's featureset makes AVC in AVI a much less useful idea than ASP (where we have all the workarounds in place, without them it wouldn't be so convenient either unless you restrict yourself to simple profile)

@redfoxx: if you have any interface improvement ideas, please share them (in the appropriate thread though). I've asked in the past for ideas but nobody replied so far.. I'm aware that with all the new features, a rearrangement would make a lot of sense.

Manao

21st November 2005, 13:00

you just need to use mencoder (which has a limited x264 featureset I'm afraid).IIRC, Loren quickly updates mencoder when features are added to x264

Doom9

21st November 2005, 13:27

IIRC, Loren quickly updates mencoder when features are added to x264Not all the time.. just take a look at the mencoder manpage and compare it with x264.exe...

redfordxx

21st November 2005, 13:39

if you have any interface improvement ideas, please share them (in the appropriate thread though). I've asked in the past for ideas but nobody replied so far.. I'm aware that with all the new features, a rearrangement would make a lot of sense.Well I thought I better not bother developers with my personal "complains". But when there is at least some interrest, provided I will have some constructive output, I will share it (in MeGUI thread).
Only in general idea:
Except arranging and grouping controls according to logical relationships, maybe it is good also somehow to distinguish features which are pass specific and which are pass independent. In other words, after I am not satisfied with second pass, which features can I change without redoing 1st pass (and save many hours), and which feature change require new 1st pass. (of course, this is a newbie feature. These, who perfectly understand the encoder, can decide it themselves)

Sharktooth

21st November 2005, 16:03

Some time ago i was going to update the VFW interface with some of the new options.
However some of them (like zones) are a pain in the a$$ to add. Also i moved away completely from VFW since i stared including MeGUI in my builds, and have no longer interests in keeping VFW up to date.

Kostarum Rex Persia

21st November 2005, 16:52

Sagittaire

21st November 2005, 17:04

Sharktooth,can you,please,find some motivation to implement new options in vfw codec, subme 7 ,b-rdo and Trellis,Adaptive Quantization and Custom Quantization Matrices.

Most of the world codecs use vfw interface,so I think if you stop to develop x264 vfw,that can really harm x264 popularity.Very few people like to work in MeGUI or CLI encoders.

and RV10 example with producer.exe ... lol

IMO x264 with CLI is the best way for multiple Gui developpement ... and by far

H264 in avi or mkv is a very bad way ... mp4 will be compatible with SAP.

Kostarum Rex Persia

21st November 2005, 17:11

Well,it works for me.I use AVI container for x264,and I am very pleased.

Sirber

21st November 2005, 17:15

and RV10 example with producer.exe ... lol

IMO x264 with CLI is the best way for multiple Gui developpement ... and by far

H264 in avi or mkv is a very bad way ... mp4 will be compatible with SAP. :stupid:

Well,it works for me.I use AVI container for x264,and I am very pleased.
AVI is outdated as well as VFW. It's time for you to upgrade :p

dimzon

21st November 2005, 17:21

:stupid: AVI is outdated as well as VFW. It's time for you to upgrade :p
I have an idea to develop VfW encoding API successor.

easy to implement
Codec developers does not spent they time for interface and other stuff

easy to deploy
Must support XCopy deployment model and side by side execution (DirectShow is not applicable here)

easy to use
Must provide simple API able to use from VB6/Delphi/.NET/C++ etc.

Tommy Carrot

21st November 2005, 17:27

H264 in avi or mkv is a very bad way ... mp4 will be compatible with SAP.I never understood people's obsession with mp4 container. Is there any evidence that it will be widely supported by the industry? Next-gen DVD will most probably use a VOB like container, HDTV will use TS for streaming, Apple is already using AVC in MOV, and H.264 reference encoder doesn't even support mp4 output. Where is the wide support for mp4? Not to mention if you want to edit your mp4 (and mkv) videos, your hands are tied, there is no simple straightforward way to do that.

Kostarum Rex Persia

21st November 2005, 18:05

I never understood people's obsession with mp4 container. Is there any evidence that it will be widely supported by the industry? Next-gen DVD will most probably use a VOB like container, HDTV will use TS for streaming, Apple is already using AVC in MOV, and H.264 reference encoder doesn't even support mp4 output. Where is the wide support for mp4? Not to mention if you want to edit your mp4 (and mkv) videos, your hands are tied, there is no simple straightforward way to do that.

I agree with you.There is no wide support for .mp4 container in this moment.And I also think that future HD-DVD and BlueRay films most probably use VOB like container.

@ Dimzon,can you,please,explain in detail your idea to develop vfw encoding via API successor? I don't understand what is your idea.

@ Sirber,why do you think that AVI container is outdated,explain that,please.

Sharktooth

21st November 2005, 18:09

AVI and VFW do not support natively many of the AVC and even ASP features.
They're hacked in and may create problems (look at the packed bitstream option in xvid) in both SAPs and PCs.
AVI is just too old... and VFW too.

Kostarum Rex Persia

21st November 2005, 18:26

Ok,AVI is too old,but you can't say that for VFW.You didn't answer me to my question earlier(on previous page)?

Tommy Carrot

21st November 2005, 18:26

AVI and VFW does not support natively many of the AVC and even ASP features.
They're hacked in and may create problems (look at the packed bitstream option in xvid) in both SAPs and PCs.
AVI is just too old... and VFW too.The only feature they don't support is the out-of-order frames, in other word they intruduce a small delay when b-frames are used, which remains unnoticable thanks to the workarounds. I could live with this "problem" with xvid, so why should it bother me now?

Revgen

21st November 2005, 18:39

I can understand why some people want to use vfw instead of CLI. It's easier to cut and edit a video and then encode it in Virtual Dub with a dual preview screens than it is to learn how to create an AVS script to do the same thing.

Even for those who do know how to script, writing scripts like:

Trim(0,2873)+Trim(7080,0)
Trim(0,21139)+Trim(24750,0)
Trim(0,32606)+Trim(37572,0)
Trim(0,49059)+Trim(53121,0)
Trim(0,59227)+Trim(63290,0)
Trim(0,79451)+Trim(83511,0)
Trim(0,87248)+Trim(90854,0)
Trim(0,94067)+Trim(99027,0)
Trim(0,102490)+Trim(106684,0)
Trim(0,114666)+Trim(118725,0)
Trim(0,122616)+Trim(126224,0)
Trim(0,130978)+Trim(135938,0)
Trim(0,150506)+Trim(154719,0)
Trim(0,157104)+Trim(160711,0)
Trim(0,171381)+Trim(175511,0)
Trim(0,180388)+Trim(184449,0)
Trim(0,187978)+Trim(191584,0)
Trim(0,198401)+Trim(202460,0)
Trim(0,214030)+Trim(217938,0)
Trim(0,229599)

Just to cut out unwanted footage can be a hassle.

I think that more n00bs and newbies would appreciate x264 CLI if it could be integrated into more of a Virtual Dub app. MeGUI doesn't quite fit that criteria yet.

Kostarum Rex Persia

22nd November 2005, 00:30

Well,ok,but very few people know how to make AVS scripts.Most of them don't won't to bother with AVS scripts,because they want easy to use codec interface.That kind of interface is VFW,believe or not.

BTW,Sharktooth,do you have any plans to allow MPEG1/2 and AVI input in MeGUI,instead only AVS input?

falcon2000eg

22nd November 2005, 00:43

I can understand why some people want to use vfw instead of CLI. It's easier to cut and edit a video and then encode it in Virtual Dub with a dual preview screens than it is to learn how to create an AVS script to do the same thing.

I think that more n00bs and newbies would appreciate x264 CLI if it could be integrated into more of a Virtual Dub app. MeGUI doesn't quite fit that criteria yet.
Thats why I ask for vfw in first place because I need to use Virtualdub some times.

Personaly I'm using MeGUI-CLI for 90% of my encodes, it is a great tool but i can not replace Vdub and yes avisynth is not easy for newbies.

bond

22nd November 2005, 00:44

ah now avisynth is evil and a reason for using vfw? :D

megui includes a very easy to use interface for creating .avs scripts

you guys should simply make the step and learn something new and better, megui makes it soooo easy. you are acting like 80 year old pensionists for which only the old, known things are good unwilling to try something new

falcon2000eg

22nd November 2005, 00:58

OK bond I quit :( I will not ask for Vfw again :confused:

Tommy Carrot

22nd November 2005, 01:03

you guys should simply make the step and learn something new and betterThis is exactly my point: it's not always better. If you want to do additional editing on your encoding, it's almost impossible with the cli method, you'll need muxing your video many times, while with vfw interface, it's very simple. I know you are feeling frustrated that avi and vfw are still here and just cannot die, but you must understand that cli and GUIs just cannot replace them for certain tasks.

bond

22nd November 2005, 01:08

well if you really really really need to use virtualdub you can still remux from mp4/mkv to avi with avc2avi
but of course editing with b-frames is a pita with avi/vfw

Sagittaire

22nd November 2005, 01:30

problem with x264 build 368

with this command line
x264.exe --bframe 2 --b-rdo --ref 16 --mixed-refs --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 6 --trellis 2 --progress -o NUL Encodage.avs

source is avs 1280*720*25 and first pass stop always at frame 146(/2591) ... ???

I have warning "DPB size (22118400) > level limit (12582612)"

no problem with exactly the same source but with 720*400*25 resize. No warning with this resolution : seem to be level problem ... ???

Revgen

22nd November 2005, 02:23

OK bond I quit :( I will not ask for Vfw again :confused:

What you really should be asking is for Virtual Dub to support X264 CLI or MeGUI to add more Virtual Dub-like features. Once that happens the whole VFW debate will be over.

As bond has said many times before, the .avi interface doesn't allow the H.264 codec to reach it's potential without a lot of hacks and code twisting. And sometimes that doesn't even work.

Using VFW and .AVi with X264 is kind of akin to drinking Don Perigon wine out of a paper cup instead of a contoured wine glass to accentuate it's aroma. MKV and MP4 are the wine glass containers that benefit the H.264 codecs.

BTW I'm not a wine freak. My Mother rented Sideways last night and we all had to watch. :rolleyes:

falcon2000eg

22nd November 2005, 02:40

:goodpost:
What you really should be asking is for Virtual Dub to support X264 CLI or MeGUI to add more Virtual Dub-like features. Once that happens the whole VFW debate will be over.

But ATM I think updating x.264 VFW will be easier and faster.
I realy like MKV it is a nice glass for the wine :D

nDman

24th November 2005, 02:29

I come here to say about a problem in x264 VFW encoder.
i use combustion for VFX and like save output as x264 avi but combustion can't render with this codec.

and if VP6 be installed, combustion will open encoder setup dialog of VP instead x264.

and i use Magix Video pro for video editing, when i encode the movie with x264 the magix will does crash.

can you fix it?

sorry for my bad english.

Revgen

24th November 2005, 02:59

Okay lets get this straight.

1) You're trying to export a video editing project created using Magix Video Pro to x264vfw?

2) When you use a video effect called "combustion" in your project and attempt to convert to x264, Magix Video Pro crashes?

3) When you have the VP6 codec installed on your system, whenever you try to enter the X264vfw setup menu, you enter the VP6 codec menu instead?

If the above information is correct, then I'm going to guess that the problem lies with Magix Video Pro or your OS.

What could be happening is that the settings that you're inputing for x264 are being sent to the VP6 codec or another codec other than x264. This codec may not understand the settings and abort causing Magix Video Pro to crash.

This is only theoretical though.

charleski

24th November 2005, 05:00

Ok,AVI is too old,but you can't say that for VFW.Um, VfW is ANCIENT. It goes back to the old 16-bit days (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_video_for_windows.asp). It's long since been time to move on.

But what I'm seeing here really is that people want to retain the filtering and editing functions of VirtualDub while encoding using x264. Have you ever considered using VDub's built-in frameserver to do that? This would be a far better method than trying to cram h.264 video into an AVI.

Revgen

24th November 2005, 08:20

Um, VfW is ANCIENT. It goes back to the old 16-bit days (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_video_for_windows.asp). It's long since been time to move on.

But what I'm seeing here really is that people want to retain the filtering and editing functions of VirtualDub while encoding using x264. Have you ever considered using VDub's built-in frameserver to do that? This would be a far better method than trying to cram h.264 video into an AVI.

I don't believe that X264CLI can process .vdr files.

Only .avs can be used.

squid_80

24th November 2005, 08:37

It's easy enough to modify x264.c so the CLI accepts .vdr files just like .avi and .avs but virtualdub only seems to frameserve in RGB24 format.

redfordxx

24th November 2005, 09:32

puffpio

24th November 2005, 10:09

pausing encodes to restart later would be nice...maybe even recover from a power out? that would be sweet

CREXbzh

24th November 2005, 10:13

Not all the time.. just take a look at the mencoder manpage and compare it with x264.exe...
That is just because the website of mplayerhq.hu (which puts all the docs online) has not been updated in a while (due to several issues not worth talking about here).

The 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.

foxyshadis

24th November 2005, 10:18

Are you suggesting something like writing each IDR-gop as a discrete block, journaling changes in a temp file until ready to attach another full IDR?

...why don't you just use ELDER? Tobias went through all the trouble to make it do just that. It's not just for SMP encoding. (In fact it might even support single-frame recovery, it's simple enough to write out encoder state every frame, the problem is whether it can be acceptibly performant with all that data.)

Doom9

24th November 2005, 10:23

Most of them don't won't to bother with AVS scripts,because they want easy to use codec interface.That kind of interface is VFW,believe or not.And how do you get your video into VirtualDub? Via AviSynth script most likely (at least that's the most efficient way.. I hear there are people still using VFAPI and filters in VDub.. well, if you like to wait twice as long then be my guest).

redfordxx

24th November 2005, 10:25

...why don't you just use ELDER?I learned about ELDER some time ago, but just VERY briefly. So, maybe I am wrong, but I suppose parallel encoding cannot be as efficient as normal 2pass...
(meaning the rate control and best bits alloc)

stephanV

24th November 2005, 11:10

I learned about ELDER some time ago, but just VERY briefly. So, maybe I am wrong, but I suppose parallel encoding cannot be as efficient as normal 2pass...
(meaning the rate control and best bits alloc)
Why not?

redfordxx

24th November 2005, 11:23

Why not?This question-answer implies, that I do not understand the matter thoroughly enough and I am probably wrong;-)

I thought the encoder does not go throug whole movie (mean 1st pass) and then decide the bit allocation "based on the knowledge" of the whole movie.

Anyway the original Q remains: Suspend feature for x264 (e.g. Ctrl-S in CLI) makes sense?

stephanV

24th November 2005, 11:29

This question-answer implies, that I do not understand the matter thoroughly enough and I am probably wrong;-)

I thought the encoder does not go throug whole movie (mean 1st pass) and then decide the bit allocation "based on the knowledge" of the whole movie.
That's true in principle, but i believe ELDER at least does some modifications on the stat files to (partly) correct for this. Of course, whats more of an objection to this is that it probably isn't so that the current 2-pass mechanism is perfect.

Anyway the original Q remains: Suspend feature for x264 (e.g. Ctrl-S in CLI) makes sense?
It could. :)

Doom9

24th November 2005, 11:47

MeGUI allows you to suspend x264.exe and resume encoding whenever you feel like it.

maybe even recover from a power out? that would be sweetthere is seek and then there's elder. Of course it would also be nice if x264 would brew me ice tea (don't like coffee at all), cook for me, clean, wash clothes, iron, etc, but you gotta stop somewhere. Keeping consistent states across program termination is something that can only be achieved with a lot of effort and there's hardly any software to do this. Why should a video encoder, which is nothing business critical whatsoever, have features that only the most expensive apps in the world have?

Last but not least I think this thread should get back to being all but a free-for-all wishlist and container discussion.

redfordxx

24th November 2005, 12:03

MeGUI allows you to suspend x264.exe and resume encoding whenever you feel like it.Wow, haven't noticed. I thought it can pause, but can't quit, reboot etc. So I probably cancel using CLI and come back to MeGui (for wholemovieencodes at least).
[EDIT] incorrect english, :) now it makes more sense...

charleski

24th November 2005, 13:33

I don't believe that X264CLI can process .vdr files.

Only .avs can be used.
Well that's no barrier:
Q2.8: How do I load my clip into AviSynth (video) ?
...
* vdr-files (VirtualDub's frameserver files):

AviSource("d:\filename.vdr")
(From the docs at avisynth.org)
Have you tried it?

708145

24th November 2005, 16:18

Well, how about different feature: suspend to disk
for instance only at the I?? frame (can't remember the name, you know), I believe it will save lot of memory space to save.
H.264 encoding is quite slow and with forthcoming HD the hours turn into days quickly... and sometimes reboot or so is necessary

please note that the next beta of ELDER will have pause/resume functionality for x264 and xvid :)

and for the bit distribution: The parallel first pass I do results in a bit identical stats file as a normal 1st pass does. Plus I will alter the second pass rate distribution to your needs. But current implemetation is very close to what a 2pass xvid does.

bis besser,
T0B1A5

Revgen

24th November 2005, 17:07

Well that's no barrier:
(From the docs at avisynth.org)
Have you tried it?

Yep tried it, it doesn't work. Could be the RB24 issue that squid80 talked about earlier.

charleski

24th November 2005, 17:10

@Revgen: Put ConvertToYV12() at the end of the avisynth script

Revgen

24th November 2005, 17:14

I forgot to mention that I did that too. Avisynth still gives an error when I start it.

charleski

24th November 2005, 18:26

Check to see if the .avs plays correctly in something like Zoom Player. If not then there's a problem in the frameserver setup (make sure the handlers are installed from auxsetup).
I just did a test and I can frameserve from VDubMpeg2 through meGUI to x264 just fine.

Revgen

24th November 2005, 19:54

I decided to uninstall VirtualDub completely and reinstalled it again. Frameserving now works fine.

Very strange. :confused:

Wilbert

24th November 2005, 21:27

Perhaps you forgot to install the frameserver (auxsetup.exe)?

Revgen

24th November 2005, 21:39

auxsetup.exe was installed and setup. It just wasn't working. Perhaps there was a registry glitch.

nDman

24th November 2005, 22:57

Revgen

25th November 2005, 02:40

may bad english :(

combustion is VFX program similar to Adobe AfterEffect, it not a video effect.
http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=5562397
i don't have problem in combustion with Divx or Xvid.

i downloading last version of x264 and no more crashes with Magix Video Pro.

Cool. :cool:

Also, don't feel bad about your English. English is much easier to speak than it is to read or write. You'd be amazed at how many native English speakers have difficulty reading and writing English. English is my native language and I'm still learning how to read and write it. ;)

charleski

25th November 2005, 02:44

You'd be amazed at how many native English speakers have difficulty reading and writing English.Not if you spend a couple of days looking at message-boards populated by poorly-educated American teenagers! heh

Revgen

25th November 2005, 05:10

Not if you spend a couple of days looking at message-boards populated by poorly-educated American teenagers! heh

[OFFTOPIC]

Sadly it's true :(

And it isn't funny.

Our schools are getting worse. Politicians are cutting school funding all the time to pay for "pet" projects to satisfy their campaign donors.

[OFFTOPIC]

Czarek Kwasny

25th November 2005, 10:26

Hello,
I find x264 icon not very well suited for 48x48 size (it becomes blurred).
Here's fixed version (more detail for 48x48):
http://gfx.artivo.pl/x264.ico

If you find it valuable, feel free to use it. I may share PSD source on demand if needed ;).

Thanks for the good job.

Hyper Shinchan

25th November 2005, 18:13

I was trying to use the new level conformance button in the megui build included in the x264 full release (the one with the installer and with megui).
But when I analize them with mp4info my avc videos are always level 5.1..
What is the problem???

Sharktooth

25th November 2005, 19:09

The problem is x264 default level is 5.1 and MeGUI doesnt pass --level command line option to x264.exe

Doom9

25th November 2005, 19:33

nobody ever told me about level and allowable values...

nDman

25th November 2005, 22:44

hi.
i think there is bug in ffdshow in H.264 decoding.
it can't play this clip correctly:
http://www.vsofts.com/h264/avi/vssh-ccir39_d1_3000.avi :rolleyes:

rig_veda

25th November 2005, 22:47

akupenguin

25th November 2005, 23:26

it can't play this clip correctly:
http://www.vsofts.com/h264/avi/vssh-ccir39_d1_3000.avi
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.

nDman

25th November 2005, 23:46

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

26th November 2005, 05:49

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

26th November 2005, 09:49

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

26th November 2005, 14:48

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

26th November 2005, 15:16

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

26th November 2005, 17:15

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

26th November 2005, 17:17

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

26th November 2005, 17:41

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

Doom9

26th November 2005, 21:04

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

28th November 2005, 11:02

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

28th November 2005, 13:55

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

redfordxx

28th November 2005, 16:13

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

28th November 2005, 17:30

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

28th November 2005, 17:34

Doom9

28th November 2005, 19:22

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

28th November 2005, 19:36

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

charleski

29th November 2005, 13:24

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

30th November 2005, 16:48

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

30th November 2005, 17:15

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

IgorC

30th November 2005, 17:31

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

Sharktooth

30th November 2005, 17:59

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

charleski

30th November 2005, 22:54

Sharktooth

1st December 2005, 04:52

it's not about color, but artifacts.

puffpio

1st December 2005, 09:40

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

1st December 2005, 10:14

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

1st December 2005, 13:02

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

4th December 2005, 09:01

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

4th December 2005, 09:58

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

Tima

4th December 2005, 15:07

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

4th December 2005, 18:32

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

4th December 2005, 18:39

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

squid_80

5th December 2005, 01:16

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

5th December 2005, 02:07

------ 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

5th December 2005, 03:29

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

5th December 2005, 04:11

in this 75 pages thread? ;)

ok thanks :D

molinacabaleiro

5th December 2005, 09:11

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

redfordxx

5th December 2005, 09:16

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

5th December 2005, 10:52

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

redfordxx

5th December 2005, 11:05

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

bond

5th December 2005, 11:15

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

5th December 2005, 11:33

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

6th December 2005, 01:45

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

11th December 2005, 19:20

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

11th December 2005, 20:36

'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

11th December 2005, 20:57

Ok, thx for the info. :)

Cu Selur

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

redfordxx

23rd December 2005, 15:16

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

23rd December 2005, 23:06

"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

26th December 2005, 20:39

@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?