x264 development

[IgorC]

Considerating that difference between x264 HP and Nero HP is aprox. 0.25 +/- 0.1 dB (for 1 CD bitrate) x264 still has potential.

[SeeMoreDigital]

Could somebody please remind me of the FFDshow "VfW Codec Config" settings I need to select in order to get VirtualDubMod to open up MPEG-4/AVC in AVI files please?

Some of my filter settings were lost/altered after de-installing Haali...


Cheers

[Sharktooth]

just enable h.264 decoding in VFW config...

[SeeMoreDigital]

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]

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

[SeeMoreDigital]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[SeeMoreDigital]

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]

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]

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]

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]

~> x264 foo.yuv 352x288 -o foo.mkv
~> mkvinfo foo.mkv
+ EBML head
+ Segment, size unknown
|+ Segment information
| + Muxing application: Haali Matroska Writer b0
| + Writing application: x264
| + Timecode scale: 50000
| + Duration: 0.400s (00:00:00.400000000)
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 36
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Video track
| + Pixel width: 352
| + Pixel height: 288
| + Display width: 11
| + Display height: 9
|+ Cluster
Doesn't look to me like there's a language set.
On the other hand, if I remux with mkvmerge without specifying a language, it adds language=eng.

[Marsu42]

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]

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]

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]

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

[Kyle_Katarn]

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

VideoInspector is a good FCC changer : http://www.kcsoftwares.com/?vtb

[hpn]

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]

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

[berrinam]

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]

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]

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]

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]

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]

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

js

[celtic_druid]

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

[bugmenotwillyou]

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

[Haze_NZ]

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]

thanks
but tried that
doesn't work

[bugmenotwillyou]

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]

does that seem familiar to any one
suggestions any one

[celtic_druid]

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

[Sharktooth]

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

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

[el divx]

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]

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]

Thanks.

Question: How do you remove a patch?

[leowai]

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]

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