x264 development

[celtic_druid]

Not it at all. The reason it is recommended is because it is generally the most recent available. Most of the time there is nothing custom about it.

[peteag]

any ideas of a 1-pass cq mode in x264 or is it already comparable to 1-pass encoding?

[gaekwad2]

1-pass cq mode already exists:

Vfw: Single Pass - Quantizer
CLI: -q##

[Tommy Carrot]

Newbie question here...

How far has x264 come? I haven't checked on
its progress since ~r200, and browsing/searching
the forums hasn't helped me find the answer I
seek.

In terms of quality, how does it compare now to
Xvid, DivX, and the others (I remember it wasn't
as good at ~r200)?

Would it be a bad idea to start making backups
using x264 because it is still too early in the testing
stages?

js
Since rev. 200, x264 got many new features, like 8x8 dct, RDO, UMHex ME method, etc. These can significantly improve the quality.

IMO the mpeg4 ASP codecs cannot come close in quality, x264 is already better than them, sometimes the difference is huge.

I don't know if it's safe to use, but made the decision a few months ago, i exclusively use x264 for my encodings since then, and i've never experienced any problem with it.

[Inventive Software]

It could be that your path is too long, and its fecking up the software then.

Save your stats info to the root c: with a shorter filename as a test to see if that helps. You can always rename it afterwards if you need to.

Also, you may have to re-run the first pass if it turns out the filename was too long, as it may not have saved correctly.

If this is so, can longer statsfile names be implemented ASAP?

[bugsan]

hello

In vfw, the multipass/first-pass *seems* to be done with a constant bitrate (The standalone GUI writes a batch command with a --bitrate, for the 1st pass)

Maybe i'm wrong but i think it should be better with a quant constant.

[NuPogodi]

A bit stupid request, but... CLI applications usually allow to redirect stdout into text file. Could such a feature be implemented for CLI x264 (say, the command 'x264 -h > options.txt' has to create 'options.txt' with a full list of options)?

[MatMaul]

hello!
I have a problem(if it's a problem) : after encode with x264, I mux the video in the matroska container via mkvmerge.But when I look the framerate in the properties (with matroskaprop) I am a value like 24.994...fps for 25 fps for my input video. moreover, when I try to do a caption and go to a precisely frame with xvid and x264 I don't obtain the same frame : there are a shift of 2 or 3 frame.
for info, xvid has the good framerate (25.000fps) and I encode with cli version with avs input and mp4 output.

my command lines :

x264 --pass 1 --bitrate 800 --ref 1 --bframe 5 --direct temporal --weightb --b-pyramid --analyse none --me dia --subme 1 --progress -o NUL: "input.avs"

x264 --pass 2 --bitrate 800 --ref 5 --subme 6 --bframe 5 --direct temporal --weightb --b-pyramid --8x8dct --analyse all --progress -o "output.mp4" "input.avs"

[akupenguin]

In vfw, the multipass/first-pass *seems* to be done with a constant bitrate (The standalone GUI writes a batch command with a --bitrate, for the 1st pass) Average bitrate, not constant. CQP is fine if you pick the right quant, but ABR is better since you don't have to guess.

A bit stupid request, but... CLI applications usually allow to redirect stdout into text file. Could such a feature be implemented for CLI x264 (say, the command 'x264 -h > options.txt' has to create 'options.txt' with a full list of options)? Try 'x264 -h &> options.txt' (or '>&' depending on your shell).

[LigH]

Another way that works for me:

x264 -h 2> options.txt

Reason: You are allowed to use file handle numbers in front of redirectors.

0< = stdin (< = 0<)
1> = stdout (> = 1>)
2> = stderr

[ac-chan123]

@LigH:
under linux you can use tee to print on screen and write a copy into a file.

[LigH]

Probably. But are there Linux builds of the x264 CLI? If so - probably not from celtic-druid.

[Joe Fenton]

I build x264 on Fedora Core 3 for the AMD64. It works nice, but gpac doesn't compile as 64bit yet, so I don't get mp4 output. Also, AVI input isn't possible either. :(

[NuPogodi]

x264 -h 2> options.txt
Thanks a lot...

[peteag]

what about 1-pass cq at a specific bitrate like mpeg2?

[LigH]

For 1 pass: Either CQ, or average bitrate. But both is not possible for 1-pass. The reason is:

With only 1 pass, an encoder would not know which quality / quantizer it has to use to achieve a desired bitrate. This can only be calculated for a 2nd pass.

A CQ tester is not really an exception: I would call that a "1.5 pass mode"... ;)

[yokem55]

but gpac doesn't compile as 64bit yetI have x264 built with gpac support on my 64-bit gentoo box here. To get gpac to build proberly I had to checkout a recent cvs version of gpac and add "-fPIC" to the cflags. As for inputing data into the x264cli, I setup mencoder to frame serve into a fifo that x264 then reads. Mencoder has to be run like this:mencoder somevideo.vob -of rawvideo -ovc raw -vf swapuv -nosound -o myrawvideo.fifo

[LigH]

Just realised that width and height still have to be MOD 16. Do you plan to implement a workaround to circumvent this limitation, e.g. in a similar way as e.g. in XviD?

(AFAIR, often some kind of "mirroring" is used to extend the video area to the next multiple, if necessary.)

[CREXbzh]

Just realised that width and height still have to be MOD 16. Do you plan to implement a workaround to circumvent this limitation, e.g. in a similar way as e.g. in XviD?

(AFAIR, often some kind of "mirroring" is used to extend the video area to the next multiple, if necessary.)
That just a very bad idea not to scale at MOD 16. Please read this to get convinced: http://mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html#menc-feat-dvd-mpeg4-constraints
:)

[Joe Fenton]

I have x264 built with gpac support on my 64-bit gentoo box here. To get gpac to build proberly I had to checkout a recent cvs version of gpac and add "-fPIC" to the cflags. As for inputing data into the x264cli, I setup mencoder to frame serve into a fifo that x264 then reads. Mencoder has to be run like this:mencoder somevideo.vob -of rawvideo -ovc raw -vf swapuv -nosound -o myrawvideo.fifo

Thanks! Just the info I was looking for.

[Manao]

CREXbzh : in fact, it's not a bad idea. It's better to crop to eliminate black borders without being mod 16 than having black borders and being mod16.

[LigH]

I don't need to be convinced, I know the advantages of videos being sized at multiples of macroblock sizes pretty well. But there are situations where you cannot serve optimal video sources. And there are better ideas of virtually filling up, than adding black borders, which are easy to achieve inside the encoder, but not so easy outside of it.

[yokem55]

Thanks! Just the info I was looking for.
A couple of other notes on useing mencoder as a frame server. If you use a telecine filter, you might get some lost frames that will cause nasty audio sync problems. Also, using -noskip on the mencoder command line is needed to get all the frames into x264.

[Joe Fenton]

Right... good idea.

[JasonFly]

Is there any mean to change the fourcc in the cli encoder? I know this command is present in the VFW version(the debug tab) but I cannot find any command in the CLI help (to change fourcc from h264 to avc1 for instance)

[dimzon]

just a little suggestion:
please add "target file size" mode (like in XviD) as -bitrare alternative
Thanx!

[bond]

Is there any mean to change the fourcc in the cli encoder? I know this command is present in the VFW version(the debug tab) but I cannot find any command in the CLI help (to change fourcc from h264 to avc1 for instance)
the cli doesnt output to avi so there is also no need to mess around with fourccs

[JasonFly]

I though mp4 also had fourcc in its header. Shame on me.
I should have read the MP4 FAQ more carefully. I'll read it ten more times as punishement.

So AVC content is only discribed by his private track ID in the MP4 file? Does Ateme/Nero AVC and x264 have the same private track ID?

[bond]

for ensuring interoperability between different encoders the mpeg-4 standard defines clearly how to place avc in mp4 and all encoders claiming to be mpeg-4 compliant have to use that way and x264 and ateme/nero do it therefore too

[guada 2]

Hello, :)

The last version (x267) is not supported by player NERO.
Why? and where come the problem?

Indeed, it is impressive.

[bond]

Hello, :)

The last version (x267) is not supported by player NERO.
Why? and where come the problem?

Indeed, it is impressive.no problem here with as good as all settings enabled..

lossless doesnt work with nero as mentioned already

[guada 2]

it is strange whereas the other versions perfectly functioned.

And the other versions? What it was?

[bond]

post your exact settings used for encoding and a sample clip showing that problem

[LigH]

I love people who post their complete command line used for encoding, in case of playback problems. Or even their whole encoding report. Really. ;)

[guada 2]

I suppose that it is not accepted by MP4BOX?

[bond]

troll?

[guada 2]

I apologize Bond, all is of my mistake.
I was mistaken since the beginning of AVS file.

You are right, I don't have anything say.

a question:
what means " TROLL"? please

[Rash]

Humm, I don't know if it was already posted here somewhere (big topic :)) but I would like to suggest something. And I don't know if it is easy to code and if it is a feature people would use either.

But what if x264 cli encoder took the configurations from a file? Stuff like, b-frames, matrices (now supported), the Macroblock Option, etc? So you would only type

$>x264 --conf configuration.xml -o file.mp4 file.avs
for example. That would be nice to test different videos with the same configuration. ;) Anyway, just a thought, please don't kill me. :)

[guada 2]

Hello Bond :)

You have say this:
"lossless doesnt work with nero as mentioned already"

I have make a small test of lossless with NERO SHOW TIME.
I notice that it accepted the HUFFYUV file?

What is your verdict? strange or luck ??????

[Ariakis]

Hello Bond :)
You have say this:
"lossless doesnt work with nero as mentioned already"

I have make a small test of lossless with NERO SHOW TIME.
I notice that it accepted the HUFFYUV file?


He meant Lossless AVC (as in x264 with qp=0), not HuffYUV

[guada 2]

Other thing:

Concerning the properties of a file encoded with the codec x264:
It would be useful to find a name of for the option " compression video ".

No.. :)

[guada 2]

Ariakis,

I understood it well, not of concern.
it was just to add a report.

NO PROBLEMO.. :)

[LigH]

@ guada 2:

Please, do yourself a big favour:

If you have a technical problem, try to describe it as detailed as possible, especially always post your complete command line, or even the whole application output. Try to read and understand given answers. I'm not sure if you ever read about the infamous "TUVOK" - a former member of many boards, who always asks and asks and asks, but never learns from given answers...

If you instead have a personal problem with another member, discuss it privately (e.g. send a "Private Message" via the small menu that pops up when you click on his user name), but don't mess an important thread.

[Luminaria]

Sorry if this has been asked before, but are there plans to include a directshow decoder in x264 in the future?

[Manao]

No. In fact, there isn't any working decoder in x264 at the moment, because the 'official' decoder is ffmpeg. So the 'official' directshow decoder is FFDShow.

[guada 2]

Hello,

LiGH

I don't understand your reasoning.
Where do you seen a problem?

It is me that have make a mistake in my applications.
BOND didn't understand my problem.
He thought that I had found a error on the codec.

It is FALSE.

I understood its thought.
I even have make a small parenthesis without consequence.

But where is the problem?

On the other hand I didn't understand the word that he used, and I don't always know the translation / "TROLL".
If you believe that I have make something, don't hesitate to tell it to me.

That is sure, when I have a problem I say it honestly and in direct; And there doesn't have a problem ( I think that you understand me LIGH ).
If my mistake caused twists , I apologize but if it is not the case I would like to understand.

I don't tempt to destabilize the progression of the codec.
Indeed, I approve the work that is accomplished. and I thank all those that participate in to create a reliable and effective codec.

For all problem, I would not hesitate to follow your advice.
Thank you for your sense of the dialogue and your understanding.

Mario.

[LigH]

Mario - you too?! :D
__

"Troll" is also a mystic figure in the old german mythology, can have a dwarvic or giantic size, but usually does no good... (try to search for "define: troll" with Google)

We probably suspected you "trolling" because we asked again and again for more details, but you didn't deliver any facts. For this reason, I just recommended you to be a little more careful how your posts look aand sound like. But I did not want to say that I personally would dislike you! ;)

Let's stop any open discussions about misunderstandings. Let's keep the thread clear for technical facts, please. :)

[guada 2]

Ligh,

I appreciate your spontaneity. :)
Thank you very much.

Mario

[Joe Fenton]

"Troll" is also a mystic figure in the old german mythology, can have a dwarvic or giantic size, but usually does no good... (try to search for "define: troll" with Google)

The usual meaning of the term troll in forums is derived from:
To fish for by trailing a baited line from behind a slowly moving boat.

The baited line is the trollish reply and is often referred to as 'flamebait'. The 'fish' are incensed people who reply angrily to the post. The troll is trying to stir up trouble by posting replies he knows will get others on the board angry.

[Chaos Creator]

Hello,

I've just endode a video file, once with threads set to 1 and once with threads set to 2! I used the exact same options! I use the vfw codec! Here is the problem:

1 Thread = 936 KB

2 Threads = 947 KB

Why this difference???

[Manao]

Because ! 2 threads -> 2 slices ! 1 threads -> 1 slices ! And slices can't reference each other spatially ! And slices reset cabac contexts !

All that to say : slices ( and so threads ) allow a faster encoding, but reduces the codec efficiency.

[Sharktooth]

All that to say : slices ( and so threads ) allow a faster encoding
Only on systems with multiple execution units (hyperthreading, multi processor, or multicore).

[bill_baroud]

If your code keep all your execution units busy correctly, using hyperthreading won't help you, and even will harm performance (by disrupting the instructions flow of your program that you carefuly set and managed with love and care and ... err i need to stop coding in assembly)

But well yeah, in practice, you can't never keep your executions units busy and break all dependances.

[dinolib2]

Here (http://forum.doom9.org/showthread.php?t=96059) you can read, under "current issues with AVC/H.264" paragraph, this sentence: .avi: using AVC-in-AVI is nowhere standardized and therefore already causes incompatibilies. The limitations of AVI and VFW (eg regarding b-frames or arbitrary frame coding orders), together with the necessary hacks caused by these two formats, hinder the full implementation of all possible features AVC offers and therefore harm the possible quality or at least the speed of the development, the interoperability and therefore also the competition. AVI is currently used by VSS and x264 (mencoder and vfw)

My question is: in this state of development, is x264 quality limited by avi restrictions? Could be in the future developed some "advanced feature" no more compatible with avi container (and not present in VFW)?

Sorry if I've made a silly question :D

[absinthe]

Doom9 suggested that I report an odd problem here: x264 from the command line with the --progress parameter does not show any progress output on my box. Therefore, I see no status progression in the ProgressWindow of MeGUI.

Several people seem to be affected by this, including some who do get progress at the command line and still do not get progression in the MeGUI ProgressWindow (though that may not be relevant here). At least one other person has the same problem I do with no progress at the command line.

I use WinXP Pro (SP1), Athlon 1600 XP. Nothing unusual about my box that I can think of. I'm using the latest x264 (revision 270).

Let me know if I can provide more info.

-abs

[Sharktooth]

Maybe starting with installing all OS updates (including SP2) will exclude a good amount of possible problems...

[Doom9]

(though that may not be relevant here)It doesn't. I'll take care of of those in my own domain eventually.

[kurt]

I have the same problem like absinthe (no progress at cli)...
I use WinXp Home on my P4 2ghz with 512 MB RAM - I installed all windows updates (including sp1 for .net 1.1)...
with mencoder there are no problems...
Any idea what's going wrong?

Edit: this is the window during encoding (wich always finished fine)
http://img220.echo.cx/img220/7595/image17ii.th.jpg (http://img220.echo.cx/my.php?image=image17ii.jpg)

[Sharktooth]

what build are you using?

[kurt]

what build are you using?
latest revision (270) :) (sorry forgot that to mention)

[Sharktooth]

my build or other's build? or the problem is still there indipendenlty from which builds you use?

[kurt]

my build or other's build? or the problem is still there indipendenlty from which builds you use?
normally I use your builds, but I tried bob0r's even too - same problem here....

[Sharktooth]

well... a compiler issue is excluded then: i use gcc 4.0.0 and bobor 3.4.x (IIRC).

[ckjnigel]

Can someone explain where Ahead/Nero has positioned itself with regard to H and X .264? It's important for me to know so as to choose which codecs to install; I recreate my X64 partition once a month. This go round I've discovered that that 6/19 ffdshow cannot compare to Videolan VLC player and the latest Nero video decoder is even better playing back an H.264 in an avi container created with Gordian Knot.
I'm guessing that X.264 could be a format for video as well suited to Pocket Pc as AAC+ is for audio.
I'm hoping that Pocket PC freeware BetaPlayer and TCPMP developer Picard is being kept in the loop. ( see http://tinyurl.com/86aq2 )

[bond]

avc is avc no matter what codec (nero, x264 or whatever) you use to create the stream

place avc in the .mp4 container and you will be able to play the file on as good as all avc enabled players (including nero's stuff)

[posix]

where do i find a list of all resolutions this codec supports? (searched this thread for "resolution" without success)

[LigH]

What do you mean with "all resolutions"?

From "poststamp" up to HTDV dimensions - no problems. The only required precondition: Width and height must be multiples of 16 - x264 does not yet support "any" size by virtually filling up the dimensions to multiples of a macroblock.

I only remember one kind of codec which was limited to only a few special resolutions: H.261 (used for ISDN {64 kbps} video telephony).

[berrinam]

Is there no maximum resolution, or is it just so large that it is irrelevant?

[LigH]

There is most probably a maximum. But do you really need to encode e.g. 4096x4096 videos? Where do you want to get material larger than 1920i?

[Andrey]

>>There is most probably a maximum. But do you really need to encode e.g.
>>4096x4096 videos?
Original digital D5 source should be about this resolution. And it will not be stored uncompressed, I think. This is not what is called a "consumer" use, but still it should be handled somehow.

[LigH]

It is very hard to find useful pages about the D5 format. Mostly copies of the Wikipedia article, which is limited to HD-D5 with resolutions up to 1080 lines.

[SeeMoreDigital]

When I was last in a TV studio D5 referred to: -

625 line component digital video recorded onto ½" (12mm) tape, using an uncompressed 601 format. The max run/record time was 128 mins with up to 4No digital audio channels

It was used in the UK by Channel 4 in late 1990's as transmission format but was replaced by Digi-Beta due to the high cost of the hardware and the media.


Cheers

EDIT: Don't most production companies use the DPX process to convert film to digital video nowadays?

[Andrey]

>>When I was last in a TV studio D5 refered to
Hmmm...
Thanks for the info, SeeMoreDigital.
I saw an article, where D5 was reffered as an high definition digital (primary) source digital television sources are produced from.
Need to check it once more...

[LigH]

The DVD authoring studio I once worked for had a HDTV cinematic film scanner; AFAIR, a hot plug able 10 SCSI HDD RAID. No idea which file format they use. but a hell of a machine! :D

[Doom9]

I've had a feature request for MeGUI to offer more control over the turbo option. I'm wary of that because I'd like to prevent that incorrect settings will severely degrade the output. So far, I'm reducing subq, 8x8b options (what about the 8x8i and adaptive dct by the way.. can they be safely deactivated) and number of reference frames. Is there anything else that can be safely changed without having visibly adverse effects on the result? Or put the other way round: which options are not a "must-match" and how far can they be tweaked?

[Sharktooth]

analyze can be set to none
reference frames to 1
8x8dct can be disabled
diamond search ME can be used.
the difference between using the same settings for 2 passes and this method is negligible.

[bond]

I've had a feature request for MeGUI to offer more control over the turbo option. I'm wary of that because I'd like to prevent that incorrect settings will severely degrade the output. So far, I'm reducing subq, 8x8b options (what about the 8x8i and adaptive dct by the way.. can they be safely deactivated) and number of reference frames. Is there anything else that can be safely changed without having visibly adverse effects on the result? Or put the other way round: which options are not a "must-match" and how far can they be tweaked?
pengvado himself once made a post on what should be safe to use, dont find it anymore tough

[Doom9]

pengvado himself once made a post on what should be safe to use, dont find it anymore toughI know.. must be in this thread or in the old MeGUI one and I implemented exactly what he described. But at that time x264's feature set was more limited, especially the VfW version which was taken as template at that time (x264.exe only became useful when it got AviSynth input suport).

[berrinam]

is it this post? (http://forum.doom9.org/showthread.php?p=595200#post595200)

[Doom9]

is it this post?yup yup (2nd yup due to the minimum post lengt of 5;)

[bond]

yup yup (2nd yup due to the minimum post lengt of 5;)
yeah, would be great if this could get changed back to 3 as it was the case in the old board :D

[superdump]

Doom9: That post that aku made was merely stating what the fast first pass in vfw does. Since then I carried out some testing of an as fast as possible method, i.e. -r 1 -m 1 --me dia -A none and no 8x8dct in the first pass, all was confirmed as being theoretically OK to do and the results of my testing was that there was negligible difference between doing a full quality first pass and this fast first pass. The difference was less than +/- 0.1dB and the speed increase was approximately 3-fold compared to the usual (non-turbo) first pass. My second pass options are -r 5 -m 6 --me umh -A all --8x8dct. I think it would be appreciated if this were also implemented in the GUI. Feel free to test it yourselves.

EDIT: This is using an ABR first pass and bitrate target second pass.
EDIT: Reworded the last section and altered the meaning as it was incorrect to what I actually intended.

[cheburashka]

...I think it would be appreciated if this were also implemented in the GUI. Feel free to test it yourselves...

I second it after pengvabo might confirm this.
Or you can add it as addition to turbo mode. Lets name it "supersonic" 1st pass :)

[Doom9]

EDIT: This is using an ABR first pass and bitrate target second pass.Is there even a difference specifying --pass 1 and then a bitrate or only a bitrate? Don't you get an ABR either way?

I'll make those turbo changes shortly when I attack the configuration screen again (bond asked for AVC profile levels and I'll be happy to oblige once I can locate the specs).

[superdump]

I second it after pengvabo might confirm this.
Or you can add it as addition to turbo mode. Lets name it "supersonic" 1st pass :)
Pengvado is away and won't be back for a few months. We might be able to contact him at some point though. I did request that it be done but I think Alex_W and algern0n were apprehensive and wanted it to be tested further. So if people can test with a wide variety of sources and post results that would be appreciated. I could always make a patch which alters the fast first pass code as necessary, wouldn't take long.

Is there even a difference specifying --pass 1 and then a bitrate or only a bitrate? Don't you get an ABR either way?

I'll make those turbo changes shortly when I attack the configuration screen again (bond asked for AVC profile levels and I'll be happy to oblige once I can locate the specs).
If there is a difference it will be that specifying --pass 1 forces stats output.

bond wants profiles/levels? Do you mean setting that flag in the encoder or what? I was thinking of possibly tackling this as one of my first contributions to x264 as it should be quite easy. The hard part is deciphering the standard. :) I think it would be good if specifying a level restricted the options available and enforced the necessary resolutions/framerates/macroblock rates/vbv etc etc.

[Doom9]

I think it would be good if specifying a level restricted the options available and enforced the necessary resolutions/framerates/macroblock rates/vbv etc etc.That's the one. I already implemented parts of this (simple, main and high profile features).. the next step would go into levels within a profile.. where resolutions, vbv, etc comes into play. So if you like to read up on this and share your findings, that would be a very valuable contribution indeed and I think it would also make sense to implement the results of such research into the VfW and have something just like the VfW profiles.

I'll try to prioritize the "update jobs" feature so testing will become much easier. Right now I have to switch between inputs of my flatscreen to set up my new X2 based barebone :) x264 is gonna fly with the new CPU :)

[SeeMoreDigital]

Depending on how many profiles they'll eventually be, would it be "too daft" a suggestion for x264 to include a range of profile settings that match NeroDigital AVC.


Cheers

[bond]

Depending on how many profiles they'll eventually be, would it be "too daft" a suggestion for x264 to include a range of profile settings that match NeroDigital AVC.nero doesnt want to share the specs of their private profiles, so why should anyone mess around with them...

apart from that, with no really widely useable avc hardware existing, what sense does it make to specify and use private avc profiles different from the official mpeg ones...
they will be changed anyways once the chips arrive

[superdump]

OK, I've been discussing this with Manao and there is a slight problem. The levels impose limitations on MV lengths. x264 currently doesn't check the MV length during ME and doing so would reduce the speed and mess up the code, which is currently very neat. So instead I'm going to direct my efforts elsewhere... more RD maybe. :)

[IRMA1024]

is x264 stuck on rev270 i don't see any revision after? i hope next, error resilence will be implemented... btw... nice work

[Ark]

If you look at the daily build sticky thread, you'll see "summer break" written, which means that for a while rev270 will be the last build available, as developers (in particular akupenguin) are enjoing their holidays!

[LigH]

Did you notice the addition "Summer Break" in the title of the thread with the most recent builds by Sharktooth? In my opinion, this means: Don't expect many updates because most developers are on vacation. ;)

[akupenguin]

Since then I carried out some testing of an as fast as possible method, i.e. -r 1 -m 1 --me dia -A none and no 8x8dct in the first pass, all was confirmed as being theoretically OK to do and the results of my testing was that there was negligible difference between doing a full quality first pass and this fast first pass. The difference was less than +/- 0.1dB and the speed increase was approximately 3-fold with my second pass (-r 5 -m 6 --me umh -A all --8x8dct).
You can't measure the benefits of turbo just by the 1st pass's speed. What you should ask is: how much did your version of turbo reduce total encode time over both passes, vs how much time would you save by reducing 2nd pass options by the same amount of quality?

The levels impose limitations on MV lengths. x264 currently doesn't check the MV length during ME and doing so would reduce the speed and mess up the code, which is currently very neat. It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.

[superdump]

You can't measure the benefits of turbo just by the 1st pass's speed. What you should ask is: how much did your version of turbo reduce total encode time over both passes, vs how much time would you save by reducing 2nd pass options by the same amount of quality?
Why would I want to reduce the second pass options? That doesn't make sense to me. I use the second pass options I do because they're what I consider to be realistically the maximum I can get out of the codec without wasting time on -r 16 or whatever. The point of increasing the speed of the first pass was to avoid wasting time with encoding complexity when it doesn't significantly affect the output of the second pass with my preferred options. If I were to reduce the second pass options too I would reduce the quality of the output, which is undesirable. Am I misinterpreting what you're saying because it seems an unusual suggestion? (The second part. The first part, comparing the overall speed not just first pass, is reasonable.)

It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.
Ah, cool.

EDIT: I reread the section you quoted from me and it reads like I was comparing the first pass speed to the second pass speed. I essentially was because I used the same first and second pass options in the non-turbo encode but what I actually intended was that the first pass with the turbo options I've specified are ~3 times faster than the first pass which uses settings identical (aside from -p) to my second pass settings.

[Doom9]

It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.So it could be done after all.. :) So if we can translate the specs into x264 options I'm all game for implementing it into megui

[NuPogodi]

Just a stupid question about compressing black'n'white video... till now, i've found the only option ('--no-chroma-me') to accelerate reencoding b&w movies. Did i miss something? any plans to make the b&w-optimized preset which allows to ignore all croma info?

[IgorC]

rev270B has a EQM AVC-HR matrix. What kind of source and bitrate this matrix is for?
I'd suppose it's like Xvid EQM HR matrix. But how high bitrate? 1.5 Mbit is it enough for DVD 720X480 23.976 fps source to use this kind of matrix ? Any result?

[superdump]

rev270B has a EQM AVC-HR matrix. What kind of source and bitrate this matrix is for?
I'd suppose it's like Xvid EQM HR matrix. But how high bitrate? 1.5 Mbit is it enough for DVD 720X480 23.976 fps source to use this kind of matrix ? Any result?
If you search the forum for the name of the matrix you will find Sharktooth's thread.

[Sharktooth]

look at my signature. however 720x480, 23.976fps and 1500kbps should be enaugh to use it (unless the source is really noisy or have bad compressibility).
Some feedback would be really appreciated :)

[zombi55]

Hi..

I have some troubles with the x264 VFW codec or the H264 ffdshow. I made a "small" encoder using the windows API functions ICopen, ICDeCompress and ICCompress. All is well but every time I want to use a x/h264 codec, the ICClose function crashes. I code using VC++ and even in debug mode I can't find a solution, I have a message [ User breakpoint at 0x..... ] in NTDLL.

Can anyone help me? (All others VFW codecs work perfectly, even VP62 and VP70)

[LigH]

In my opinion, the SAR option works wrong.

I used the following command line:

--bitrate 1000 --min-keyint 50 --ref 6 --subme 6 --bframes 3 --weightb --b-pyramid --analyse all --qpmin 1 --ratetol 4.0 --merange 64 --me umh --sar 16:9 --progress --threads 1

The result:

ffdshow 2005-07-03 reports an AR of 20/9.

mplayer 2005-06-27 reports a movie AR of 2.22:1.

All players and filters (Ateme too) resize from 720x576 to 1280x576.

[Sharktooth]

Some doom9.it users reported that problem too...
the weird thing is i made a lot of anamorphic encodes and didnt notice it.
i'll make a new encode to check.

[DeeGee]

Works fine here. At least when I use the aspect ratios told here (http://forum.doom9.org/showthread.php?t=86870).


And here are the settings you'll need for both PAL and NTSC 4:3 and 16:9 DAR (which are based on PAR): -

Required AR Custom DAR(PAR) Setting
4:3 PAL 64:60 (or 16:15)
16:9 PAL 64:45
4:3 NTSC 64:72 (or 8:9)
16:9 NTSC 64:54 (or 32:27)


I simply use those values as imputs for the --sar setting as these aspect ratios with their sar, dar and par make me dizzy :)
I'd need quite exact explanation on which means what and how to calculate them.

[LigH]

O.k. - so must be my mistake, I probably read it as "source AR" or so...

If the sample=pixel AR is used here, I'll try again with 1024:704 = 16:11 (almost IRU-R BT.601 compliant). Here I would expect a width of 720*16/11 (~ 16) = 1048 pixels.

[Manao]

LigH : your results are those expected : SAR means Sample Aspect Ratio : it's the AR of a pixel. Now, the Aspect Ratio is somethings different : it's the playback width / playback height. Since you encoded a video whose ratio width / height is 5:4, and since you set up a SAR of 16:9, you get an AR of 16:9 * 5:4 = 20:9, ie, what the playback filters are reporting.

[LigH]

Yes, must be right: 720*16/9 = 1280, and that's what I got. My mistake.

[Japhsoncross]

i did some tests for a few days on x264 and nd mp.
i captured the video from the window while i was playing the emu(emulator) 384*224(machine resolution)@30fps, and the game is Street Fighter Zero 3, i think this kind of material is absolutely clean, 'cause the background and character moves without details changing. i encoded it with both x264 v270vfw and nero recode @650kbps and 750kbps. and my decoder is ffdshow050619, and i turn the visualizations fuction of ffdshow on, with displaying the motion vectors. i found that on most occasions, nd mp's motion vectors seem more correct than x264's according to the video.

settings:
targat bitrate 750kbps
x264: no loop filter(deblock), max ref 5, minqp 1, b frame reduction 0, max 3 b-frames, use as ref, adaptive, bias 0, 8*8DCT 4*4intra, chroma me, RDO, UMH , me range 32, direct mode temporal.
nd mp, -512 - 512, 5 ref, no deblocking

see the images attached:
ND MP@750kbps
http://forum.doom9.org/attachment.php?attachmentid=4291&stc=1
x264 v270@750kbps
http://forum.doom9.org/attachment.php?attachmentid=4292&stc=1

[FredThompson]

The sources link is dead. Given it's summer break :P, would someone pease mirror these?

[superdump]

Japhsoncross: That doesn't look right at all. Something's amiss.

FredThompson: It's only really a 'summer break' because akupenguin is away. I'm fairly sure SharkTooth is still around and anyway you can find out how to get the source code on http://developers.videolan.org/x264.html .

[leowai]

Some doom9.it users reported that problem too...
the weird thing is i made a lot of anamorphic encodes and didnt notice it.
i'll make a new encode to check.
Me too. Just realise that days of conversion wasted, but we learned from mistakes. :)
O.k. - so must be my mistake, I probably read it as "source AR" or so...
Since there are confliction caused, will it be good to name the parameter as PAR (Pixel Aspect Ratio, which used in the link below) rather than SAR (Sample Aspect Ratio)? Sample also not clear enough for me. Sample = Source (i.e. original source)? Sample = Input Video source for encoding?

Works fine here. At least when I use the aspect ratios told here (http://forum.doom9.org/showthread.php?t=86870).
I simply use those values as imputs for the --sar setting as these aspect ratios with their sar, dar and par make me dizzy :)
I'd need quite exact explanation on which means what and how to calculate them.
I think following link is useful to you. It provides some information about this matter:
http://www.3ivx.com/support/par.html
Just learn that: It's NOT neccessary for the pixels a video to be sqaure (i.e. width-to-height ratio of 1:1)!

[Manao]

Japhsoncross : the picture you chose is a bframe, isn't it ? some version of ffdshow are buggy when displaying motion vectors on bframe.

Leowai : the standard calls explicitely that parameter SAR, not PAR.

[LigH]

From ISO 13818-2 (6.3.3: Sequence header), MPEG-2 does it in a similar way: Allowed aspect ratios for MPEG-2 video are

- 1:1 SAR
- 4:3 DAR
- 16:9 DAR
- 2.21 DAR

and SAR = DAR * width/height

So the same must obviously be true for MPEG-4 video.

[Manao]

> SAR = DAR * width/height

Hum, no. SAR * width / height = AR ( or DAR )

[LigH]

In this document, they use an inverted DAR. 3:4, 9:16, 1:2.21 - that's why... :rolleyes:

I hate such kind of "un-common" specification.

[Sharktooth]

The sources link is dead. Given it's summer break :P, would someone pease mirror these?
Link to the source files is fixed... (sorry, didnt notice it)

[namchik]

vfw dll was packed into CLI version (http://www.webalice.it/f.corriga/x264/X264CLI_rev272B_mmx.7z) ??

[Rash]

Yes, it was. ;)

[leowai]

Leowai : the standard calls explicitely that parameter SAR, not PAR.
Thanks for correcting my wrong concept. :)
I see the update of vfw build from sharktooh too.

@namchik,

I think the *CLI* only consists of the client executable. If you want vfw support in VirtualDub, you need to download the installer instead.
x264 VFW Revision 273: http://www.webalice.it/f.corriga/x264/X264VFW_rev273_mmx.exe

[Sharktooth]

Sorry for the inconvenience, it was a wrong copy/paste "issue" :)

[yaz]

In my opinion, the SAR option works wrong.it worx right but ... it's not sar but (custom) par.
... --sar 16:9 ... ffdshow 2005-07-03 reports an AR of 20/9.that's correct then :) (16/9)x(5/4)=(20/9) ~ 2.25:1

the bests
y

[SeeMoreDigital]

it worx right but ... it's not sar but (custom) par.
that's correct then :) (16/9)x(5/4)=(20/9) ~ 2.25:1Agreed

I think it would make more sense if it read something like... "Custom PAR" and not "Sample Aspect Ratio": -

http://img121.imageshack.us/img121/8002/x264arsettings4nr.png


Cheers

[Sharktooth]

Custom PAR is misleading.
I modified it and it's "Sample AR" now...

[bond]

SAR is pixel aspect ratio, no?

why not simply call it "Pixel AR" than?

[LigH]

Because "Pixel" and "Picture" are sooo similar sounding... :rolleyes:

This should be the reason why at least since ISO/IEC 13818-2, MPEG uses "Sample AR" and "Display AR".

[lexor]

you guys make me cry :scared: can't you just come up with a unique and precise name for every single thing, nooo you have to make life diffcult.

here is my proposition, let's erase all text in the gui's so that no one knows what option does what, obscure but FUN FUN FUN!! you never know what you gonna get :p

[SeeMoreDigital]

And here was me thinking this sort of thing had been agreed ages ago :eek:

3ivx has been using the terms PAR (for Pixel Aspect Ratio) and DAR (for Display Aspect Ratio) for ages. XviD has also been using the term "Pixel Aspect Ratio" for ages - And the term "Picture Aspect Ratio" to describe the Display Aspect Ratio... but lets not go there!

In my opinion the term PAR (Pixel Aspect Ratio) is all we need because PAR offers the greatest flexibility when it comes to altering the shape of your encodes. Including the possibility of generating encodes to either, PAL 4:3 / 16:9 DAR or NTSC 4:3 / 16:9 DAR

That said, an incorrectly shaped encode with PAR signalling can be a bit of a pain to sort out "after the event".... Which is why I feel we could really do with an tool such as MPEG4 Modifier which x264 friendly.... but that's for another thread!


Cheers

[bond]

Because "Pixel" and "Picture" are sooo similar sounding... :rolleyes:

This should be the reason why at least since ISO/IEC 13818-2, MPEG uses "Sample AR" and "Display AR".well "sample" can also mean the whole pic imho :D
i personally definitely wouldnt think of "pixel" when i read "sample"

[Manao]

Actually, i still think 'sample' is the most appropriate term. 'Sample' refers the smallest / undivisable unit of the signal, so it can't refer to the frame. And 'pixel' refers to what is shown on the screen ( meaning, after scaling ), so it would be inappropriate in that case. But that's bitching on the definition... ( /me thinks the mpeg4 guys spent at least a week in meetings just to decide that name ;) )

[708145]

well "sample" can also mean the whole pic imho :D
i personally definitely wouldnt think of "pixel" when i read "sample"

Would anyone send me a sample video please :p
SCNR.

bis besser,
Tobias

P.S.: It would be too easy if we would understand each other right away, right?

[LigH]

BTW: Did someone already mention the "texel"? :rolleyes: :D -- IMHO: "like in the specs" is okay.

[SeeMoreDigital]

As far as I'm aware SAR (Storage Aspect Ratio) refers to the pixel aspect ratio of the source as it stored digitally on electronic media, before correction...

In the case of DVD, a PAL 720x576 source, has a SAR of 1.25:1. And an NTSC 720x480 source, has a SAR of 1.50:1


Cheers

[Manao]

No

PAL 720x576 (4:3) has a SAR of 16:15
PAL 720x576 (16:9) has a SAR of 64:45
NTSC 720x480 (4:3) has a SAR of 8:9
NTSC 720x480 (16:9) has a SAR of 32:27

[LigH]

May depend on how exact you calculate: 702:{768|1024} or 704:{768|1024}. But such cancelled fractions shall be suitable as long as the differences between the ITU specs and the calculated fractions are below recognition...

[SeeMoreDigital]

No

PAL 720x576 (4:3) has a SAR of 16:15
PAL 720x576 (16:9) has a SAR of 64:45
NTSC 720x480 (4:3) has a SAR of 8:9
NTSC 720x480 (16:9) has a SAR of 32:27Errrm... as far as I'm aware....

PAL 720x576 (4:3) has a DAR of 16:15
PAL 720x576 (16:9) has a DAR of 64:45
NTSC 720x480 (4:3) has a DAR of 8:9
NTSC 720x480 (16:9) has a DAR of 32:27


Cheers

[LigH]

@ SMD:

No. 4:3 video has a DAR of 4:3, 16:9 video has a DAR of 16:9 (DAR = "Display ASpect Ratio" is the whole picture, after resizing: width:height). At least it is documented this way in the MPEG-2 specification ISO/IEC 13838 Part 2 in chapter 6.3.3.

MPEG-2 video with aspect ratio flags "DAR 4:3" or "DAR 16:9" have to be resized so that the ratio between the width and the height of the decoded frame has to become 4:3 or 16:9.

[SeeMoreDigital]

In the case of say, an PAL 16:9 anamorphic DVD...

An 720x576 (1:1) source image without correction = SAR
An 720x576 with 64:45 PAR correction = DAR


EDIT: Or as SteveG put it..........

==================================================================================
Assuming

DAR = display aspect ratio - x/y ratio of physical dimensions (e.g inches or cm - NOT pixels) of display screen
PAR = pixel aspect ratio - x/y ratio of the physical dimensions of a single pixel
SAR = storage aspect ratio - x/y ratio of the #of pixels being encoded, always known from the file

==================================================================================
MPEG-4

DAR = PAR x SAR, where

PAR is based on "aspect_ratio_info" in the Video Object Layer

For aspect_ratio_info values 1 - 5,
PAR = 1:1, 12:11, 10:11, 16:11, and 40:33 respectively.

If aspect_ratio_info = 15, PAR is the custom value:
"par_width" / "par_height"

where par_width & par_height are any two relatively prime integers
between 1 and 255. Those two values are stored in the VOL as well.

==================================================================================
MPEG-2

Based on "aspect_ratio_information", stored in the Sequence Header

If aspect_ratio_information is "1", PAR = 1:1, and therefore DAR = SAR

If aspect_ratio_information is "2", "3", or "4", DAR = 4:3, 16:9 or 2.21:1 respectively,
in which case PAR = DAR/SAR

However (this is relatively rare):

If Sequence Display Extension is present and display_horizontal_size
and display_vertical_size are present and differ from the SAR,
then their ratio will replace SAR in the above equation.

==================================================================================
MPEG-1

Based on "pel_aspect_ratio" located in the Sequence Header

DAR = PAR x SAR

where PAR = the reciprocal of 1.0000, 0.6735, 0.7031, 0.7615, 0.8055,
0.8437, 0.8935, 0.9157, 0.9815, 1.0255, 1.0695, 1.0950, 1.1575 or
1.2015 for pel_aspect_ratio values of "1" thru "14" respectively.

However:

0.9157 is commonly accepted to mean 11/12 or .9166, the reciprocal of 12/11 (1.091) and,
1.0950 is commonly accepted to mean 11/10 or 1.1, the reciprocal of 10/11 (0.909)

==================================================================================

:cool: more or less, anyway
Cheers

[Manao]

Well, his definition of SAR is his own, but not the standard's one, that's all. Once and for all, SAR means SAMPLE aspect ratio, ie, what he calls pixel aspect ratio.

[SeeMoreDigital]

Okay think of SAR x PAR = DAR this way...

An SAR of 1.25 (ie: 720x576) x an PAR of 1.0666666 (ie: 16:15) = an DAR of 1.3333333 (aka 4:3)
An SAR of 1.25 (ie: 720x576) x an PAR of 1.4222222 (ie: 64:45) = an DAR of 1.7777777 (aka 16:9)

An SAR of 1.50 (ie: 720x480) x an PAR of 0.8888888 (ie: 8:9) = an DAR of 1.3333333 (aka 4:3)
An SAR of 1.50 (ie: 720x480) x an PAR of 1.1851851 (ie: 32:27) = an DAR of 1.7777777 (aka 16:9)


Cheers

[Wilbert]

@SeeMoreDigital,

You are both right, but the problem is the naming of things. The MPEG-2 specs (page 47) says the following

SAR = DAR * horizontal_size/vertical_size

with horizontal_size the width of the displayable part of the luma component of pictures in samples (vertical_size idem ...). I think this just means the number of horizontal pixels.

So, what they call 'horizontal_size/vertical_size' is called 'storage aspect ratio' by Stegre. What they call SAR (or sample aspect ratio) is called '1 / PAR' by Stegre.

So, for example

SAR = DAR * horizontal_size/vertical_size = 3/4 * 720/576 = 0.9375

Interestingly, the MPEG-2 doesn't mention PAR at all. So, a question for Manao, where is the term PAR coming from (if it isn't mentioned in any specs)?

edit: i didn't know the DAR values in the MPEG-2 specs are actually 3/4, 9/16, etc ... :)

[LigH]

Interestingly, the MPEG-2 doesn't mention PAR at all. So, a question for Manao, where is the term PAR coming from (if it isn't mentioned in any specs)?
MPEG-1 specs, ISO/IEC 11172 Part 2, Chapter 2.4.3.2 "Sequence header":

pel_aspect_ratio -- This is a four-bit integer defined in the following table.

pel_aspect_ratio - height/width - example
0000 - forbidden
0001 - 1.0000 - VGA etc.
0010 - 0.6735
0011 - 0.7031 - 16:9, 625line
0100 - 0.7615
0101 - 0.8055
0110 - 0.8437 - 16:9, 525line
0111 - 0.8935
1000 - 0.9375 - CCIR601, 625line
1001 - 0.9815
1010 - 1.0255
1011 - 1.0695
1100 - 1.1250 - CCIR601, 525line
1101 - 1.1575
1110 - 1.2015
1111 - reserved
__

Unfortunately, I do not yet know where to find MPEG-4 specifications...

[SeeMoreDigital]

Interestingly, the MPEG-2 doesn't mention PAR at all. So, a question for Manao, where is the term PAR coming from (if it isn't mentioned in any specs)?That's right, because Mpeg2 / DVD, in its commercial form only offers 2No SAR sizes (720x576 for PAL or 720x480 for NTSC) and 2No DAR sizes, 16:9 and 4:3. However, the DAR sizes are still calculated using PAR.

People are now used to cropping and re-sizing their MPEG-4 encodes to any old convenient pixel frame size that either exactly or closely represents the movies theatrical aspect ratio. But with the aid of PAR we can now subtly adjust the pixels to match our 2No (DAR) screen sizes.


Cheers

[Sharktooth]

Regardless of this discussion i will keep the "Sample AR" label coz the cli option is --sar and not --par or --dar ...
When and if the cli option will change name i'll modify vfw accordingly...

[LoKi128]

--- OFFTOPIC ---
Just to add my little grain of sand, as I've said before I think the whole anamorphic thing is just a leftover from the old analog age of fitting a wider picture into a "slimmer" film frame. It is definetly not needed in the digital world, but I do agree that it might save some bandwitdh with little impact on quality.

That said, in my mind it is more intuitive to use the Display Aspect Ratio because it just describes the final AR that the picture should take. I don't care about the pixel or sample aspect ratio, or any other convolutions that the program needs to get to the desired DAR. I just want it to get there, and using the DAR you also use the already established convetions of 4:3, 16:9 or 2.35:1, not yet another set of values to remember.
--- OFFTOPIC ---

[SeeMoreDigital]

At the end of the day it all comes down to the terminologies and abbreviations we give things.... We can make them as simple or as confusing as we want. And even more confusing if we use the same abbreviations to mean different things!

DAR = Display Aspect Ratio (Relates to the 2No TV/Computer monitor sizes. Which are, 4:3 and 16:9)
PAR = Pixel Aspect Ratio (Which can be any ratio you care to make)
SAR = Storage Aspect Ratio (Relates to square pixel ratio, before correction, of the movie, as it's stored in an digitized electronic form (ie: DVD, VCD, disc, disk, tape etc).
MAR = Movie Aspect Ratio (Relates to how the movie makers indend the finished production image to be viewed)

In effect SAR should not mean "Sample" it should mean "Storage"

EDIT: As Wilbert mentioned.... It comes down to "the problem is the naming of things"


Cheers

[LigH]

So.

Now that I found a source of the ISO/IEC 14496 Part 2:

6.3.3 Video Object Layer
...
aspect_ratio_info: This is a four-bit integer which defines the value of pixel aspect ratio. Table 6-12 shows the meaning of the code. If aspect_ratio_info indicates extended PAR, pixel_aspect_ratio is represented by par_width and par_height. The par_width and par_height shall be relatively prime.aspect_ratio_info pixel aspect ratios
0000 Forbidden
0001 1:1 (Square)
0010 12:11 (625-type for 4:3 picture)
0011 10:11 (525-type for 4:3 picture)
0100 16:11 (625-type stretched for 16:9 picture)
0101 40:33 (525-type stretched for 16:9 picture)
0110-1110 Reserved
1111 extended PARpar_width: This is an 8-bit unsigned integer which indicates the horizontal size of pixel aspect ratio. A zero value is forbidden.

par_height: This is an 8-bit unsigned integer which indicates the vertical size of pixel aspect ratio. A zero value is forbidden.Any more questions? -- I'm afraid, yes... :rolleyes:

And another small piece of reference to this topic:
6.3.5.2 Video Plane with Short Header
...
source_format: This is an indication of the width and height of the rectangular video plane represented by the video_plane_with_short_header. The meaning of this field is shown in Table 6-25. Each of these source formats has the same VOP time increment resolution which is equal to 30000/1001 (approximately 29.97) Hz and the same width:height pixel aspect ratio (288/3) : (352/4), which equals 12:11 in relatively prime numbers and which defines a CIF picture as having a width:height picture aspect ratio of 4:3.

[Wilbert]

@yaz,

Since the MPEG-4 specs doesn't mention SAR (correct me if i'm wrong), isn't it more logical to call it PAR (or Pixel AR or whatever) instead of Sample AR?

[Manao]

The h264 / AVC specs only talk about SAR, and never mention PAR. So it's a tie.

[yaz]

...isn't it more logical to call it PAR (or Pixel AR or whatever) instead of Sample AR?imho, u're right. lots of application call it par, so giving a different name just increase the confusion.
The h264 / AVC specs only talk about SAR, and never mention PAR. So it's a tie. it can't be so hard. just see ligh's quotes. aren't they from the same specs u refer ?

however, not the name but the value(s) to be put here is(are) important. (and then call it whatever u want ;) )

the bests
y

[SeeMoreDigital]

The h264 / AVC specs only talk about SAR, and never mention PAR. So it's a tie.But I wonder what think their definition of think SAR means?

For all we know we might have one of those classic situations whereby the writers of one MPEG specification did not follow the meanings of the abbreviations created by the writers of former MPEG specifications.... Resulting in an confusing array of abbreviation that (of course) all look the same, but mean very different things!

For example. It's alright generating encodes at a resolution 720x576 (which I've always accepted as being the "SAR" of the encode) but whether that same encode contains any AR signalling (which I've always accepted as being "PAR" signalling) is another matter entirely!

Maybe what we need is a definitive list of all these abbreviations, with an explanation of what they mean within each MPEG specification.


Cheers

[TheBashar]

Let me apologize if these questions about zones in x264 have been asked before. I did a forum, thread, and google search and found suspiciously little information.

I would like to know if I am mistaken in believing that x264 zones lack the ability to do "start with keyframe" as in xvid. I actually use zones twice as much for marking cut/splice points than I do for bitrate reduction.

The reason I think x264 lacks this ability is because I used the zones configuration in MeGUI, but when I went to cut the resulting mkv (using mmg/mkvmerge) I was only able to cut at -2s and +4s on either side of where I had indicated a zone boundary.

I've finally resorted to encoding the video as 5(!) separate jobs using Trim()'s in the individual avs scripts. After that I adjust fix each parts timecodes for vfr, join the parts, mux the audio, and then split it back up at the join points. This way I get good splits.

Needless to say, this really complicates things.

Can someone confirm that my experience is accurate. And if I'm not making some stupid error, I'd sure like to cast my insignificant vote for adding that feature to x264 zones.

Thanks!

[Doom9]

I remember that this has come up before. But your scenario is so special that I wouldn't count on anything happening.

[Isochroma]

I just finished editing Noir ep. 1 (35089 frames processed by hand in 14 days of work). I am now encoding the final output using the newest x264 (v. 280). The file is ridiculously small (at q=20); I'm using ESA motion estimation and all the highest quality settings possible. Here is the commandline:

x264.exe --progress --qp 20 --subme 6 --ref 1 --threads 1 --filter 0:0 --keyint 250 --min-keyint 25 --scenecut 40 --qpmin 10 --qpmax 51 --qpstep 4 --direct temporal --me esa --merange 16 --bframes 15 --weightb --b-bias 0 --ipratio 1.40 --pbratio 1.30 --qcomp 0.60 --analyse all --8x8dct --progress --fps 23.97600000 --sar 32:27 -o "F:\Video Files\Noir\Encoded\Noir.01.mp4" "F:\AVISynth Scripts\Noir\MP4 Output\Noir.01.avs"

I am very impressed with the quality this codec is achieving; it could only be excelled by Ateme among all other codecs in the world right now. My AthlonXP 2500+ running single-channel DDR400 gets about 3.2-3.5 fps (no filters in the avs):

avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi")
killaudio()
converttoyv12()

The avisource() line should explain why I used killaudio()! This unusual setup is due to the fact that Vegas 6.0 starts sending corrupt frames to saved AVI files after about f4000.

So many thanks to the developers; in combination with my intensively laborious hand-editing (or rather, choosing for replacement) of video frames, the codec is a perfect match for my insistence on perfect output, in archival grade.

Tomorrow or Thursday I will be posting the link to my new site, which will explain the techniques used in this process. Particularly, delta codecs such as x264 can benefit enormously from having source frames that differ only in quantization and film-grain noise replaced by the best among a group. This zeroes whole groups of frames - sometimes quite substantial in size.

Due to the high quality of x264, it tends to preserve noise much better than MPEG-4 ASP codecs, due to more efficient bit allocation at equivalent bitrates. Thus at equivalent bitrates, the value of source noise reduction is increased by a substantial amount. Beyond the saving of bits, choosing superior frames for replicative replacement of inferior ones increases the psychovisual quality of a video stream and is a powerful tool to provide a 'free' quality boost. It is time-intensive, though; The curent project is estimated to take one year and one month to complete.

Since encoding time is less than 5% of the time to produce a finished release, I'm not concerned about slow encoding speeds. Since I've invested so much time in the other 95%+, I use the most perfect encoding settings I know of.

If anyone knows of any way to make x264 run slower but achieve higher quality, please do point out the parameters that should be changed in the commandline above. Acceptable framerate for encoding is 0.1 FPS. Thanks!

[nm]

If anyone knows of any way to make x264 run slower but achieve higher quality, please do point out the parameters that should be changed in the commandline above. Acceptable framerate for encoding is 0.1 FPS. Thanks!
How about 2- or 3-pass encoding, --ref 15, --b-pyramid and --keyint 500 (this should be tested; probably no gain and may lose seeking precision).

[LigH]

Instead of
avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi")
killaudio()
converttoyv12()
simply try
avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi", false, "YV12")
This shall speed up a little, because it does not "request and delete" unnecessary data, but instead requests only desired.

[akupenguin]

--keyint 500 (this should be tested; probably no gain and may lose seeking precision)

--keyint is just a maximum. If increasing it removes some I-frames, then you both lose seeking precision and gain compression. If not, nothing changes.

[posix]

right,
sorry to be the pestering noob but...

"x264 options explained, step by step guide"

where?

[bond]

right,
sorry to be the pestering noob but...

"x264 options explained, step by step guide"

where?
:readrule: :search: :readguid:

also what does this have to do with x264 development?

striked

[LigH]

@ posix:

Because you seem to be a German, you may want to look in the german doom9/Gleitz board for Selur's "Wissenswertes rund um x264".

http://forum.gleitz.info

[Egh]

Where to actually report possible bugs in x264?

This one is assertion exception, raised apparently in x264 whilst encoding with VirtualDub.

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

[LigH]

x264.exe does not yet have a special "encode interlaced" option, as far as I can see in the help output of rev. 284 - or did I miss an option?

[bond]

x264.exe does not yet have a special "encode interlaced" option, as far as I can see in the help output of rev. 284 - or did I miss an option?nope, x264 doesnt support interlaced encoding till now

[TheBashar]

I have a problem, and I think it's in the bowels of the code. I don't think there is any way to tackle this from x264 option tweaking. I have a couple clips where x264 seems to lose low contrast detail. And there's now way I can stop it.

I have a clip with snow falling and a camera rotation. It's a pretty busy clip. The problem is the snow gets softened into a smeared falling macroblock look. Really not nice. I've tried everything (qcomp=0.7, qcomp=0, no deblocking, lots of deblocking) and nothing works except throwing massive amounts of bitrate at it.

Now, I understand you might take a look at the clip and say, well this is really busy, 10,000 kbps might be warranted. How do I get the bitrate to it without inflating the entire movie? The majority of the movie looks great at 1400 kbps. There are some other low contrast background smears/blockyness similar to the snow, but the (high-contrast) foreground details look great.

So, without some dev help, I think I'm stuck in the water. I think my clip needs something like a negative qcomp to take bitrate from the easily compressed scenes and throw it at the problem scenes. My guess is this is a much more intrinsic problem in that the basic encoding method naturally loses low-contrast details, so x264 wouldn't even have any way of knowing there was detail there that needed more bitrate.

Here is a 14MB huffyuv avi source clip. (http://www.savefile.com/files3.php?fid=9435255)

Here is a 0.8MB 5000kbps ABR x264 MP4. (http://www.savefile.com/files3.php?fid=8421389)
Here is a 0.8MB 5000kbps no-CQM ABR x264 MP4. (http://www.savefile.com/files3.php?fid=9665839)

Here is a 0.5MB 3000kbps ABR x264 MP4. (http://www.savefile.com/files3.php?fid=8480839)
Here is a 0.5MB 3000kbps no-CQM ABR x264 MP4. (http://www.savefile.com/files3.php?fid=3282791)

The first x264 clip was made with the following command-line:
x264.exe --bitrate 5000 --keyint 300 --ref 5 --bframes 3 --b-pyramid --subme 6 --weightb --analyse all --8x8dct --qpstep 50 --qcomp 1.0 --me esa --merange 32 --cqmfile eqm_avc_hr.cfg --progress --no-psnr --output ep-2.mp4 ep-2.avs --ratetol inf

Please be sure to examine the snow falling in front of the dark parts of the volcano on the left. Hey ya know, maybe that's not snow, maybe it's ash! Damn, I'm slow!

[omion]

How do I get the bitrate to it without inflating the entire movie? The majority of the movie looks great at 1400 kbps. There are some other low contrast background smears/blockyness similar to the snow, but the (high-contrast) foreground details look great.
I'd think this would be a perfect candidate for using the --zones command. Add --zones start,end,b=5.0 to your command line and x264 will make the range of frames from start to end use 5 times the bitrate as the rest of the movie. It's sort of like curing the symptom instead of the disease, but it should work.

[SeeMoreDigital]

Where was the source from originally.... Was it a TV capture or from a DVD.... I'm wondering why your 14MB huffyuv sample is 880x480 pixels... not 720x480 pixels?


Cheers

[Pookie]

omion-Thanks for the info on the zones command. Gonna try it out on some footage with ocean scenes.

[TheBashar]

Where was the source from originally.... Was it a TV capture or from a DVD.... I'm wondering why your 14MB huffyuv sample is 880x480 pixels... not 720x480 pixels?

It's off my SG-1 (tv series) DVD collection. The size reflects the fact that I captured the "source" at the end of my postprocessing setup. I guess I should have been more clear that it was the source for the encode, not the ultimate source.

@omion:
Thanks for reminding me about the zones. It's not a good solution since in addition to easily identifiable scenes like the one I posted, there are small stretches with low contrast backgrounds that get smeared or blocky and they are scattered throughout. Not meaning to diminish your suggestion however, I will point out that while it's not a good solution, it is the best one that I have. :)

[LigH]

On the occasion of several remarkable speedups between r28x and r293, x264 now has a lightning fast new logo. Well done, bob0r - beautiful!

http://x264.nl/x264_fire.gif

[hpn]

Yes, a very nice logo. It's also a very complex one with lots of collors and shadows, so gif is not the best format (55k). It could be easily transformed losslessly to 48k PNG, so bob0r could make his site half a second faster :)

[SeeMoreDigital]

... It could be easily transformed losslessly to 48k PNG, so bob0r could make his site half a second faster :)Oh yeh....

http://img300.imageshack.us/img300/8559/x264fire95am.png

at 41.5KB PNG

[gaekwad2]

38.4KB

http://img76.imageshack.us/img76/4430/x264fire1sg.png (http://imageshack.us)

[Chaos Creator]

What Sarktooth wants to say exactly with this:

x264 win32: rev.292 - Last build until sanity comes back into ppl's mind. ???
:confused: :confused: :confused:

[LigH]

@ SMD, gaekwad2:

Which tools did you use? SMD - probably IrfanView's PNGOUT?

[Chaos Creator]

http://forum.doom9.org/showthread.php?p=711871#post711871

Ok, thanks for answering my question!! Some people really can't understand the open source philosophy!!!! :( You can't request anything!!!!

[gaekwad2]

@ SMD, gaekwad2:

Which tools did you use? SMD - probably IrfanView's PNGOUT?
I used a batch script that was posted at Hydrogenaudio a while ago, it runs advpng, pngcrush, optipng, pngrewrite and pngout (plus pngout /f0 which shaved off another 4 bytes :)).

[Audionut]

http://img355.imageshack.us/img355/5179/x264fire5fn.png

28.5kb png


http://img380.imageshack.us/img380/8624/x264fire19nl.jpg


18.1kb jpg

[hpn]

Ok, because I started this oftopic talk, lets finish it by pointing out that one can go as low as 5k with jpg or lossy PNG, but the whole idea was to make a lossless transformation and preserve the good looks of the original logo, not to make it as small as possible, so the 38.4KB version of gaekwad2 seems the smallest possible lossless GIF to PNG transformation (lossless = fully preserves the rendered RGB triples)

the facts:
http://www.cs.toronto.edu/~cosmin/pngtech/optipng.html
and the batch scripts:
http://www.hydrogenaudio.org/forums/index.php?showtopic=22036&hl=

edit: even lower than gaekwad2 losslessly to 39108 bytes:
http://img167.imageshack.us/img167/8427/x264fire9ry.png

[Antony]

Hi all,
I have revamped the VFW settings window into a smaller tabbed window. Screenshot and source code here: http://members.shaw.ca/antony.boucher/download/x264rev293_gui_patch.zip
Cheers

[sr78]

Hi All.
I am just now starting development on the x264.
I woundered if there is any good documentation I can get
in order to understand the source code better?

thanks.

[Kopernikus]

@Antony: Please send the Patch to the x264-devel mailinglist (see here http://developers.videolan.org/lists.html)

@sr78: Unfortunately there is almost no documentation for the sources. But reading the standard and the sourcecode parallel can help much. Also there is a document describing the reference encoder http://ftp3.itu.ch/av-arch/jvt-site/2005_01_HongKong/JVT-N046r1.doc, which may help in understanding.

[bob0r]

Hi all,
I have revamped the VFW settings window into a smaller tabbed window. Screenshot and source code here: http://members.shaw.ca/antony.boucher/download/x264rev293_gui_patch.zip
Cheers

Hi Antony, welcome, finally :D

Please remove my AWESOME Logo from your VFW patch, it is highly patented by me and i require a lot of money to use it.... or as most please say.... its horrible ;) ( No seriously, just add no logo, i just keep playing around with it on x264.nl )


Also, please disguss with VFW Patch with Sharktooth, he can also test them, and he makes custom builds so others can play with stuff before it gets commited to svn (or not)

His builds: http://forum.doom9.org/showthread.php?t=89979

[celtic_druid]

If anyone wants to test it:
http://mirror05.x264.nl/celtic_druid/force.php?file=./x264vfw.exe

[Sharktooth]

New 293B builds up with the antony's vfw patch released.

[dimzon]

how about target filesize instead of target bitrate option?

[bob0r]

New 293B builds up with the antony's vfw patch released.

Arg, please remove the logo, when people use Themes (antony uses Silver theme), like me, it's ugly.
Maybe if it was transparent it could be fun, but the logo is only wasting space; download and vfw window wise...

http://mirror05.x264.nl/public/antony_vfw.gif

as for the VFW file itself... testing ;)

[Sirber]

logo's pretty cool :devil:

[hpn]

Hi All.
I am just now starting development on the x264. I woundered if there is any good documentation I can get in order to understand the source code better?

thanks.
All you can do is read the comments in the source (if any). Besides the H.264 official specs (search "h264.pdf" in google), you can also buy and read the Iain Richardson book
http://www.vcodex.com/h264mpeg4/index.html

[celtic_druid]

http://mirror05.x264.nl/celtic_druid/x264vfw.png
Looks ok to me.

[leowai]

http://mirror05.x264.nl/celtic_druid/x264vfw.png
Looks ok to me.
very nice! Good job, celtic_druid.
Will it be good to change the *.ico (icon) as well?

Still, we need to get permission from bob0r. :P

[Sharktooth]

new builds up (with updated logo)

[SeeMoreDigital]

new builds up (with updated logo)Thanks Sharktooth,

Great work guys... the new GUI makes things much clearer and simpler to understand ;)


Cheers

[Koti]

very nice :)

[hpn]

The tabs look nice. One wish: Now I have to click 8 times before starting each encode to check all my settings, just to make sure I haven't changed some of the options by mistake previously. I hope it's possible to add a small "No tabs" "Tabs" botton, changing label depending on what is currently active (next to "Load Defaults" button for example), to switch between all settings on one big screen (as it was before) and the new tabbed version. Once set, people just keep using the way that suits them best.

[foxyshadis]

The tabs look nice. One wish: Now I have to click 8 times before starting each encode to check all my settings, just to make sure I haven't changed some of the options by mistake previously. I hope it's possible to add a small "No tabs" "Tabs" botton, changing label depending on what is currently active (next to "Load Defaults" button for example), to switch between all settings on one big screen (as it was before) and the new tabbed version. Once set, people just keep using the way that suits them best.
This sounds like something better solved through profiles. (Not the mutating ones in megui, just normal ones.) You reset to a saved profile, and make any tweaks from that known config.

Very nice, overall. I think more of the advanced features could be pushed into one or two tabs rather than a half-dozen, but overall it looks cleaner and slicker.

[hpn]

Ok, suppose today I create 3-4 profiles for common encoding tasks ("Save Processing Settings" in VirtualDub in my case). I don't think when in a few days before starting a 20 hours encode, I'll simply load some of these profiles, without rechecking again all options. So with or without profiles I'll always end up clicking all tabs, unless I don't mind running the 20 hours encode again if something turns out to be wrong, like loading a wrong profile name, potential bugs in VirtualDub, etc, etc. Exactly the same holds true if I encode with MeGUI. IMHO profiles are overrated. I don't say that the tabs are bad, just let people choose what suits them best :)

[foxyshadis]

Ok, suppose today I create 3-4 profiles for common encoding tasks ("Save Processing Settings" in VirtualDub in my case). I don't think when in a few days before starting a 20 hours encode, I'll simply load some of these profiles, without rechecking again all options. So with or without profiles I'll always end up clicking all tabs, unless I don't mind running the 20 hours encode again if something turns out to be wrong, like loading a wrong profile name, potential bugs in VirtualDub, etc, etc. Exactly the same holds true if I encode with MeGUI. IMHO profiles are overrated. I don't say that the tabs are bad, just let people choose what suits them best :)
They're only overrated if you actually do check/change options all the time. All I ever change is bitrate; everything else never changes depending on if I'm encoding animation/real/streaming footage because I know they're already on the best settings I've found for that type. I can understand where you're coming from though.

[stephanV]

The old GUI is still in SVN, so download that and compile it yourself. Making two GUIs in one is a bit bloated IMO. Although I do agree that the new one has a few tabs too many perhaps.

[Sirber]

is it me or rev 295 is kinda lots faster than previous builds?

encoded frames: 3529/41516 (8.5%), 29.12 fps

I was around 21 before :D

[celtic_druid]

I don't see anything that would make it quicker. Did you compiled with the mmx/mmxext patches that were posted on the mailing list?

[Sirber]

I'm on Sharktooth build. I read on the changelog some functions were optimized MMX.

MMX quantization functions, and optimization of the C versions. ...
SSE2 pixel comparison functions ...

Could be that :)

[edit]

Seems to be in "fast first pass" only. Normal encoding is ~8 FPS as usual.

[celtic_druid]

That was for r293 though.
Revision 295:
fps patch by Haali

Revision 294:
* configure: added support for ia64, mips/mipsel, m68k, arm, s390 and hppa
platforms, as well as linux sparc.

Nothing there to increase speed.

[Sirber]

my last test was with 292 IIRC.

[celtic_druid]

That would explain it.

[el divx]

very nice! Good job, celtic_druid.
Will it be good to change the *.ico (icon) as well?

Still, we need to get permission from bob0r. :P

I have changed the installer graphic and the icon. I hope you like it.

[leowai]

I have changed the installer graphic and the icon. I hope you like it.
:thanks: I'll try it later... Waiting now ;) ... => attachment is currently pending for approval. :o

If it looks better than current version, probably we should suggest the developers to committe these into the SVN. :devil:

[bob0r]

Question for the smart guys:

my x264.exe commandline:
x264 --progress --pass 1 --bframes 2 --me dia --ref 1 --subme 1 --analyse none --output NUL cap.avs
x264 --progress --pass 2 --bitrate 1000 --bframes 2 --b-pyramid --weightb --ref 3 --subme 6 --8x8dct --analyse all --output video.264 cap.avs

In VFW is there a way to "disable" bitrate for pass 1?
Or because i save cap_pass1.avi and cap_pass2.avi this is a stupid question, and VFW can't output to NUL?


As for the settings themself, profiles in VFW would be awesome, you could just save all your pass1/pass2 etc... settings, just the way you want them, good idea!

[Sharktooth]

Im already preparing a new installer script and all the stuff to commit to the SVN.
Please have some patience :)

[bob0r]

Maybe await el_divx's icon :)

[Sharktooth]

im awaiting... :P

[Antony]

Right, 8 tabs was a lot... Here is the same window with only 4 tabs :)
http://members.shaw.ca/antony.boucher/download/vfw_4_tabs.zip

[stephanV]

Looks good to me :)

[Sharktooth]

thanks. the next builds will feature the new vfw patch and some other changes in both full and lite packages.

[el divx]

All I've done is take bobor's logo(sorry for not asking you first, bobor) and use it on the default installer script as well as paste it over the old icon's logo to make it look better. You can find it all in the file I attached above.

[bob0r]

All I've done is take bobor's logo(sorry for not asking you first, bobor) and use it on the default installer script as well as paste it over the old icon's logo to make it look better. You can find it all in the file I attached above.

That's no problem, its only $500 per pixel.

Email me the file, and ill put in on http so we all can enjoy it.
Sent to el_divx [at] x264.nl (or any other random [at] x264.nl)
gmail to store all! :devil:

[Sharktooth]

New builds up. Installer script is still unchanged (had no time to update it).
Please test the VFW interface.

[foxyshadis]

Sharktooth, just curious, will your new installer script include a reg key with the last installed-to folder?

[bob0r]

I just updated my gpac (cvs up)
make clean
make

gpac\bin\gcc\libgpac_static.a copy to \MinGW\lib
gpac\include\gpac copy to \MinGW\include

svn co svn://svn.videolan.org/x264/trunk x264_test
cd x264_test
patch -p0 < x264_mp4_output_gpac_04x_update.0.diff
configure --enable-vfw --enable-avis-input --enable-mp4-output --enable-pthread

make clean
make

Error:
Creating library file: x264vfw.dll.a
make[1]: Leaving directory `/home/user/x264_test/vfw/build/cygwin'
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -DHAVE_GETOPT_LONG=1 -c -o x264.o x264.c
x264.c: In function `recompute_bitrate_mp4':
x264.c:1426: warning: dereferencing type-punned pointer will break strict-aliasing rules
x264.c:1426: warning: passing arg 1 of `gf_odf_desc_del' from incompatible pointer type
x264.c: In function `open_file_mp4':
x264.c:1471: error: too few arguments to function `gf_isom_open'
make: *** [x264.o] Error 1

Sharktooth? Superdump? Anyone else?

[SeeMoreDigital]

New builds up.... Please test the VFW interface.Just used the new VfW interface to generate two anamorphically signalled test encodes, one with 2 B-frames, one without B-frames.... Seems to work well ;)


Cheers

[celtic_druid]

@bob0r, from anyone else.

You neeed to add , NULL to the function.

p_mp4->p_file = gf_isom_open(psz_filename, GF_ISOM_OPEN_WRITE, NULL);

[leowai]

I just updated my gpac (cvs up)
:
:
Sharktooth? Superdump? Anyone else?
Me too. I believe it's because the changes in isomedia file open API in gpac on 20th Sep 2005:
Latest CVS Changes 20/09/05
- changed isomedia file open API for better support of temporary directories

It takes additional input for the mp4 creation, this need a newer patch for the mp4 support.

If you want a quick solution, back to gpac CVS on 19th Sep 2005.

@bob0r, from anyone else.

You neeed to add , NULL to the function.

p_mp4->p_file = gf_isom_open(psz_filename, GF_ISOM_OPEN_WRITE, NULL);

I'll try this first. :D Thanks.

[edit]: This works. Thanks celtic_druid. :)

[celtic_druid]

NULL sets it to the default temp dir.

[bob0r]

...
If you want a quick solution, back to gpac CVS on 19th Sep 2005.
...


Stupid question: How do i go "back to gpac CVS on 19th Sep 2005"?

And where do i find:
Latest CVS Changes 20/09/05
- changed isomedia file open API for better support of temporary directories

This changelog?

[celtic_druid]

Run cvs with -D date .

The changlog is in ./gpac/changelog

[leowai]

Stupid question: How do i go "back to gpac CVS on 19th Sep 2005"?

And where do i find:
Latest CVS Changes 20/09/05
- changed isomedia file open API for better support of temporary directories

This changelog?
Yes, changelog of gpac. Well, since you got the latest gpac, try celtic_druid's method. It works for me. :)
@bob0r, from anyone else.

You neeed to add , NULL to the function.

p_mp4->p_file = gf_isom_open(psz_filename, GF_ISOM_OPEN_WRITE, NULL);
Find the function in the patch file, add the NULL accordingly before apply the patch.

[el divx]

After applying the patch, here's what I get when the process starts building VFW:make -C vfw/build/cygwin
make[1]: Entering directory `/home/x264/vfw/build/cygwin'
D: /home/x264/vfw/build/cygwin/bin
C: ./codec.c
C:/msys/home/x264/vfw/build/cygwin/../../x264vfw.h:132: warning: 'tabs_enable_items' declared `static' but never defined
C:/msys/home/x264/vfw/build/cygwin/../../x264vfw.h:133: warning: 'tabs_update_items' declared `static' but never defined
C: ./config.c
C: ./driverproc.c
C:/msys/home/x264/vfw/build/cygwin/../../x264vfw.h:132: warning: 'tabs_enable_items' declared `static' but never defined
C:/msys/home/x264/vfw/build/cygwin/../../x264vfw.h:133: warning: 'tabs_update_items' declared `static' but never defined
W: ./resource.rc
C:/msys/home/x264/vfw/build/cygwin/../../resource.rc:10:20: afxres.h: No such file or directory
c:\mingw\bin\windres.exe: C:/msys/home/x264/vfw/build/cygwin/../../resource.rc:20: syntax error
make[1]: *** [resource.obj] Error 1
make[1]: Leaving directory `/home/x264/vfw/build/cygwin'
make: *** [x264vfw.dll] Error 2

[bob0r]

@celtic_druid
Thanks that worked

@leowai:
Thanks, what celtic_druid said indeed worked :P

@el divx
Yo, email me the installer.7z
( http://forum.doom9.org/showthread.php?p=714574#post714574 )

[Kurtnoise]

@Antony : Great stuff...:) Could you add zone options a_la_xvid ? Thanks...

[leowai]

After applying the patch, here's what I get when the process starts building VFW:
C:/msys/home/x264/vfw/build/cygwin/../../resource.rc:10:20: afxres.h: No such file or directory
Your compilation platform can't find the required file "afxres.h"! My MinGW just works out fine here. :)

Tried clean compilation?
make clean
make
If this fails, I suspect of faulty compilation platform. ;)

[el divx]

Your compilation platform can't find the required file "afxres.h"! My MinGW just works out fine here. :)

Tried clean compilation?

If this fails, I suspect of faulty compilation platform. ;)

Thanks leowai. I installed the latest version of MinGW and now it works.

[bob0r]

I have changed the installer graphic and the icon. I hope you like it.

the file: http://mirror05.x264.nl/el_divx/installer.7z

I must say, i have tried the same win.bmp as you did, i removed it, for 2 reasons, 1 its ugly when its not horizontal and 2 its adding to the filesize of the installer.

x264vfw.ico i will be using tho, thanks :)

[Sharktooth]

Sharktooth, just curious, will your new installer script include a reg key with the last installed-to folder?
Yes. It will also include the ability to choose what do you want to install (cli, vfw, megui etc.), an option to uninstall any previosly installed versions and will add a start menu link to a small app to check for new versions.

[Sharktooth]

@celtic_druid
Thanks that worked

You can find a working gpac 0.4.x patch in the x264 daily builds thread. It works with the latest gpac sources.

EDIT: Maybe some headaches could be avoided if i knew celtic druid posted the fix in the previous page... 't was my fault, though... :)

[Sirber]

rev 293 changes gives me ~10 FPS more in fast first pass and ~1.5 FPS more with all options. sweet :D

(AMD64 3000+, 1GB DDR400)

[bob0r]

@sharktooth:
Yup akupenguin/pengvado asked in the irc channel is the patch should be commited, but then i tested it, and it failed to compile :p
Now i just tried it again, and with your patch it indeed "still" works fine, so time to commit it, and start working on the --fps 29.97 .mp4 output bug :D

@el divx:
Can you please make a NSIS compatible icon for the installer(uninstaller) too?
I tried several bmp/gif to icon converters, but all failed, they remain 24 or 32bit according to windows properties.
http://www.nullsoft.com/free/nsis/makensis.htm >
Icon path_to_icon.ico "Sets the icon of the installer. The icon MUST contain a 32x32x16 color icon resource (it can also contain other icons, but they will be discarded)."
UninstallIcon path_to_icon.ico "Sets the icon of the uninstaller. Again, the icon MUST contain a 32x32x16 color icon resource (it can also contain other icons, but they will be discarded)."
Please look into it.

(Extra question, i added !define Icon "x264.ico" and !define UninstallIcon "x264.ico" to x264-conf.nsi, that should be correct right, sharktooth?)

Edit: No longer needed, thank you!

[Sharktooth]

It "should" be right. But some versions of NSIS had some bugs, so if it doesnt work check your NSIS version and eventually update it...

However the gpac patch works like a charme, it's time to submit it (and hope JLF doesnt make API changes any more...).
If you meet pengvado on irc tell him to get the patches directly from the daily builds thread. Also the VFW patch seems to work ok, so...

[bob0r]

It "should" be right. But some versions of NSIS had some bugs, so if it doesnt work check your NSIS version and eventually update it...

http://nsis.sourceforge.net/
NSIS 2.09 released - 26-08-05

It seems the icons in C:\Program Files\NSIS\Contrib\Graphics\Icons also show 32x32 with Bit Depth 32 (windows xp/properties/summary)
In fact, all is the same with my icons:
Width 32 pixels
Height 32 pixels
Horizontal Resolution 96 dpi
Vertical Resolution 96 dpi
Bit Dept 32
Frame count 1

I tried
!define ICON "C:\Program Files\NSIS\Contrib\Graphics\Icons\arrow2-install.ico"
and
!define ICON "arrow2-install.ico"

So guess what:
http://nsis.sourceforge.net/Docs/Modern%20UI/Readme.html >
"
Important: Because the Modern UI has its own macro system, its own default settings and a lot of new features, the interface configuration works differently. So you should not use commands like LicenseText, Icon, CheckBitmap, InstallColors etc.
"

MUI_ICON icon_file
The icon for the installer.
Default: ${NSISDIR}\Contrib\Graphics\Icons\modern-install.ico

MUI_UNICON icon_file
The icon for the uninstaller.
Default: ${NSISDIR}\Contrib\Graphics\Icons\modern-uninstall.ico

I forgot we used MUI again, problem solved! :D ;) :o

[Sharktooth]

MUI_ prefix should be used if you use the Modern UI. Some standard NSIS commands are replaced by MUI versions and won't work with MUI unless you use the specific MUI replacements.
However MUI should be integrated in the next major NSIS version.

[hpn]

Congratulations on rev. 300 :)

The 4 tabs are beautiful. And to make everything perfect I think the second and third tabs
("Rate Control" and "I/P/B/Frames") should switch places, cause the Rate control options
are less likely to be changed with each encode (I usually don't touch them) than some of the
options on the third tab.

http://img343.imageshack.us/img343/8701/x2643000rt.png

[virus]

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

[akupenguin]

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.

[Kostarum Rex Persia]

But why Sharktooth removed all patches from rev. 300??? I think that is bad idea,because some of the patch was worked very good job in increase of speed and quality of x264 codec.

Sharktooth,can you,please,put these patches in build 301 or 302.I mean mainly on Johannes Reinhardt patch for Intra prediction mode,and,of course,Christian Heine new MMXEXT SATD functions that are slightly
faster than the original ones on Athlon XP and another his patch.

I put these patches as attacments.It's shame if these very good patches won't be included in future builds.

So,I need opinion of you,guys.What do you think,is these patches deserve to find place in futute revisions of x264?

[Kostarum Rex Persia]

Another question,from where I can directly download pengvado builds of x264.I am subscribed to x264 development from http://developers.videolan.org/lists.html ,but in the emails,I never get the download link for the newest builds.

[berrinam]

But why Sharktooth removed all patches from rev. 300??? I think that is bad idea,because some of the patch was worked very good job in increase of speed and quality of x264 codec.Can you not read? From Sharktooth's sticky, the Build Changes section says quite clearly:
(r300) Removed all patches, they were all finalized and submitted to the SVN repository. Updated GPAC sources.
I think that clears it all up, doesn't it? There is a reason for forum rule 1.

Another question,from where I can directly download pengvado builds of x264.I am subscribed to x264 development from http://developers.videolan.org/lists.html ,but in the emails,I never get the download link for the newest builds.
What are you talking about? There are no 'pengvado builds'. The newest builds can be found on Sharktooth's sticky.

[omion]

Umm... The changelog indicates that the patches were removed because they were merged with the x264 code. There's no point in applying the patches since it's now in the trunk source.

[edit: Oops. berrinam beat me to it]

[Kostarum Rex Persia]

Omion,are you sure that that patches now in the trunk source? Can anyone confirm it?

[berrinam]

@Kostarum Rex Persia: I quoted Sharktooth's sticky, where he said that the patches are now committed. Do you really think he would lie about that? For further proof, see the changelog (https://trac.videolan.org/x264/log/trunk/), which is also linked to from Sharktooth's sticky. There is no need to fear that the progress on x264 would go backwards. The developers are not stupid.

[omion]

Omion,are you sure that that patches now in the trunk source?I don't know what those patches were, exactly, but if they looked anything like this (https://trac.videolan.org/x264/changeset/296), this (https://trac.videolan.org/x264/changeset/297), or this (https://trac.videolan.org/x264/changeset/298), then there's no need to worry. (I do notice that the first one is by Johannes Reinhardt and the other two by Christian Heine, just as the ones you described...)

Can anyone confirm it?Yes... YOU can! The source is free and open on the internet. It took me 2 clicks to get to the links above from the x264 sticky.

I think you're being a bit too paranoid about the whole thing... If patches work, then they get committed. If they break, then they don't. As berrinam says, there's no need for anybody to lie about it... :rolleyes:

[Sharktooth]

But why Sharktooth removed all patches from rev. 300??? I think that is bad idea,because some of the patch was worked very good job in increase of speed and quality of x264 codec.

Sharktooth,can you,please,put these patches in build 301 or 302.I mean mainly on Johannes Reinhardt patch for Intra prediction mode,and,of course,Christian Heine new MMXEXT SATD functions that are slightly
faster than the original ones on Athlon XP and another his patch.

I put these patches as attacments.It's shame if these very good patches won't be included in future builds.

So,I need opinion of you,guys.What do you think,is these patches deserve to find place in futute revisions of x264?
I hope that's a joke....
Another question,from where I can directly download pengvado builds of x264.I am subscribed to x264 development from http://developers.videolan.org/lists.html ,but in the emails,I never get the download link for the newest builds.
still joking?

[Kostarum Rex Persia]

I am sorry,Sharktooth,I didn't read carefuly your sticky.Can you forgive me?

[Sharktooth]

sure ;)

[Kostarum Rex Persia]

btw,I read on the x264 mailing lists that " In its current
state, x264 is already quite efficient. Don't expect outstanding quality
boost in the near future ( a fair boost would be 0.3 dB, which I think
can be reached, and which represents roughly a 6% bitrate saving with
the same quality ). Now it's up to you to see how much time you can wait.

Feature-wise, AlexI is working on adding interlacing support to x264,
so, of course, if your streams are interlacing, I'd advise to wait. In
any other case, I'd encode right away ( you can't wait indefinitely ),
but you might think otherwise." (quote from Mathieu Monnier)

That's sounds very promising,I hope that interlace support will be ready in the next 3-4 months.

[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 ... ???

[Sharktooth]

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

[Manao]

afaik, it doesn't use adaptive quantization.

[giandrea]

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]

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]

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

[Sharktooth]

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]

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

[Manao]

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

[JnZ]

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]

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]

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]

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

[el divx]

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]

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]

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

[squid_80]

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]

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]

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]

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]

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]

thank a lot :)

[giandrea]

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

[QuadraQ]

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]

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]

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]

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]

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

[sr78]

Does the x264 support the FMO feature?

[foxyshadis]

This just came up a few days ago.

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

Answer: No.

[Sharktooth]

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]

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]

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]

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]

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]

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]

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]

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

[Sagittaire]

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]

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]

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

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]

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

[squid_80]

Zeroes it is then. :cool:

[sr78]

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]

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]

@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.i assume you have a vfw decoder for hfyu installed?

[sr78]

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

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.
As bond said, are you sure you have a huffyuv VFW decoder? Coz x264 accepts only yv12...

[Kopernikus]

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

[sr78]

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

[sr78]

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

thank you both for your help

[Richard Berg]

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]

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]

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.

[bond]

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]

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]

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]

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.
Shouldn't be a problem for most people, just make an avs script with avisource and converttoyv12 (if needed).

[ChronoCross]

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]

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]

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]

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 )

so cabac also compresses the reference info for each macroblock along with the transformed quant coefficients? good to know. Thanks for the quick answer.

[akupenguin]

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]

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]

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]

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

[sr78]

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

thanks

[bond]

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]

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]

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]

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

[Sharktooth]

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]

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

[gino25]

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

[nm]

http://gpac.sourceforge.net/

[bond]

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]

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]

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]

any update for vfw?

[bond]

any update for vfw?whats that? :p

[falcon2000eg]

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]

I agree.Updated vfw is very good idea.

[CiNcH]

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]

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]

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]

Tommy Carrot
:thanks: :goodpost:

[celtic_druid]

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]

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.

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.

[redfordxx]

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]

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]

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]

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]

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]

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]

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.

[Sagittaire]

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]

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

[Sirber]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Tommy Carrot]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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

[puffpio]

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

[CREXbzh]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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

[Revgen]

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

[charleski]

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]

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

Very strange. :confused:

[Wilbert]

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

[Revgen]

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

[nDman]

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.


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.

[Revgen]

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]

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]

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]

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]

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]

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

[Doom9]

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

[nDman]

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]

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.

[akupenguin]

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]

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

thanks for info :)

[puffpio]

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

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

[rig_veda]

is your hard drive formatted with the NTFS file system?

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

[Hyper Shinchan]

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

[Doom9]

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

[charleski]

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

[Hyper Shinchan]

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

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

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

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

[Doom9]

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

[Doom9]

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

[redfordxx]

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

[Doom9]

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

[redfordxx]

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

Of course I know, it is cosmetics.

[LigH]

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

[redfordxx]

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

[Doom9]

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

[redfordxx]

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

[charleski]

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

[IgorC]

I have a bug with AQ here.

Source. Matrix 2. Progressive 23.98 fps. Chapter 20

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

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

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



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

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

[Sharktooth]

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

[IgorC]

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

[Sharktooth]

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

[charleski]

Colour Coefficients

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

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

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

[Sharktooth]

it's not about color, but artifacts.

[puffpio]

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

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

I'll give this a whirl

[puffpio]

Colour Coefficients

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

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

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

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

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

[charleski]

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

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

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

[ChronoCross]

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

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

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


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

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

For example:

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

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

[berrinam]

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

[Tima]

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

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

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

Expression: pic->data[0]

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

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


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

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

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

[Sirber]

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

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

[Manao]

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

[squid_80]

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

[Sirber]

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

[squid_80]

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

[Sirber]

in this 75 pages thread? ;)

ok thanks :D

[molinacabaleiro]

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

[redfordxx]

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

[bond]

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

[redfordxx]

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

[bond]

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

[redfordxx]

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

[DarkFoon]

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

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

[Selur]

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

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

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

Cu Selur

[charleski]

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

[Selur]

Ok, thx for the info. :)

Cu Selur

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

[redfordxx]

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

[akupenguin]

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

[Marsu42]

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

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

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

[Sharktooth]

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

[akupenguin]

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

[Manao]

Actually, Ateme codec has an option to encode at x.xx times the realtime speed. It works roughly as akupenguin described, and that does the job very well.

[Marsu42]

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

Constant fps should do ok for my purpose, too, but I guess when encoding a dvd through an avs script x264 is the bottleneck, so the encoding buffer would be alway full and the lowest quality options would be locked in? Therefore, it would be nice - if possible - to have this --fps switch which tells x264 when to reduce quality and gain speed as an alternative to measurement of the buffer.

[akupenguin]

The speed option would control how fast input frames are copied into the buffer.

[mgh]

The latest profiles do not have adaptive quantization?

[unmei]

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all" :)

[Yong]

Ive noticed this problem sometime already(XviD have the same problem too)...
the video look flashy with some blockiness when it fade-out(white to black).

Here is the link for the part of x264(rev389 with AQ, subme7.. patch applied) encoded video snapshot(png):
http://rapidshare.de/files/9978648/x264-Snapshot.7z.html
i can upload the full x264 encoded if someone really need to watch it :rolleyes:
Here is the link to original source:
http://www.sp-janis.com/download/heaven_anime.mpg

Please correct me if im wrong, here is the x264 options i used:
start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 3 -r 1 -f -6:-6 -A none -w -m 1 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress --b-pyramid
start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 3 -r 5 -f -6:-6 -A all -m 7 -w --chroma-qp-offset 2 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress --b-pyramid --me umh -8 --mixed-refs -t 2 --aq-strength 1.1 --aq-sensitivity 15 --b-rdo

Now im tring to encode with higher bitrate see the problem solved or not :p

[nm]

The answer is right above your post: try --no-fast-pskip instead of AQ.

[Yong]

The answer is right above your post: try --no-fast-pskip instead of AQ.
Nope, the problem still persist after i removed aq options and add --no-fast-pskip. :eek:
But the flashy and blockiness reduced alot @ 600kbps :rolleyes:

[nm]

You have set the deblocking parameters to very low values. That probably causes blocking at low bitrates, so it's better to try the default values (0) first.

By the way, there are also thin black borders left in your sample images. It is better to crop the borders entirely if you aim for maximal quality.

[Yong]

You have set the deblocking parameters to very low values. That probably causes blocking at low bitrates, so it's better to try the default values (0) first.

By the way, there are also thin black borders left in your sample images. It is better to crop the borders entirely if you aim for maximal quality.

The blockiness and flashy problem still there even set loop filter alpha:beta to 6:6...

and the source is 640x480 and the x264 encoded was cropped with .Crop(0,56,-0,-56), =640x368, no more black borders already :)

[nm]

and the source is 640x480 and the x264 encoded was cropped with .Crop(0,56,-0,-56), =640x368, no more black borders already :)
There is a 1-pixel dark line on top even if you crop with (0,64,-0,-64) so for "best" results you'll need to crop 15 lines of actual image with (0,72,-0,72).

[Yong]

There is a 1-pixel dark line on top even if you crop with (0,64,-0,-64) so for "best" results you'll need to crop 15 lines of actual image with (0,72,-0,72).
The problems still there even i cropped the video clips with (0,72,0,-72)....
May be im not suppose to encode video clips at such low bitrate :p

[foxyshadis]

Have you tried removing b-frames? For extremely low bitrates they're not really a good idea, and in fact, deaththesheep had a few other suggestions in his quality guide.

[Yong]

Have you tried removing b-frames? For extremely low bitrates they're not really a good idea, and in fact, deaththesheep had a few other suggestions in his quality guide.
Just now i finished the encoding with this options:

start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 0 -r 1 -A none -w -m 1 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress --no-fast-pskip
start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 0 -r 5 -f -w -m 7 --me umh -t 2 --chroma-qp-offset 2 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress --no-fast-pskip --mixed-refs
I still couldnt get rid those flashy and blocky problem...

forgot to mention, the video snapshot i uploaded all are p-frames.

Here is the link to download the splitted mkv:
http://www.geocities.com/y0ngc/heaven_anime-002.zip
(thnks for someone reminds me that MKVtoolnix have splitting function :p )

[bond]

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all" :)fastpskip has been changed too, so it doesnt show the blue blocks problem anymore

[redfordxx]

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all" :)Does it mean, that once using --no-fast-pskip option, some AQ settings couldn't add any quality at all?

[bond]

Does it mean, that once using --no-fast-pskip option, some AQ settings couldn't add any quality at all?no, "some" AQ can still add quality, but not the AQ that has been tested till now

so to say there were two fixes for the blue blocks problem:
1) the AQ patch from haali
2) a tuned fastpskip

as solution 2) was chosen, so there is no need for 1) anymore

[nm]

I tried Yong's source with the default (tuned) fastpskip, and there is annoying flicker and blocking in the end. 256 kbps is a low bitrate, so edges are not so sharp anymore, but the blocking is generally stationary and not so annoying elsewhere in the clip. The slow fade seems to trigger it.

[squid_80]

Does anyone have any idea how to extend x264.c to print the avisynth error when it fails to open a script? I got it to work but unfortunately it only works by compiling as c++ rather than c and I'd prefer not to do that.

[redfordxx]

I've been doing 1sp pass now and the power supply failed. Some precious encoding time already behind, so I continue with --seek option (with 1000 frames overlap). Then will I join the stat files. I will have to renumber the second stats file because x264 starts numbering the frames from zero again.

Wouldn't it be useful to keep original frame numbers?


BTW: Capital 'I' is the IDR frame in stats file - that's where I can join it, correct?
When on the topic already: is somewhere the stats file syntax description to find?

[LigH]

I have a little annoyance with Sharktooth's download link - not x264 related, more MIME/client behaviour:

When I click on the link for a download (e.g. http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r395.exe at the moment), Opera detects the file type "application/force-download" and wants to save the file as "x264-Std_r395.force-download".

Any ideas how I could convince Opera to use the submitted filename, not a constructed one? In previous versions, there was an option to toggle between "trust MIME type" and "guess by extension", but this does not exist anymore in the options dialog - and I'm not even sure if it would help here. I probably have to edit some config file instead, I'm afraid...

[bob0r]

Change http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r395.exe to

http://files.x264.nl/Sharktooth/x264-Std_r395.exe and it should work.

[virus]

@LigH:
I don't have such a problem when clicking the force.php link in your post. Opera (version 8.5-Win32) shows me type "application/force-download" as you, but when I choose "Save" the filename is simply "x264-Std_r395.exe".

Don't ask me why this happens for you, though. Maybe you can search/ask at the forums over at opera.com - maybe some mess in the config files (did you upgraded from, say, version 7 or older or is it a clean 8.x install?) or perhaps you unintentionally changed something in Tools->Preferences->Advanced tab->Downloads?

[LigH]

It was an update.

And I wonder what I could "mess up"... I just changed the settings from "Show download dialog" to "Save to disk" (or similar, I'm using the german language file).

But meanwhile, x264-Std_r395.exe does not exist anymore - boy, Sharktooth is fast!

http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r396A.exe

[Dayvon]

Just a quick note to you x264 developers and supporters.

You guys have done awesome work bringing the most cutting edge technology to the public. Keep up the great work. Loving your creations.

Dave

[CEC]

Is there any updated guide with all the new x264 features? The one i found in doom9 is old!

[LigH]

If you can read german - Selur's x264 documentations are usually quite up to date.

x264 VfW (http://www.flaskmpeg.info/board/thread.php?postid=54931) / x264 CLI (http://www.flaskmpeg.info/board/thread.php?threadid=5571)

[CEC]

If you can read german - Selur's x264 documentations are usually quite up to date.

x264 VfW (http://www.flaskmpeg.info/board/thread.php?postid=54931) / x264 CLI (http://www.flaskmpeg.info/board/thread.php?threadid=5571)

I can't understand anything!:eek:
But thanks anyway!:)

[LigH]

So what is your preferred language?

And what is the CEC, a software for creating computer aided art?

[DeathTheSheep]

<> Bi-directional ME
<> DCT-domain NR

2 new badboys that haven't been touched upon yet ;)

and....
http://www.myfilehut.com/userfiles/5120/untitled.PNG

[Piper]

I just want to echo other comments of praise for those developing x264. I've been playing with x264 ever since seeing the recent Codec shoot-out 2005 - final (http://www.doom9.org/codecs-final-105-1.htm#intro) and I'm astonished with what this codec is capable of. Thanks for all your continued hard work on this project!!

[Marsu42]

I've been playing with x264 ever since seeing the recent Codec shoot-out 2005 - final and I'm astonished with what this codec is capable of.

While being an absolutely convinced x264 user, I have to admit I don't quite understand how the ateme codec could have lost the competition because x264 shows some annoying washed blocks I have been experiencing in my own encodes, too: Take e.g. the "Scene 7: Neo faces Agent Smith" and look at the rain in middle and right of the picture. Is it just me or does the encode really look blurred? I am wondering if this is a bug or just unlucky rate control during exactly this scene?

[foxyshadis]

Do you mean the capture, or did you get ahold of (or replicate) the encode of the full scene? Doom9 specifically says do not study captures too closely, because they don't accurately reflect how the encode fared while being watched closely. It might be a B-frame in one encode and an I in another.

It's somewhere in his faq.

[Marsu42]

Do you mean the capture, or did you get ahold of (or replicate) the encode of the full scene?
I just looked at the capture, but it strikingly reminded my of the phenomenon I exprerienced w/ my own encodes - sometimes, the background tends to be very blurred. Of course, It were lower bitrate encodes (~900-1000) and I might have chosen bad filter settings, but in comparison to XviD, I was still surprised. On the other hand, maybe it's due to XviD's tendency to "restore" detail as described in Doom9's test and perfectly normal behavior for any other codec.

[max-holz]

I just looked at the capture, but it strikingly reminded my of the phenomenon I exprerienced w/ my own encodes - sometimes, the background tends to be very blurred. Of course, It were lower bitrate encodes (~900-1000) and I might have chosen bad filter settings, but in comparison to XviD, I was still surprised. On the other hand, maybe it's due to XviD's tendency to "restore" detail as described in Doom9's test and perfectly normal behavior for any other codec.

Simply use --no-fast-pskip for me the best solution.

[DarkFoon]

I've experienced a wierd X264 "bug" you might say.
In animated encodes, when something moves very fast (and this is the only thing I could notice that might have an effect) a white block appears in its former place for a moment. It doesn't even do this for all fast motion parts.
I'd love to post some screen shots, but I don't know of a convenient image hosting service. (any reccomendations?)
A picture is worth a thousand words, and I have a few thousand to show, but no way to do it.

[bob0r]

@DarkFoon
You may send files to files@x264.nl and ill host them for you.
(Please be sure to give a link to the right forum thread also, so i know where to add a reply with the file(s), this is more a general message for others)

Edit:
BTW, paste your command line used (or screenshot of settings used in gui, if not megui (show commandline)
Also what x264 version did you use? sharktooth's? x264.nl's other?... info info info)!

[DarkFoon]

Well, I'm going to take those screne shots now and email them.

unfortunately, I did the projects over a month ago, and I have since forgotten the commandline. I used one of sharktooth's builds, probably around 375.
I should try to re-encode the source (I may have lost it ) with a more recent build to see if the problem is still there.

and lastly, (but not the least) Thanks bob0r for hosting these files!

[omion]

In animated encodes, when something moves very fast (and this is the only thing I could notice that might have an effect) a white block appears in its former place for a moment. It doesn't even do this for all fast motion parts.
I'd love to post some screen shots, but I don't know of a convenient image hosting service. (any reccomendations?)
Does it look anything like the first picture on this thread (http://forum.doom9.org/showthread.php?p=766051)? It came out right after somebody walked past the frame, and I think it may be related. For me, all of Sharktooth's builds from 379 do it, but I'm still not sure what it is.

[edit: I guess I'll find out when the screenshots are posted. I really need to read posts when I quote them...:rolleyes:]

[DarkFoon]

@ Omion,
yeah sorta like that, but a little different.
Here are my screenshots:
Example 1 - Frame 1 (http://files.x264.nl/DarkFoon/example1-1.png)
Example 1 - Frame 2 (http://files.x264.nl/DarkFoon/example1-2.png)
Example 1 - Frame 3 (http://files.x264.nl/DarkFoon/example1-3.png)

Example 2 - Frame 1 (http://files.x264.nl/DarkFoon/example2-1.png)
Example 2 - Frame 2 (http://files.x264.nl/DarkFoon/example2-2.png)
Example 2 - Frame 3 (http://files.x264.nl/DarkFoon/example2-3.png)

In example 2, that half of the frame is supposed to be white (its a camera 'flash') the bad part is the little black block in the top left of that white area.

Example 1, his hand was next to his head, and then he moved it quickly away, and well, you can see the picture.

These screenshots aren't superb, and I apologize for that. Directshowsource() doesn't really allow frame-accurate seeking. and VLC player doesn't pause when I tell it to.

@Omion (again)
The only time I saw that effect as bad as those images you showed me was when I used FFDshow's X264 almost a year ago to encode a test clip, and all motion in that clip had that effect.

[lspbeyond]

hi, everybody, I have a question about x264 decoder.
I know ffmpeg-libavcodec is the first choice in decoding x264 streams currently and it works well. However, how about your opinions in developing own decoder in x264 project?

[CREXbzh]

However, how about your opinions in developing own decoder in x264 project?

I think patches to improve/fix the decoder will certainly be considered for inclusion; however, don't expect too much enthousiasm to help you as the code team of x264 already maintains part of ffmpeg h264 decoder, and probably doesn't feel like duplicating efforts (to work on x264 own decoder).

[bond]

hi, everybody, I have a question about x264 decoder.
I know ffmpeg-libavcodec is the first choice in decoding x264 streams currently and it works well. However, how about your opinions in developing own decoder in x264 project?man, its time for you to :search:

1) the question about the x264 decoder is as old as x264 itself. basically one point of an open standard, like avc, is that you can use any avc decoder you want for decoding an avc stream. this means there is absolutely no need for a x264 decoder
2) the fastest decoder supporting as good as all available avc features and still being freely available is coreavc (http://forum.doom9.org/showthread.php?t=104277)

[lspbeyond]

Thanks CREXbzh and bond, I have learned very more.
But I also have three different opinions?
1. we know encoder include the reconstruction loop, it has already implemented mostly part of decoder, expect stream parsing and entropy decoding . So I think develop decoder in x264 project is not a hard work.
2. The decoder can share the improvement of x264 encoder directly, e.g. the mc function, dct, deblock ... are all common.
3. If somebody have been familar with x264 encoder, they can learn the decoder part quickly. IMO, if x264 has more things be needed to do, then there will be more people join in developing it.

[akupenguin]

1. Reconstruction != construction. While it would be mostly cut-and-paste, it's not as simple as calling the existing code.
2. The optimal way of coding mc and deblock are not the same between encoder and decoder.
3. Do I hear you volunteering?

[lspbeyond]

to akupenguin, thank u
1. I don't think so. I think the mc, deblock and etc functions can called without any modification.
2. I am interesting in this point very much. If you can tell me in detail, I will appreciate of you. Thank u very much.
3. Though I'm a fresh man in video coding area, if I can do my little contribution to x264 project, I will.

[akupenguin]

I'll describe mc, because it's the most different:

x264 has one function that performs all 3 halfpel interpolations on the whole frame (note that the computation of the center halfpel includes one of the other positions, so we get one for free). Thus we have 4 versions of the luma plane. We also mc enough pixels past the edge of the frame to deal with unlimited mvs, and a bit more to simplify motion estimation.
Thereafter, any fullpel or halfpel-aligned mv can be retrieved with only pointer math, no pixel operations. And the remaining qpel mvs require just a PAVGB operation. Since the encoder tests many mvs, this is a big win.

But when decoding, that would be slow. Each pixel only involves 1 mv (or up to 2 in B-frames), and it's quite often the 0,0 mv that doesn't need any interpolation, and then there's intra... So we don't want to compute all 3 halfpels everywhere. Furthermore, we'd need to not only break even in terms of pixel operations, but get over the fact that the extra planes increase cache pressure.
So the optimal mc method for decoding is to have functions which do halfpel and qpel mc just on one block, for each of the 7 block sizes.
And (I haven't benchmarked this, but michaelni says so) instead of padding the edges of the frames enough to account for all concievable mvs, it's better to pad only a little bit, and then copy the rest of the pixels on demand.

--
If you are interested in writing the decoder, I would be happy to answer any technical questions you have. (well, I answer stuff anyway, but potential contributors get first pick.)

[lspbeyond]

very good.
I have thought of this problem of mc.
And I have bethought of the method that interpolating the pixels when used. But I am uncertain if the overlap case (i mean the repeated interpolation of a pixel) is frequent or not.

ps: I used intel vtune analysing the t264 decoder, and I found the memset function cost a big proportion. I know mostly video encoder or decoder program have used this function frequently, is there any faster fuction can instead of it?

[Manao]

But I am uncertain if the overlap case (i mean the repeated interpolation of a pixel) is frequent or not.On the encoder side - definitely. A rough guesstimate of the number of subpel positions analysed would be around 20 per macroblock. On these interpolated positions, qpel are computed using 2 hpels, and represents ~12 ( second guesstimate ). So in the end, for each macroblocks, you end up doing 8 + 12 + 12 hpel interpolations. So it's definitely worth it to do it once and for all, especially if you think that a reference frame may serve more than once ( bframes, multiref ).

On the decoder side - definitely not, since 1 macroblock = 1 or 2 hpel interpolations at most, so doing the 3 hpels for the whole picture make you lose time ( not speaking of the cache miss increase ).

[Selur]

dump,.. asked this before but nobody answered:
What are the min/max values for aq-sensitivity and aq-strength ?

Cu Selur

[dimzon]

to all x264 developers:
please take look at this post:
http://forum.doom9.org/showthread.php?p=774869#post774869

Thanx!

[Manao]

x264 opens avs scripts through the vfw interface, so it doesn't work.

[dimzon]

x264 opens avs scripts through the vfw interface, so it doesn't work.
ok, thanx!

[Isochroma]

Is it possible for x264 to support encoding to 4:2:2 (YUY2) & 4:4:4 colorspaces? I know it's probably impossible to do RGB24, but some research this morning turned up support for the above two colorspaces in High profile extended fidelity extensions. Since x264 already supports at least one of the extensions (lossless), perhaps it could support more?

[akupenguin]

What makes you think RGB is any less possible than 4:4:4 ?

[Isochroma]

You may be correct (see below). Previously, I had assumed RGB wasn't supportable in any MPEG-4 standard because both 4:4:4 and 4:2:2 are mentioned as supported in the High profile extended fidelity extensions, but no RGB is ever mentioned for any MPEG stream - at least, I'd never heard of such a thing. Also, MPEG-2 supports 4:4:4 in High Profile.

From http://en.wikipedia.org/wiki/H.264:

"The JVT recently completed the development of some extensions to the original standard that are known as the Fidelity Range Extensions (FRExt). These extensions support higher-fidelity video coding by supporting increased sample accuracy (including 10-bit and 12-bit coding) and higher-resolution color information (including sampling structures known as YUV 4:2:2 and YUV 4:4:4). Several other features are also included in the Fidelity Range Extensions project (such as adaptive switching between 4×4 and 8×8 integer transforms, encoder-specified perceptual-based quantization weighting matrices, efficient inter-picture lossless coding, support of additional color spaces, and a residual color transform)."

[foxyshadis]

Dizmon is requesting input colorspace conversion, though, not direct storage of RGB or YUY2. :p

[Isochroma]

There's more than one way to cut a pie... x264 having more colorspace modes would solve his problem and simultaneously help preserve the quality of video much better than it currently can be - also giving it a significant advantage over other YV12-limited AVC and ASP codecs. I think that with the advanced compression capabilities of h.264 in general, and this implementation in particular, the extra input data should be of little concern.

The opportunities for very 'cheap' quality improvement and the widening of x264's scope to include professional archiving requirements (as has already been started by the introduction of one FREXT - lossless mode) should not be overlooked. Even 4:2:2 provides much better color sampling than 4:2:0 (I can see the chroma blocking due to YV12 between source and encoded frames with lossless mode).

I see at least the YUV 4:4:4 and 4:2:2 modes as mere extensions of the direction x264 is already moving in, and probably easy to implement. It seems RGB might be more difficult due to the different way colors are represented.

Also, the differences between 4:4:4 and RGB are bound to be almost indiscernably small (if any) so RGB support should probably be on the back-burner while YUY might be a higher priority.

[Manao]

Isochroma : most people only handle 4:2:0 material, so there's little use right now for support of the other colorspaces ( that falls into the scope "you need it, you code it" ).

[Isochroma]

They may start with 4:2:0 material, but many avisynth filters output yuy2 and some even rgb data. Having to downsample the chroma after processing is a disadvantage for certain. For example, I'm using two denoisers in sequence (fft3d and neat image) to process video. FFT3d gets fed YUY2 data from a resizer earlier in the filterchain, and outputs the same (I think). Neat Image takes the output (converted to RGB24 by the Imagewriter() plugin) and produces really nice 48-bit TIFFs which then get downsampled to 24-bit PNGs by Irfanview thru commandline interface. Chroma blocking is easily distinguished on output frames compressed in YV12 from the original, even losslessly.

In industry, 4:2:2 is considered just barely good enough for pro work, and 4:1:1 and 4:2:0 are used as capture and output only, respectively. DV50 is certainly superior to DV25, especially for multigeneration work. Also, it seems likely that avisynth 3.0 will support 4:4:4, which will give users yet another path to a better product; it may even support >8-bit per channel color!

It is my hope that all filters and codecs which only run in YUV colorspace will support 4:4:4, or at least 4:2:2, someday. When a complete non-downsampled path exists from source to finished product, these tools will be considered to have reached the pinnacle of their capabilities.

It will give professionals in NLE studios and others in industry even more reasons to incorporate the great works of open-source and free development into their workflow. In output compressors, (excluding lossless edit & storage types) the commercial products seem to include only 4:2:0, excepting Windows Media 9, which can do all of them (!). It seems a fertile field for independent innovators to make inroads...

[Manao]

Starting from a 4:2:0 video and wanting to encode it in 4:4:4 is dumb ( except if you use a filter that properly interpolate chroma, which you don't, since there's none ). If your input is really 4:4:4, it's another matter, but unless you're doing CGI animation, it won't be 4:4:4

It will give professionals in NLE studios and others in industry even more reasons to incorporate the great works of open-source and free development into their workflowNot at all. They'll never use x264, because they'll never go the open source way.

[Episodio1]

SW: III and SIN CITY were filmed with Sony HDC-F950 and HDC-950 respectively (4:4:4)
http://us.imdb.com/title/tt0121766/technical


I guess Sin City doesnt take advantage at all, as it is B&W and heavy filtered. xD

[Manao]

I doubt you have access to the 4:4:4 material for these movies anyway :p

You only have access to the DVDs ( 4:2:0 ), and HDTV ( 4:2:0, perhaps 4:2:2 sometimes, but I doubt it )

[Wilbert]

Also, it seems likely that avisynth 3.0 will support 4:4:4, which will give users yet another path to a better product; it may even support >8-bit per channel color!
Many filters in avs v2.60 are already working in YUV 4:4:4 (8 bit) :)

[Raptus]

It seems CLI x264 is less anal with levels than MeGUI is. For instance, while MeGUI won't let me use level 3 together with P4x4 x264 doesn't even issue a warning. Oversight or feature? In such cases where contradictory params are used, will x264 enforce or ignore levels?

On a sidenote, I'd appreciate if someone had a link to a detailed list of the different AVC level constraints. (I can't find the damn h.264 doc where they supposedly are specified in Appendix A. Best I dug up so far was: http://www.cdt.luth.se/~peppar/kurs/smd151/spie04-h264OverviewPaper.pdf )

[CruNcher]

Raptus also my problem with level 4 reading the level specs shows it should be fine so i force it on cmd no problem just lets wait for Standalones then we'll see whats correct :P

[Doom9]

For instance, while MeGUI won't let me use level 3 together with P4x4 x264 doesn't even issue a warning. Oversight or feature? In such cases where contradictory params are used, will x264 enforce or ignore levels?The level tag only flags the level in the resulting stream.. it does not actually limit the encoder to a certain level.

As far as the level constraints go, they are in this very forum.. I don't recall thread urls by heart but I know they're there since it's what I used to enforce levels in MeGUI (along with aku's help.. the P4x4 limitation was added after he suggested that it was required).

[Kostarum Rex Persia]

New build came out, data is below:

r429 | pengvado | 2006-02-10 22:58:43 +0100 (Fri, 10 Feb 2006) | 3 lines
Changed paths:
M /trunk/Makefile
M /trunk/common/amd64/predict-a.asm
D /trunk/common/amd64/predict.c
M /trunk/common/i386/predict-a.asm
M /trunk/common/i386/predict.c

amd64 mmx for some intra pred functions

So, I suppose that amd64 mmx predictions will speed-up encoding on Athlon 64 based computers, am I right. Sorry if I don't understand this very well, but I am not a programmer.

Can x264 32-bit version, now work without problems on Windows XP 64-bit edition?

[bob0r]

Kostarum Rex Persia will be happy:

VFW updated:
r430(and r431)
VfW: support trellis, brdo, nr, bime.
patch by Dan Nelson (dnelson at allantgroup dot com).

So About the missing option in the x264 VfW (http://forum.doom9.org/showthread.php?t=105899) can be updated , not in VFW:

- Constant quality mode
- Fast P-Skip
- Custom quantization matrices
- Buffer control
- Zones
- AQ (only available in Sharktooth's build, not an official x264 feature at this point)

[LoRd_MuldeR]

Kostarum Rex Persia will be happy:

VFW updated:
r430(and r431)
VfW: support trellis, brdo, nr, bime.
patch by Dan Nelson (dnelson at allantgroup dot com).

So About the missing option in the x264 VfW (http://forum.doom9.org/showthread.php?t=105899) can be updated , not in VFW:

- Constant quality mode
- Fast P-Skip
- Custom quantization matrices
- Buffer control
- Zones
- AQ (only available in Sharktooth's build, not an official x264 feature at this point)


Yeah! X-Mas and Easter on one day :D
Thank you very much !!!

Can't wait to try the new settings...

[Kostarum Rex Persia]

Wow, thanks. Great news, bob0r.

[celtic_druid]

I actually added those features to the build I included with my FairUse Wizard compile back in Dec or whenever.

I was just waiting to see if anyone would notice...

[LoRd_MuldeR]

Noticed a small bug with the new VFW settings:

If I check "Bidirectional ME" and klick "OK" and later go back to the config window, then "Bidirectional ME" is unckeckd. So it seems not to remember this setting. I got no idea if "Bidirectional ME" is enabled when I check it, click OK and don't go back to the config window before encoding. At least someone should take a look at this issue...

[Kostarum Rex Persia]

Yes, and I noticed that bug. I think that if "Bidirectional ME" is enabled when I check it, it's disabled when I start encoding, because encoding speed is same with or without checking Bidirectional ME. And we know that "Bidirectional ME" slowdown encoding speed.

And Trellis Quantization is only "on the Final MB", not on value "Always".

[LoRd_MuldeR]

And Trellis Quantization is only "on the Final MB", not on value "Always".

Is that a probelm?


The x264.nl notes say:
not in vfw: Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip)

Is there hope we'll get this soon?

[bob0r]

The Bidirectional ME and Max Ref. frames(try backspace and enter 2, its kinds fucked... or was) bugs are found and fixed, only have to be submitted.

@celtic_druid

^^ And your what? url?

But why not submit to x264 SVN? :)

[bob0r]

And Trellis Quantization is only "on the Final MB", not on value "Always".

Trellis 1 = recommended value. (So no thats not a problem or bug)

For EXTREME settings use x264.exe (with megui.exe if you will), then you can max out everything.

VFW must be simple and easy to use.

@all

Hopefully Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip) will be added to VFW shortly, Fast P-Skip is very easy, Quality-based VBR will take a bit longer.

Hopefully Dan will make us happy soon! (or at least bond)

Do you guys think this will be a good layout for Tab More... ?
http://files.x264.nl/x264_vfw_tab_more.jpg

[akupenguin]

maybe vertically align the checkboxes (chroma/pskip/mixed and cabac/trellis/deblock)

[SeeMoreDigital]

I think "Sample AR" boxes need to be wide enough to accommodate/display "three" numbers in each box.


Cheers

[bob0r]

Something like:
http://files.x264.nl/x264_vfw_tab_more_3.jpg

Btw, 4 more boxes are buggy with pressing backspace and adding new values.
Reported and confirmed, hopefully last submit about these issues soon, i should have tested some more :o

r434 buggy are:
VFW - Rate Control TAB: MIN QP
VFW - Rate Control TAB: MAX QP
VFW - Rate Control TAB: MAX QP Step
VFW - More... TAB: Threads

@SeeMoreDigital
I was too tired i forgot to press submit, so your idea is not in this concept :)

[LoRd_MuldeR]

Hopefully Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip) will be added to VFW shortly, Fast P-Skip is very easy, Quality-based VBR will take a bit longer.

Hopefully Dan will make us happy soon! (or at least bond)

I'm looking forward :D

[LoRd_MuldeR]

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....

[nm]

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....
I had a strange blocking problem (http://forum.doom9.org/showthread.php?p=773296#post773296) with it at all settings, with larger values (over 100) causing significant problems in some scenes. It could be just something in my systems because there were no other similar reports. I haven't tried x264 noise reduction since those tests, so it could be fixed now, if there ever was a bug. If you are using it for anything important, watch the result through to make sure there are no strange artifacts.

As for the values, I wouldn't recommend going over 500 for normal DVD sources. At high values --nr will introduce smaller 4x4 blocks all over the image as can be seen here (http://forum.doom9.org/showthread.php?p=773241#post773241).

[Kostarum Rex Persia]

Bob0r, can you include sub me 7 in your future builds, like Shark tooth in revision 408? And, or course, let us to choose between Trellis quantization values, "On The Final MB" or "Always" value.

[shon3i]

And CQM, is there any option to add decoding function in vfw like xvid, so we can manipulate with x264 files in virtualdub.

[LoRd_MuldeR]

And CQM, is there any option to add decoding function in vfw like xvid, so we can manipulate with x264 files in virtualdub.

You can use ffdshow to open x264 videos in VirtualDub. Of course they need to be in AVI. All you have to do is, enable H.264 support in ffdshow's VFW configuration. Or isn't that what you need?

AFAIK x264 (VFW and CLI) is for encoding only and does not include any kind of decoder.

[Kostarum Rex Persia]

I think that shon3i don't think on that, he has something else in mind. Shron3i, please explain in details your idea.

[shon3i]

is for encoding only and does not include any kind of decoder. I know that but xvidwfv can be a decoder. So i think why can be x264vfw has own decoder

[LoRd_MuldeR]

I know that but xvidwfv can be a decoder. So i think why can be x264vfw has own decoder

Because it is not needed. ffdshow is x264's decoder...

I think there is a decoder on the x264 CVS, but it has not been developed any further. Last change was 1 year ago. If I remember correctly, sombody said the decoder doesn't even compile...

[shon3i]

Ok but you want open x264 avi file i virtual dub to split there is error message.

[Kostarum Rex Persia]

Correct, VirtualDub always show error message when I try to open x264 encoded AVI file. Error message:

"Couldn't locate decompressor for format H264(unknown). VirtualDub requires a Video for Windows(VFW)compatible codec to decompress video. Directshow codecs, such as those used by Windows Media Player, are not suitable".

But I installed ffdshow from december and put ffdshow plug-in in VirtualDub folder.

[LoRd_MuldeR]

Ok but you want open x264 avi file i virtual dub to split there is error message.

What is the error message ???
I think you are just missing a VFW decoder that supports H.264

Do you have an up-to-date build of ffdshow installed? If not so, you'll have to do this!
And after ffdshow is installed, go to START -> Programs -> "ffdshow" -> "VFW codec configuration" and enable "H.264" on the Decoder tab (you need to change value from "disabled" to "libavcodec")
This will work :)

BTW: The "ffvdub" plugin is needed to use the ffdshow video-filters in VirtualDub, it is *not* required for the decoding!

[Kurtnoise]

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....
.....zzz

[LoRd_MuldeR]

With the cli, min=0/max=16...

Now I'm confused :scared:

You say the Noise Reduction value should be between 0 and 16.
Other people talk about values of 100 or even much higher...

So, what is correct ???

[Kurtnoise]

Sorry,...I was confused by the << and <>.

[LoRd_MuldeR]

Sorry,...I was confused by the << and <>.

So this means I should look for a good setting in there range of 0 to about 100, correct?

[celtic_druid]

Well mencoder uses 0, 100,000 but yes x264 does appear to use 0, 1<<16.

[LoRd_MuldeR]

Well mencoder uses 0, 100,000 but yes x264 does appear to use 0, 1<<16.

:eek: :confused:

And what does the x264 VFW inrerface use?

[celtic_druid]

It doesn't use anything. There is no limit, although that doesn't mean that you can really use a value of 56487897897984948949889489879878998. It is just that it will let you enter it.

[LoRd_MuldeR]

It doesn't use anything. There is no limit, although that doesn't mean that you can really use a value of 56487897897984948949889489879878998. It is just that it will let you enter it.

Arrrghhh, please be a little more patient with me :(

I already noticed that it lets my enter whatever I want to. But what values are actually supported and do make sens?
Is the range where I can find a "good" setting only between 0 and 16 or can/should I go much higher, like 100 and even above? I still don't got that...

:thanks:

[foxyshadis]

It means the range is 0-65535. I have no idea if anything over 1000 actually does anything, that's the highest I've tried.

[Koti]

Ok but you want open x264 avi file i virtual dub to split there is error message.


Correct, VirtualDub always show error message when I try to open x264 encoded AVI file. Error message:

"Couldn't locate decompressor for format H264(unknown). VirtualDub requires a Video for Windows(VFW)compatible codec to decompress video. Directshow codecs, such as those used by Windows Media Player, are not suitable".


http://forum.doom9.org/showthread.php?t=93572 <---- April 2005 :search:

[celtic_druid]

Actually I think you can go about as high as you want although really high values (30,000) would look like crap and if you go too high, then you end up back at 0. 250 or so is probably about as high as you would want to go. Guess it would depend on the source and bitrate though. A value of 250 will result in a lower size per quant than 0, so if the bitrate is low enough, then I guess a high value might pay off.

[shon3i]

Do you have an up-to-date build of ffdshow installed? If not so, you'll have to do this!
And after ffdshow is installed, go to START -> Programs -> "ffdshow" -> "VFW codec configuration" and enable "H.264" on the Decoder tab (you need to change value from "disabled" to "libavcodec")
This will work OK this work. I dont see this options before. btw on my machine have trouble with ffdshow. i used last build on x264.nl and try other builds but same problem in something memory leak. have someone other vfw decoder.

[LoRd_MuldeR]

OK this work. I dont see this options before. btw on my machine have trouble with ffdshow. i used last build on x264.nl and try other builds but same problem in something memory leak. have someone other vfw decoder.

I think ffdshow is what you will have to use, if you need to decode x264 content via VFW. One other way I can think of is this: Open the file with AviSynth and then frameserve it to VirtualDub. But then you still would need a decoder - ffdshow. Maybe the official "daily build" works better for you...

[bob0r]

I actually added those features to the build I included with my FairUse Wizard compile back in Dec or whenever.

I was just waiting to see if anyone would notice...

Where can this be downloaded, and why not add to x264 SVN? :)

[celtic_druid]

http://mirror05.x264.nl/celtic_druid/force.php?file=././fu2.2-setup.exe

Whenever I have done a FU build, I have updated all tools, codecs, etc. and since it includes x264vfw I added a few options to make it more uptodate.

Since I didn't want to encourage VfW use, I stopped uploading VfW builds some time back. Like I said, I was waiting to see if anyone would actually notice.

[bob0r]

Ahhhh no wonder, i never added you to files.x264.nl :D
Ill fix you an account on there later, mirror05 should only be used if files breaks down.

Hehehe, totally forgot about that path :p

[Kostarum Rex Persia]

celtic_druid, do you planning to compile your new build, based on recent builds from pengvado, with your new settings and stuff?

You have no excuse now, because bob0r will create a account for you on files.x264.nl:D

[edit] I just visited files.x264.nl, and I saw ready vfw patch for fast-p-skip( http://files.x264.nl/force.php?file=./x264_vfw_fast_pskip.diff ) But what about no-fast-p-skip patch?

[ChronoCross]

damnit C_D. don't update the vfw -_-. cause now we are gonna have about 100000000000 new threads figuring out problems with vfw and why it's output is damaged. which would be fine if it were the cli cause then it would be a big problem but now we have to waste time trying to figure out if these issues are just vfw or if it's cli.

I'm just kidding at you C_D it's fine I just hope people realize how stupid AVC in avi is. Kostarum Rex Persia however won't so I look forward to more annoying "when is this feature going to be implemented" threads.

[celtic_druid]

I think mirror05 has a nicer ring to it anyway. Next time I do a FU build, I will once again make sure that all included tools, codecs, etc. are upto date. Other than that I don't think I will be updating or releasing x264vfw builds.

My cli build is at revision 434 and r435 was just cosmetics.

Those who want AVC in avi can always use mencoder.

Edit: Looks like the FU source got updated Sunday, 12 February.
Edit2: Zip is still the same. Don't know why the date as changed.

[Kostarum Rex Persia]

I'm just kidding at you C_D it's fine I just hope people realize how stupid AVC in avi is. Kostarum Rex Persia however won't so I look forward to more annoying "when is this feature going to be implemented" threads.

Well, if you wanna to insult me, fine. Before that, I suggest to, once again, read forum rules, rule number 4. I never want to insult you, so I, certainly, never expect something like that from you, ChronoCross.

[Sirber]

Well, if you wanna to insult me, fine. Before that, I suggest to, once again, read forum rules, rule number 4. I never want to insult you, so I, certainly, never expect something like that from you, ChronoCross.It's not an insult, it's a guess on your next move ;)

[ChronoCross]

It's not an insult, it's a guess on your next move ;)

exactly. if I wanted to insult you I would have done so. plus it wasn't just aimed at you I just happened to have used you as an example since your the leader of the we need vfw movement.

[bob0r]

I think if x264 developers allow VFW, when it does not create bugs outside VFW, and pengvado allows it obviously, then i see no problem in developing, testing and posting about VFW.
If people want it, why not?

A seperate x264-vfw-development thread ofcourse would prefered, so VFW haters don't have to read it, and requests/bugs/questions can be placed without starting a flame war each time.

MeGUI style threads would be recommended (bug/feature requests/help-manual-questions).

But only if x264-VFW is being seriously developed.

Celtric_druid certainly has the skills to develope VFW, but has no time or is not motivated to do so.

Sharktooh also has the skills, but he can't figure out if he's a girl or a boy (no seriously, health problems prevent him from being active on any level)

Dan "Genesys" Nelson can update certain options also, but to quote him:
"whatever features translate into checkboxes or other simple UI objects, I can do :)"

So, motivation by both user and developer is key issue here, i like VFW, i bug test it and share my thoughts on it, but x264.exe (+ a gui if you must) is simply perfect, each option explained and clear.

Its true any gui(or vfw) can indeed bind options, like mixed-refs can only be used when you have 2 or more reference frames, this makes you learn the options better, for the best result.

One-Click tools will come/are available anyway, so or you just use a program as is, or you fully try to understand its options and make the best of it.

[Kostarum Rex Persia]

Well, ok then, ChronoCross. I am not a leader, and other peoples wanted and asked for updating vfw, not just I. For example, DeathTheSheep.

[Kostarum Rex Persia]

I think if x264 developers allow VFW, when it does not create bugs outside VFW, and pengvado allows it obviously, then i see no problem in developing, testing and posting about VFW.
If people want it, why not?

A separate x264-vfw-development thread of course would preferred, so VFW haters don't have to read it, and requests/bugs/questions can be placed without starting a flame war each time.

MeGUI style threads would be recommended (bug/feature requests/help-manual-questions).

That's wonderful idea, bob0r. Let create separate x264-vfw-development thread. Of course, like MeGUI, and vfw would get thread " Feature requests ", " x264 vfw bug reporting ".

Doom9, what do you think about bob0r suggestion?

[SeeMoreDigital]

That's wonderful idea, bob0r. Let create separate x264-vfw-development thread. Of course, like MeGUI, and vfw would get thread " Feature requests ", " x264 vfw bug reporting ".

Doom9, what do you think about bob0r suggestion?It sounds quite sensible to me!

[Sirber]

Well, ok then, ChronoCross. I am not a leader, and other peoples wanted and asked for updating vfw, not just I. For example, DeathTheSheep.The only one beside you ;)

[Kostarum Rex Persia]

Well, they are hiding. vfw respecters are quite numerous here, but most of them don't talk about it.

[LoRd_MuldeR]

Well, they are hiding. vfw respecters are quite numerous here, but most of them don't talk about it.

I'm here too :D

[shon3i]

I think ffdshow is what you will have to use, if you need to decode x264 content via VFW. One other way I can think of is this: Open the file with AviSynth and then frameserve it to VirtualDub. But then you still would need a decoder - ffdshow. Maybe the official "daily build" works better for you...And what is hapen if i won't recompress video. I tell you that i can using ffdshow beacouse is not working in some reason. I can open any file in virtualdub via avisynth but i must recompress video.

Let create separate x264-vfw-development thread That was be cool

[LoRd_MuldeR]

That's wonderful idea, bob0r. Let create separate x264-vfw-development thread.

They will close and delete it one minute after it is created :(

[Sirber]

They will close and delete it one minute after it is created :(For your own good ;)

[LoRd_MuldeR]

And what is hapen if i won't recompress video. I tell you that i can using ffdshow beacouse is not working in some reason. I can open any file in virtualdub via avisynth but i must recompress video.

I think you'll have to get ffdshow working.
What exactly is the problem? And what builds did you test so far?
Did you try a clean(!) re-install of the official "daily build" ???

[valipod]

I searched the entire MPEG-4 AVC forum for keyword 29.970 and then only for 29, nothing. I figure there must be a bug in the search, nevertheless I didn't find a post regarding my problem.

I have a movie 29.970 FPS, I open the AVS (in VirtualDubMod), it shows 29.970 FPS. I encode it with MeGui x264, and the resulted .264 i convert to AVI with the x264 AVC2AVI embedded in the x264 Full Package. The problem is, the resulted AVI is 25 FPS!!! And 20% longer (seconds), of course. I am of course missing something here, but what?

The same AVS encoded via VfW in VirtualDub produces a correct 29.970 FPS AVI.

[LoRd_MuldeR]

I searched the entire MPEG-4 AVC forum for keyword 29.970 and then only for 29, nothing. I figure there must be a bug in the search, nevertheless I didn't find a post regarding my problem.

I have a movie 29.970 FPS, I open the AVS (in VirtualDubMod), it shows 29.970 FPS. I encode it with MeGui x264, and the resulted .264 i convert to AVI with the x264 AVC2AVI embedded in the x264 Full Package. The problem is, the resulted AVI is 25 FPS!!! And 20% longer (seconds), of course. I am of course missing something here, but what?

The same AVS encoded via VfW in VirtualDub produces a correct 29.970 FPS AVI.

Can't you change the Framerate of the AVI in VirtualDub and set it to the correct value? Just use direct-stream-copy for audio and video.

[shon3i]

I think you'll have to get ffdshow working. I can menage this beacouse my windows is crasheed and i have no time to reinstall it. So i using lastest build from x264.nl i think is 21/12/2005 gcc sse i olso tried some build from free-codecs.com but nothing hapen.

[valipod]

Can't you change the Framerate of the AVI in VirtualDub and set it to the correct value? Just use direct-stream-copy for audio and video.

Well, I did that now, and it works (thanks). But let's call this a "workaround". Is this a bug in the CLI or in the AVC2AVI converter?

[LoRd_MuldeR]

I can menage this beacouse my windows is crasheed and i have no time to reinstall it. So i using lastest build from x264.nl i think is 21/12/2005 gcc sse i olso tried some build from free-codecs.com but nothing hapen.

Give this one a try:
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow

[shon3i]

Give this one a try:
http://ffdshow.sourceforge.net/tikiw...etting+ffdshowI try later thanks for all help

[valipod]

Is there a way I could find out what framerate the intermediate .264 file is? Because I am pretty sure the bug is in the AVC2AVI converter.

[Dayvon]

Is there a way I could find out what framerate the intermediate .264 file is? Because I am pretty sure the bug is in the AVC2AVI converter.
It probably is AVC2AVI because MP4 files default to 25 fps unless label otherwise. Are you rendering to a RAW .264 stream? Because if you are rendering to MP4, you more than most likely will have this problem.

[shon3i]

Is there a way I could find out what framerate the intermediate .264 file is? Because I am pretty sure the bug is in the AVC2AVI converter.
You must use avc2avi comandline and add -f or -fs switch i dont now at the moment use avc2avi -h for help
ex. myfile.264 -f 25 myfile.avi

[valipod]

It probably is AVC2AVI because MP4 files default to 25 fps unless label otherwise. Are you rendering to a RAW .264 stream? Because if you are rendering to MP4, you more than most likely will have this problem.

I created a RAW .264 stream from a 29.97 FPS AVS. And I converted the RAW .264 to avi, where I could observe the 25 FPS.

I tried now the AVC2AVI -h, it says there it defaults to 25 FPS. Still, since the source is 29.97, it should keep that, not expect a parameter from me, or default to something else. Or is there no FPS information in the .264 RAW stream?

[shon3i]

I created a RAW .264 stream from a 29.97 FPS AVS. And I converted the RAW .264 to avi, where I could observe the 25 FPS.
Look my uper post but here is example for you avc2avi myfile.264 -fs 29.976 myfile.avi

[SeeMoreDigital]

Is there a GUI for avc2avi.exe?

[valipod]

Look my uper post but here is example for you avc2avi myfile.264 -fs 29.976 myfile.avi.

I figured out the sintax, even if there is no avc2avi /? (and -h instead :)) The issue now was only to discover where bug is, in the CLI or in the AVC2AVI. I tend to think is the AVC2AVI, with that defaulting to 25FPS. And again, is there no FPS information in the RAW .264 stream?

[valipod]

Is there a GUI for avc2avi.exe?

:) There is AVC2AVI_GUI from the x264 full package, which offers the smallest of functionalty, that is "browse for input" and "Mux".

[shon3i]

And again, is there no FPS information in the RAW .264 stream?I know that but if you want convert .264->AVI default fps from avc2avi.exe is 25, using -fs or -f switch you can corect that. You can't use avc2avi gui beacouse there is not option to change fps. Use run and type cmd, then go to dir where is located avc2avi.exe not gui exe. type avc2avi.exe you should be get all switches. I have avc2avi.exe from lastest sharktooth build 408.

[valipod]

I know that but if you want convert .264->AVI default fps from avc2avi.exe is 25, using -fs or -f switch you can corect that. You can't use avc2avi gui beacouse there is not option to change fps. Use run and type cmd, then go to dir where is located avc2avi.exe not gui exe. type avc2avi.exe you should be get all switches. I have avc2avi.exe from lastest sharktooth build 408.

Actually I was asking. Is there no FPS information in the raw .264 stream? It seems like it isn't.

I have always tried the /? switch whenever I needed help from a commandline exe. Didn't work here. So I figured there's no help offered. I have now tried the -h switch (mentioned here a few posts up) and I got the options. Thanx.

[akupenguin]

Actually I was asking. Is there no FPS information in the raw .264 stream? It seems like it isn't.
There is. avc2avi just ignores it.

[fuxor123]

I encoded some transport streams lately on hte hg-slow settings with megui and couple of times there's some pixelation while a scene changes in the encoded file. The bitrate I used was around 4200kbs. It didn't seem to matter though if it was in a fast or slow moving part of the movie. Just from times to times in a scene change.
Is there any chance of avoiding such an effect in future encodings?

[Kostarum Rex Persia]

OK, guys, raw streams aren't my field, so...

Let's get back on introduce separate threads about VFW development, like Bobrow suggested earlier yesterday on page 82, I think.

Doom9, you didn't answer me anything about new threads. What do you think about opening separate VFW threads, " X VFW development", " X VFW error reporting ", and " X feature requests " ?

Can Bob0r or someone else start these threads, please? :)

[asdfsauce]

Profiles for VFW would be nice. :scared:

[ChronoCross]

As you can see I have made two new topics for you vfw people. Don't make a development thread because it's not needed. The development can be done in the feature request thread as that's probably where the updates on developer progress will go.

For you cli people eager for a new custom build I have made the following

Custom x264 Builds with patches. (http://chronocrossdev.com/apps/x264)

I updated sharktooths patches...well all except the one with vfw in the title of the .diff. I also removed the Signature.diff vfw changes. If you encounter any problems let me know and I'll see if I can narrow it down.

[Sharktooth]

Is there a GUI for avc2avi.exe?
http://files.x264.nl/Sharktooth/utils/avc2avi_rev267+gui.7z
requires .NET 2.0, it muxes the file in the same dir as source and uses the same filename (except the extension that will be .avi).
just let me know if you need more functionalities (well there isnt much to do but...) and i will add them when i will be able to re-start coding.
i was thinking to add fps, batch muxing and maybe splitting (but it requires another prog).

[SeeMoreDigital]

http://files.x264.nl/force.php?file=./Sharktooth/utils/avc2avi_rev267+gui.7z
requires .NET 2.0, it muxes the file in the same dir as source and uses the same filename (except the extension that will be .avi).
just let me know if you need more functionalities (well there isnt much to do but...) and i will add them when i will be able to re-start coding.
i was thinking to add fps, batch muxing and maybe splitting (but it requires another prog).Thanks Sharktooth,

I downloaded the x264 Standard R408 package yesterday :D

I wanted to see how well it worked muxing raw ".h264" streams that had been extracted using YAMB.

The thing I noticed straight away is that the ".h264" file extension is not listed, only the ".264" file extension... Although the muxing worked fine :)

Support for specifying the required FPS would be the most useful implementation at the moment, I think.

Hope you start feeling a little better soon.... Speaking as somebody who was forced into giving up full-time work due to a chronic illness (and had to re-build my immune system from scratch), I sympathise with you....


Cheers

[Doom9]

It's not really an x264 development issue but it's rather technical: Recently, a number of megui users ran into x264.exe aborting the first pass without notice, and then the the second pass would abort immediately with a message about a mismatch of number of frames between the source and the statsfile. However, megui never gets those error messages. Even though I redirect both stdout and stderr of x264.exe, and make sure I keep reading from both as long as neither reports null (that goes beyond the process reporting it has exited), megui can never pick up those messages. I used to have the same issue with encraw but when I changed the code to keep reading beyond the process.Exited event until attempting to read from stdout and stderr just reports null, I managed to catch all the lines from encraw. I'm wondering if anybody has an idea why this doesn't work for x264.exe and what there is fundamentally different from x264 exiting immediately with an an error like the mentioned one, and other errors (like unsupported commandline option.. those are picked up just fine).

[Sirber]

Profiles for VFW would be nice. :scared:
VFW is like VHS... You can still use it but it's time is over.

[kurt]

http://files.x264.nl/force.php?file=./Sharktooth/utils/avc2avi_rev267+gui.7z
requires .NET 2.0, it muxes the file in the same dir as source and uses the same filename (except the extension that will be .avi).
just let me know if you need more functionalities (well there isnt much to do but...) and i will add them when i will be able to re-start coding.
i was thinking to add fps, batch muxing and maybe splitting (but it requires another prog).
errm - sadly the file does not exist :)

[Sharktooth]

damn redirector doesnt like "+" in filenames... i should fix it...
try this direct link: http://files.x264.nl/Sharktooth/utils/avc2avi_rev267+gui.7z

[nickolasemp]

Hello everybody!
Does anyone know how I can put zones (in order to encode a movie's credits in grayscale) in x.264?
I have searched x.264's options but I can't seem to find anywhere such thing as grayscale encoding...

[leowai]

Hello everybody!
Does anyone know how I can put zones (in order to encode a movie's credits in grayscale) in x.264?
I have searched x.264's options but I can't seem to find anywhere such thing as grayscale encoding...
MeGUI support zones. It provides encoding of the movies's credit with less bitrate using x264.exe. The bitrate are reserved for higher bitrate for main movie. However, I'm not sure is this the grayscale encoding that your refer to.

You can download MeGUI binary builds from ChronoCross:
http://chronocrossdev.com/apps/megui/

[Doom9]

there's no grayscale mode in x246 and why is this in the development thread?

[Kostarum Rex Persia]

What about build 445? It seems that some error appearing from build 443.:confused:

lurui: Hi,I use r445 to encode the same file under the same parameter set as r440,but the result is not the same in PSNR and bin bitstream. So I think there is an error in the r445.

and:

Hi,
I test more and find the difference is between r442 and r443. I set b_bframe_adaptive=0,
so the frametype decision function is not used at all. There must be some other reason.

[LoRd_MuldeR]

Downloads on x264.nl broken:
"The requested URL /x264/revision446/x264-446-install.exe was not found on this server."

//EDIT

Okay, it's fixed now

[bob0r]

Ya, it uploads rev.txt first, because it only took 5 minutes to compile, now with a working make fprofiled, my 5m18s test video takes up to 1h30m to compile fully.

I will change the order of files being uploaded later on...

[Inventive Software]

Profiles for VFW would be nice. :scared:
I have tried some dabbling in the source code, and only got as far as making a new tab, which says "Profiles". I should be able to work on it more during the holidays, about 6 weeks, where I'll try and add some drop-down boxes et-al, but don't get your hopes up. My coding knowledge extends to reading the manual (if there is one) and trial-and-error.

[Sharktooth]

why waste time on VFW? Let it die.

[ChronoCross]

why waste time on VFW? Let it die.
I second that.

[IgorC]

I'm third.

[shon3i]

And i am First who is against

[ChronoCross]

And i am First who is against

I don;t get it. Is compatibility the only reason you want it to stay. the native mp4 editing tools are appearing now. It's like telling nintendo that they have to make their new console compatible with the original NES.

[Sharktooth]

VFW is old, is buggy, is slow, is limited, doesnt support many of the new codecs features, creates problems when editing, doesnt support variable bitrate, doesnt support variable framerate, doesnt support streaming, etc...
it's simply old and outdated and must die so a new tech can replace it.

[Eretria-chan]

And i am First who is against
I second that.
There is nothing prevent something new to replace VFW and until that time, VFW should stay around methinks.

[nexus]

I don't know if this bug is known. Sorry, if it was mentioned a few pages before.

Since a few revisions of x264 I get the following error message if I turn on "turbo":

[shon3i]

VFW is old, is buggy, is slow, is limited, doesnt support many of the new codecs features, creates problems when editing, doesnt support variable bitrate, doesnt support variable framerate, doesnt support streaming, etc...
it's simply old and outdated and must die so a new tech can replace it.
I know all of that but developers is not try to implement that options.

[Tommy Carrot]

VFW is old, is buggy, is slow, is limited, doesnt support many of the new codecs features, creates problems when editing, doesnt support variable bitrate, doesnt support variable framerate, doesnt support streaming, etc...
it's simply old and outdated and must die so a new tech can replace it.
Ehh, not again... :( We already had this debate several times, and i explained you several times that most of your arguments are simply not true.

VFW is old indeed (then again, quicktime, which mp4 is based on, is even older), but it is not buggy, no matter how many times you keep repeating it. AVC in vfw interface has exactly the same issue ASP had (b-frame lag at editing, no issues at playbacking), and i don't remember that anyone had any problems with xvid or divx in this regard. VFW is not slower (as only the interface is different, and it has nearly no overhead), and there is no feature in the AVC standard what couldn't be used in VFW interface (the fact that not every feature is implemented in the vfw version is a completely different question). Variable frame rate and streaming are indeed not supported, but i cannot imagine why would i need these features.

I just cannot understand why you guys feel so threatened by the vfw version that you have to keep spreading these misinformations.

[LigH]

You can watch the image of the error message already in a thread in the german board (http://forum.gleitz.info/showpost.php?p=255782&postcount=1). But it looks rather like a MeGUI problem than a x264 bug.
__

@ nexus:

The MeGUI thread is here (http://forum.doom9.org/showthread.php?t=96032).

[bond]

Ehh, not again... :( We already had this debate several times, and i explained you several times that most of your arguments are simply not true.

VFW is old indeed (then again, quicktime, which mp4 is based on, is even older), but it is not buggy, no matter how many times you keep repeating it. AVC in vfw interface has exactly the same issue ASP had (b-frame lag at editing, no issues at playbacking), and i don't remember that anyone had any problems with xvid or divx in this regard. VFW is not slower (as only the interface is different, and it has nearly no overhead), and there is no feature in the AVC standard what couldn't be used in VFW interface (the fact that not every feature is implemented in the vfw version is a completely different question). Variable frame rate and streaming are indeed not supported, but i cannot imagine why would i need these features.

I just cannot understand why you guys feel so threatened by the vfw version that you have to keep spreading these misinformations.tommy carrot, you tell us we dont listen to your arguments?

i tell you you dont listen to ours, cause if you would, you would not "keep spreading these misinformations"

[Sharktooth]

You can watch the image of the error message already in a thread in the german board (http://forum.gleitz.info/showpost.php?p=255782&postcount=1). But it looks rather like a MeGUI problem than a x264 bug.
__

@ nexus:

The MeGUI thread is here (http://forum.doom9.org/showthread.php?t=96032).
yeah, it's related to megui and not to x264.

@Tommy Carrot: it's not limited to b.frames, there are also other features (forward and backward multiple reference frames, frames reordering etc.) that are NOT COMPATIBLE NOR SUPPORTED by VFW (and AVI).
Until VFW is alive there will be small or no interest in creating editing software based on other techs just coz there's virtual dub(mod).
Let vfw die and let the coders develop software based on new technologies.

[Tommy Carrot]

Bond, i think every argument i said is true. I don't say people should use vfw, and i'm perfectly aware of the limitations of it, but sometimes the "anti-vfw league" is saying ridiculous things here, and i feel i have to address the issue. Spreading misinformations, even with good intentions, just to convince people is not ok IMO.

Sharktooth: the mentioned problems are all related to the b-frames, p-frames have no problem with multiple references.

Anyway, i don't wish to continue this debate, let's just say that theoretically i agree with you, i just think you are too quick to bury vfw before any proper alternative could emerge. I'm following closely the developments of the mkv and mp4 manipulator applications, but they are nowhere close to being usable for more complex editing jobs. I think until then the vfw version is still necessary.

[Sharktooth]

spreading misinformation?!?
MPEG-4 ASP was HACKED in VFW... AVC is HACKED in VFW...
what misinformation? VFW doesnt support MPEG-4 (both v3 and v10).
If you say something different it's you spreading misinformation.

[Eretria-chan]

So far, I can see the VFW is good enough for the casual user. And the more advanced tools out there means you have to download additional huge programs and learn them.
I don't see why VFW is so incredibly bad. Make another system like VFW if you think it is so bad. If it really is as good as VFW, it might just one day replace it.

[bond]

guys, lets cool down plz ;)

[Sharktooth]

There is... GStreamer... DirectShow...
But no virtual dub for DirectShow nor for GStreamer...
Thanx to VFW.
BTW, VFW is not good at all... it causes big problems with AVC.

[bond]

well once avidemux supports mp4 output correctly, there will be no reason for using x264 with avi/vfw anymore

[shon3i]

But still is not same. Nobody can change virtualdub

[Sharktooth]

infact it's much better...
stick with your jurassical software and tech then and speak for yourself.

[shon3i]

This software comlete all my jobs whitout any bug. This going nowhere. I want say anything about that.

[Sharktooth]

well, AVC in AVI thru VFW is buggy.
using AVC with VFW is buggy.
using Virtual Dub with AVC is buggy...
since we're talking about x264, and x264 IS AVC... virtual dub and x264 = buggy.
it's not so difficult to understand...

[shon3i]

Relax man i won't mad you i understand you man. But this can fix like says Tommy Carrot

[Sharktooth]

it cant be fixed. there is nothing to fix.
it's just VFW that lacks support for a series of features.
they cant be added without breaking everything.
thats why MS created DirectShow.

[bond]

guys, plz calm down, especially newbies who definitely dont know the technical details

[shon3i]

guys, plz calm down, especially newbies who definitely dont know the technical details
@bond I am not a newbie and i know the technical details
Maybe I am newbie on this forum.

[bond]

how did you know that i mean you? ;)

[Sharktooth]

i know the technical details
it doesnt seem so

[shon3i]

how did you know that i mean you? ;)
Just Easy :)

[nexus]

@ nexus:

The MeGUI thread is here (http://forum.doom9.org/showthread.php?t=96032).
Damn, wrong thread.

[Kurtnoise]

First of all, I understand Tommy Carrot point of view...

Second, I'd say let people choose by themself. I think there are already some good explanations here and there to choose by himself which is good or which is bad for our own needs. In addition, most often problems caused by these tricks can be the break point to change our point of view or at least to change the methods used to create/edit video streams. And don't forget that vfw codecs are also used for captures and all existing methods are not perfect...


But no virtual dub for DirectShow
not true...what about ffdshow. Some dshow filters work with vdub.

nor for GStreamer...
There are some vdub-like in *nix world which use GStreamer.

[Sharktooth]

not true...what about ffdshow. Some dshow filters work with vdub.
the problem is that it will still make use of vdub... and so vfw...
There are some vdub-like in *nix world which use GStreamer.
but not in windows:(

[LoRd_MuldeR]

First of all, I understand Tommy Carrot point of view...

Second, I'd say let people choose by themself. I think there are already some good explanations here and there to choose by himself which is good or which is bad for our own needs. In addition, most often problems caused by these tricks can be the break point to change our point of view or at least to change the methods used to create/edit video streams. And don't forget that vfw codecs are also used for captures and all existing methods are not perfect...

:goodpost:

[Kostarum Rex Persia]

Bond, i think every argument i said is true. I don't say people should use vfw, and i'm perfectly aware of the limitations of it, but sometimes the "anti-vfw league" is saying ridiculous things here, and i feel i have to address the issue. Spreading misinformations, even with good intentions, just to convince people is not ok IMO.

Sharktooth: the mentioned problems are all related to the b-frames, p-frames have no problem with multiple references.

Anyway, i don't wish to continue this debate, let's just say that theoretically i agree with you, i just think you are too quick to bury vfw before any proper alternative could emerge. I'm following closely the developments of the mkv and mp4 manipulator applications, but they are nowhere close to being usable for more complex editing jobs. I think until then the vfw version is still necessary.

I absolutely agree with you, Tommy Carot. And, please, don't kill VFW at least until June 2007, OK. Compatibility is VERY VERY IMPORTANT.:(

And what about VirtualDub, can VirtualDubMod be modified to support your ideas(I mean on "anti-vfw" community)?:devil:

[Kostarum Rex Persia]

And, for the record, Shon3i is very very good in encoding jobs. He knows everything about video encoding for 7 years.

[ChronoCross]

which explains why he is living in the past. VFW needs to be killed off and new technologies be embraced. Why waste the developers times on vfw when the cli could just implement all the features without worry of having to conform to something that was old and outdated even when xvid first came around. The reason we still have xvid vfw is because of the simple fact of no one wanting to leave vfw. are we seriously gonna keep using vfw 25 years from now just because n00b's think it's easy? Come on seriously.

Let it die.

[Kostarum Rex Persia]

No, not 25 years, but only 2 or 3 more years. Until MP4 tools get ready for market.

And what about direct recording in Xvid or x264 from TV recording programs? That's why VFW needs to exist, until recording programs(and the market) accept MP4 container, properly.

[bob0r]

x264.nl > configure --disable-vfw :devil: ?

[ChronoCross]

There is no reason to use x264 for recording captures. we have huffy and xvid/divx for that. They are already vfw.


The question at hand is should we continue to support vfw for upcoming codecs. The answer is no. We already have codecs that do the jobs that vfw were meant to. If we continue to develop x264's vfw then the full switchover to cli will NEVER happen. WHy change when you can get by with the current. If we dump the vfw in x264 we can continue to use the older codecs for direct capturing.

Else we will still be having this conversation when the next level codec comes out in 3-5 years. Are we gonna still beg for vfw when no tools for .mp5 are here?

[Adub]

I am currious about this whole argument.
When people say "no vfw" I wonder what could we use as a replacement? I heard some one mention GStreamer, so I looked it up. It looks really promising, for my very limited knowledge of it.

Are there any others? Some maybe be developed by the brilliant people who populate this maginficent forum? What else would work, because I like my Virtualdub, yet I am starting to really like MeGUI as well.
Thoughts/Suggestions?

[Kostarum Rex Persia]

BTW, can anyone explain to me what is GStreamer? Never heard for that.

[ChronoCross]

BTW, can anyone explain to me what is GStreamer? Never heard for that.


it's called google. repeat after me. google.

http://www.gstreamer.net/

[Sharktooth]

I am currious about this whole argument.
When people say "no vfw" I wonder what could we use as a replacement? I heard some one mention GStreamer, so I looked it up. It looks really promising, for my very limited knowledge of it.

Are there any others? Some maybe be developed by the brilliant people who populate this maginficent forum? What else would work, because I like my Virtualdub, yet I am starting to really like MeGUI as well.
Thoughts/Suggestions?
there is DirectShow (for windows). Nero Recode uses it for example... oh, IIRC gstreamer is developed by matroska guys...
correct me if im wrong.

[bond]

ok as this is the x264 development thread my proposal to bring this topic back to the topic:

split the x264vfw windows centric code from the x264 svn and let vfw advocats take it over and develop it in an own project
just like other x264 guis (megui, staxrip, whatever), and x264vfw is only a gui and not more, are also developed in own projects

[Inventive Software]

Bloody hell, I think I opened a can of compressed worms with the VFW mention.

My 2 cents: Firstly, VFW is still used quite a lot, and until a viable and WORKING alternative arises, I'll continue to help along the development. Secondly, the developers of x264 deserve to have a VFW implementation to give the masses what they want.

[Inventive Software]

ok as this is the x264 development thread my proposal to bring this topic back to the topic:

split the x264vfw windows centric code from the x264 svn and let vfw advocats take it over and develop it in an own project
just like other x264 guis (megui, staxrip, whatever), and x264vfw is only a gui and not more, are also developed in own projects
Isn't that what sex264 was for? AFAIK development has stopped on this, as the VFW in x264 is miles better.

[celtic_druid]

Not sure that giving the masses what they want is ever a good idea.

No one really edits AVC avi's via VfW do they? If they only use it for encoding then surely there are plenty of viable alternatives already?

[Eretria-chan]

No one really edits AVC avi's via VfW do they? If they only use it for encoding then surely there are plenty of viable alternatives already?
If it works, then it works for me. I just want an easy-to-use GUI and no CLI crap. That's all I ask for. But no one seems to heed that :scared:

[bond]

If it works, then it works for me. I just want an easy-to-use GUI and no CLI crap. That's all I ask for. But no one seems to heed that :scared:we have an own forum for x264 gui encoders that are not using vfw and virtualdub

read up before you post

[Eretria-chan]

we have an own forum for x264 gui encoders that are not using vfw and virtualdub

read up before you post
I know that. But they are not VFW.
And I like vdub =)

[bill_baroud]

so what ? with them, you choose an avs file, set the encoding options, and then encode. With vdub, you open an avs file, set the encoding options and then encode. Why the f*** do you want to use vdub ?
Setting encoding options is even faster in megui, there is less mouse movements to access them, so if you're really that lazy (because you doesn't want to change) you should use megui !

[Sharktooth]

I know that. But they are not VFW.
And I like vdub =)they must not be VFW, since it's VFW that causes problems with AVC and unfortunately vdub is based on VFW.
so, it's only a matter of learning to use other tools instead of vdub.

edit: also with megui you dont even have to set the options every time, just use pre-made profiles or create your own ones...

[Eretria-chan]

so what ? with them, you choose an avs file, set the encoding options, and then encode. With vdub, you open an avs file, set the encoding options and then encode. Why the f*** do you want to use vdub ?
Setting encoding options is even faster in megui, there is less mouse movements to access them, so if you're really that lazy (because you doesn't want to change) you should use megui !
Dude, there is a reason I use RA4. I don't know avisynth. I don't know CLI. I want to know neither. I just want an easy-to-use GUI that does it all for me.
I agree RA4 is pretty much all I need (because it handles everything for me), but that doesn't mean VFW is bad. If it works, then it is all we need. If it does not work, then we must use something else.
And I know vdub more than megui and other encoding tools.

[bond]

realanime encodes with x264 to mp4/mkv without vfw/avi too :rolleyes:

[Sharktooth]

Dude, there is a reason I use RA4. I don't know avisynth. I don't know CLI. I want to know neither. I just want an easy-to-use GUI that does it all for me.
I agree RA4 is pretty much all I need (because it handles everything for me), but that doesn't mean VFW is bad. If it works, then it is all we need. If it does not work, then we must use something else.
And I know vdub more than megui and other encoding tools.
well, you dont need to know CLI, avisynth or anything... megui has a script creator, creates the command line for CLI etc... for you.
just use the ONE CLICK ENCODER function and you're set up.
VFW creates non compliant files that can create problems for playback and for editing.
AVC is not supported in VFW and you may end up with unplayable files in a near future.
BTW, RA4 doesnt use VFW nor vdub... it uses x264 CLI...

[Eretria-chan]

realanime encodes with x264 to mp4/mkv without vfw/avi too :rolleyes:
Sure, but I don't have to do anything. Just like VFW. No CLI and no avisynth - just like I want it.
And now I don't want to continue this discussion, so this shall be my final comment.

[Sharktooth]

Eretria-chan... you're telling us there are programs just easy to use as vdub/vfw... so what's the problem??!?
RA4 is good and does the encoding the right way as does megui and staxrip...

[Eretria-chan]

I suppose I can clarify to you a little :)
I'm AGAINST using CLI directly (eg typing a lot of options as a dos prompt). I'm AGAINST using avisynth directly (because there is hundreds of command which I can't possibly remember, plus I don't understand anything about what those commands do).
BUT, I don't mind using a program that handles it.
I'm not against those tools. But I'm not against VFW either.
I AM against, however, those who badmouth VFW. Because VFW works for me and I like it and it is easy to use. When I use VFW, I have no need for the "not supported" features so VFW is quite adequate for me.

Conclusion:
Direct use of CLI + avisynth = BAD.
Use of tools like RA or MeHUI = Okay.
Use of VFW = Okay (NOT BAD).

[Sharktooth]

well, what im trying to say is VFW and AVC is a bad choice coz AVC is basically incompatible with VFW and even if the devs made some hacks to make it "work", it causes problems.
So, it's better to use other codecs with vdub (or VFW in general).

[Eretria-chan]

If it works, if I can do what I need with VFW and AVC, I'm happy. That's all I need. Therefore I don't agree with your when you badmouth VFW. Sure, it may be old, sure it may require hacks - but it works! And it's easy!

If I need more advanced features, I would try some more advanced products.

[bond]

it doesnt work correctly, and thats the point

you get a slight desync and you have missing frames (just two of the many problems)...

inform yourself before you mix yourself into such discussions, clueless newbies kicking in only lead to bad blood

[Sharktooth]

you didnt understand... the advanced features are already in AVC and it uses it everytime you encode...
it's not safe to say it "works"...

[Yong]

I suppose I can clarify to you a little :)
I'm AGAINST using CLI directly (eg typing a lot of options as a dos prompt).
There is someting called "batch file"(it just a text file),
it can execute alot of command at once as you defined in the batch script...
I'm AGAINST using avisynth directly (because there is hundreds of command which I can't possibly remember, plus I don't understand anything about what those commands do).
http://www.avisynth.org/index.php?page=AviSynthManual

imo a simple batch file isnt too hard to write. ;)

example(dgindex -> generate a simple avisynth script -> encode):

@echo off
IF '%1'=='' GOTO EOF
IF "%~1"=="%~dpn1.avs" (GOTO ENC) ELSE (IF "%~1"=="%~dpn1.avi" (GOTO AVI) ELSE (IF "%~1"=="%~dpn1.mpg" GOTO AVS))
:AVI
echo AVISource("%~1" ,false) > "%~dpn1.avs"
GOTO ENC
:AVS
IF EXIST "%~dpn1.avs" GOTO ENC
start /low /b /w D:\DGIndex\DGIndex.exe -IA=5 -OM=0 -IF=[%~1] -OF=[%~dpn1] -exit
rem 1=MMX, 2=SSEMMX, 3=SSE2MMX, 4=64-bit Floating Point, 5=IEEE-1180 Reference, "6=Skal MMX", 7=Simple MMX
echo loadplugin("D:\DGIndex\DGDecode.dll") >> "%~dpn1.avs"
echo mpeg2source("%~dpn1.d2v").Crop(0,56,-0,-56).hqdn3d() >> "%~dpn1.avs"
GOTO ENC
rem fps=23.976.Crop(0,64,-0,-64)..ChangeFPS(15)
:ENC
echo %date% %time%
echo Avisyth Script loaded:
more < "%~dpn1.avs"
set x=start /belownormal /b /w x264 -I 300 -i 30 "%~dpn1.avs" --progress
title X264 Encoder [%1]
%x% -B 600 --me umh -A none --filter -6:-6 -o "%userprofile%\desktop\%~n1.264" --bframes 0 --frames 500
echo %date% %time%
pause>nul:
:EOF

[Eretria-chan]

I did use AVC in VFW some time long ago and it worked fine (at least it looked fine to me), so that adds to my argument. Although I don't use AVC in VFW so much because I let programs handle all the settings for me (RA), so I will not speak of it much.

As long as you get a file that can be watched, then it works, by my definition. And it has in the past. Dunno about now.

As for batch files, CLI & co: that is old school. That was used when DOS was around, and now it isn't anymore. The future is GUI. At least, that is what I think. I don't want to fool around with command lines or batch files and write 20 lines just to encode a file. And even the avisynth manual is confusing for those who don't know how video encoding really works.

In vdub, select the frames you want to delete and select edit -> delete. To resize, add a filter, enter the new size and select a method. What is good here is that I can see a preview of what the result will be with the specified resize method. Piece of cake. But not in avisynth.

But I shan't talk of VFW anymore since you only seem to bounce it back on me and it makes matters worse.

[708145]

As for batch files, CLI & co: that is old school. That was used when DOS was around, and now it isn't anymore. The future is GUI. At least, that is what I think. I don't want to fool around with command lines or batch files and write 20 lines just to encode a file. And even the avisynth manual is confusing for those who don't know how video encoding really works.


mental arithmetic is old-school as well ever since people have calculators, right? :rolleyes:

My point: Both variants, CLI and GUI, have it's use. But this is independent of the VFW discussion!

edit: We should separate editing from encoding. For editing use whatever you like, preferably lossless keyframe-only AVI, but for encoding either use:
a) VFW to encode to an ancient codec of the pre ASP era (before 1999); AVI is fine here as well.
b) use a proper chain and container to encode to advanced codecs
But please don't bug developers with VFW support for advanced codecs. It is disturbing and annoying!

[Adub]

Okay for curiousity sake, how would one go about designing a codec interface through Directshow? My guess is that it would look alot like FFDShow? If so, developers go crazy. I love FFDShow, and if it would replace VFW altogether that would be fine by me.

Am I wrong? Are there other designs for Directshow?

[Eretria-chan]

@echo off
IF '%1'=='' GOTO EOF
IF "%~1"=="%~dpn1.avs" (GOTO ENC) ELSE (IF "%~1"=="%~dpn1.avi" (GOTO AVI) ELSE (IF "%~1"=="%~dpn1.mpg" GOTO AVS))
:AVI
echo AVISource("%~1" ,false) > "%~dpn1.avs"
GOTO ENC
:AVS
IF EXIST "%~dpn1.avs" GOTO ENC
start /low /b /w D:\DGIndex\DGIndex.exe -IA=5 -OM=0 -IF=[%~1] -OF=[%~dpn1] -exit
rem 1=MMX, 2=SSEMMX, 3=SSE2MMX, 4=64-bit Floating Point, 5=IEEE-1180 Reference, "6=Skal MMX", 7=Simple MMX
echo loadplugin("D:\DGIndex\DGDecode.dll") >> "%~dpn1.avs"
echo mpeg2source("%~dpn1.d2v").Crop(0,56,-0,-56).hqdn3d() >> "%~dpn1.avs"
GOTO ENC
rem fps=23.976.Crop(0,64,-0,-64)..ChangeFPS(15)
:ENC
echo %date% %time%
echo Avisyth Script loaded:
more < "%~dpn1.avs"
set x=start /belownormal /b /w x264 -I 300 -i 30 "%~dpn1.avs" --progress
title X264 Encoder [%1]
%x% -B 600 --me umh -A none --filter -6:-6 -o "%userprofile%\desktop\%~n1.264" --bframes 0 --frames 500
echo %date% %time%
pause>nul:
:EOF
How long did it take to write that example? That's exactly what I want to avoid. I do not want to write batch files to use with encoding. Using GUIs is much easier.

708145: Again, you also seem to miss the point, unless you typed wrong. ASP codecs with VFW works perfectly fine. I have done it many times. I have been able to encode/decode and even edit with mostly no problems. Which is another example of what I try to point out: If it works, then whatever it is, buggy, old or whatever, there is no reason not to use it, as long as it works. And with ASP codecs, if you hve not noticed, it works. And therefore I am happy to use VFW with ASP codecs.
Again, note, that even if it might have some limits, it has worked fine for my purposes, and thus it should not be excluded. It works and that is what an end user wants. Don't kill it! :scared:

And DirectShow scares me :scared:
It's so easy to b0rk. But when used properly, it works like a charm and it is easy to extend (NOTE: This does not include actually programming a new filter >_<).

[bond]

there is no need for a directshow interface

x264.exe is perfect as it is, its portable, it outputs perfect files
and there are great guis even the dumbest user can use

so what else is needed?

yeah, dumb people not wanting to learn how to push the "start encoding" button in megui will never stop using vfw

[708145]

708145: Again, you also seem to miss the point, unless you typed wrong. ASP codecs with VFW works perfectly fine. I have done it many times. I have been able to encode/decode and even edit with mostly no problems. Which is another example of what I try to point out: If it works, then whatever it is, buggy, old or whatever, there is no reason not to use it, as long as it works. And with ASP codecs, if you hve not noticed, it works. And therefore I am happy to use VFW with ASP codecs.
Again, note, that even if it might have some limits, it has worked fine for my purposes, and thus it should not be excluded.

Dear Eretria-chan,

please have a look at the posts earlier in this thread stating that ASP (with B frames) in AVI is a hack which needs support by every tool involved in the chain including decoder!

It made tools break which were correct but didn't include that hack! Besides it is becoming more and more a stretch to inlcude advanced codec capabilities like b-pyramid and the likes into AVI. Yeah sure it would work if developers would spend 90% of their time for supporting obsolete tech. Let them concentrate on improving stuff and learn to use a proper GUI instead.

A small related question: :devil: You obviously don't seem to be interested in advanced codecs so why are you discussing here at all. Just use AVI with MPEG1 and be happy. :angry: You miss all the advanced stuff anyway.


edit: I won't post about this topic in this thread anymore. This leads to nothing. Coding some ELDER instead :>

[Eretria-chan]

I must repeat: it works, does it not? You can play files and encode and edit them, right?
I DO care for new techs. Let me tell you...
See, I don't think it is bad to use VFW for things such as ASP, so don't kill it! Obviously, in time, it will become obsolete because it doesn't support all the new advanced stuff, but... that is then.

Maybe you shouldn't use VFW with AVC... but that is a small problem since good GUIs like RA exists. But what for ASP? It works! It works! Let VFW remain for the sake of ASP, where it works.

And bond seems to hate everything but CLI and obvious GUIs like RA. That's a shame... why can't evenyone use something in their own way - like they want to?

[bond]

you get a slight desync and you have missing frames (just two of the many problems)...read that a thousand times...

[Eretria-chan]

Whatever... this is leading nowhere anyway.

[JimiK]

Right, this is leading nowhere. Why don't you guys just let everybody encode the way he/she likes too. There is no law that everybody has to make good encodes. If people use VfW and are happy with the result, so be it. And just ignore all the "we need this and that in VfW" requests. If people that develop the codec feel no need to work on the VfW interface, than thats o.k. There are people that use VfW that are capable of extending the interface. When they do so, they can let others benefit from their work. If people want to use VfW and are not capable of extending it, well, then that's bad luck.
One word to the batch script of Yong: I don't think it took too long to write that. Compared to the encoding time of a 2 hour movie, such a thing is done in no time. And you can reuse it with slight alterations for your next encode. Some time ago, I was using a batch-script to encode some episodes of a series where all files should come out the same size. I also did cut the intro out. All I had to do was to tell the starting and end frame of the intro and the script cutted it out from audio and video and muxed the files in the end. So command line can be extremely helpful. By the way, Linux is one of the comming OS and with its commandline it's just faster to use.

[ChronoCross]

Or we could just remove it and not have it cluttering up space in the svn. Just like I got rid of my windows 98 CD's so should we get rid of the vfw.

[Revgen]

@Eretria-Chan

You really should be asking for better encoding tools, not codecs. Once there is a Vdub-like program that can cut and edit MP4 and MKV containers all this pro-VFW anti-VFW crap can stop.

I honestly can't understand why these two camps can't come together and find an editing solution that can work for everyone. The codec devs shouldn't be blamed for this at all.

[ChronoCross]

Just typical. Someone steps in and says "everyone should agree," then someone comes and throws it down the recycle bin.
Ffs, this is just like company vs company who use DRM to hinder both users and other companies and demand that their own technology should be used.
Let people use what they like! Let developers create solutions like THEY want!
There is no right or wrong...
Though I am sure someone will come in and reply something the other way around and completely disagree with anything sane that is written around here.

ChronoCross's last reply was the most stupid and idiotic reply I've seen today. I give it a 10 of 10 in stupidity.


listen *insert bad word here* you haven't even given one good reason other than your a too big of a lazy *insert bad word here* to learn cli and avisynth. Meanwhile myself, sharktooth, bond have given technical reasons(read the million other threads on this) as well as future practical reasons as to why vfw support in x264 should be canned. but you vfw lovers and your "because it's easy" excuse we have to continue to listen to countless people wondering when support for new features will be added to vfw, or why doesn't my vfw encode work right, why is my audio, etc.

if your gonna call me stupid please read every other thread on this issue and then call bond, sharktooth, doom9 and others idiots as well because they have said the same things I have.

[Revgen]

Here's an idea.

How about you guys delete your posts and PM each other. That way you both don't get striked by Bond. He's not here right now, so you both have time.

[Eretria-chan]

That is a good idea. I retract my statement since it offends someone.

[foxyshadis]

The last 4-5 pages should probably be split and merged into the vfw thread (http://forum.doom9.org/showthread.php?t=105929) instead. Really, discussing the topic is about as useful as abortion at a pta meeting, because no one changes their mind and everyone leaves angry anyway.

[Kostarum Rex Persia]

Yes, Doom9, please split last 3 pages into vfw thread.

[Zero1]

Bleeding hell, just accept that ASP + AVC in AVI/VfW is wrong and requires hacks.

There is a right way and a wrong way of doing this. Both "work", except the wrong way means you are restricted quality wise due to some missing features. Why not just do things the right way and have a HQ working video that no one will have (or should have) issues with?

[celtic_druid]

I could always update the VfW code. Remove bframes, etc.

[ChronoCross]

I could always update the VfW code. Remove bframes, etc.

yeah but really what would be th epoint of that? our whole arguement is that vfw limits the features and you just proved that. why settle for less features simply because your too lazy to learn the new stuff(not talking to you c_d, but to the vfw people)

[celtic_druid]

The point would be that it would work. No lag, no dropped frames. No more arguments.

[leowai]

The point would be that it would work. No lag, no dropped frames. No more arguments.
This make me thinking of the someone is driving a ferrari on an uneven country road with extremely limited speed. Yes, it runs on the road and it's OK if that's the only feature he/she really needs from that ferrari.

Now, why don't we drive that fantastic car on the high way with its full power? If you've never tried the full potential of the car, would you know how much the car is considered "wasted" when it has been only used on the country roads?


*For those who don't know what ferrari is, please simply ignore this thread. :D

[celtic_druid]

I'd still rather have an NSX-R GT. My point is that is basically how it is currently with VfW. If you want the Ferrari, then you don't use VfW.

[SeeMoreDigital]

I could always update the VfW code. Remove bframes, etc.Most of my tests with MPEG-4 AVC have been without B-VOP's....So I think it would be interesting to have a "no-frills" version of the x264 encoder.

By-the-way, what is the correct term to refer to an AVC codec which does not offer stuff like B-frames, Qpel, etc.... Is it "baseline"?


Cheers

[Sharktooth]

Cripled.
At that point is better cutting off VFW before ppl start to say x264 doesnt support b-frames and other stuff...

[bond]

microsoft also doesnt allow using b-frames in their wmv9 vfw encoder, cause they know avi and vfw simply are not useable for b-frames

apart from that using avi not only sucks because of vfw but also because of the lack of interoperability
what we see with the mpeg-4 asp mess is that avi causes a pita as every decoder needs to support specific codec stuff (like different fourccs and other codec specialities)
if people simply use mp4 or native mkv that mess problem is totally gone and interoperability is reached

there are so many arguments against avi/vfw i guess i should write a summary or so :D

[SeeMoreDigital]

Cripled.
At that point is better cutting off VFW before ppl start to say x264 doesnt support b-frames and other stuff...Taking this point further.....

If we don't want the same mistakes to occure with MPEG-4 AVC as it did with MPEG-4 ASP in AVI, then I agree, development in the VfW encoder should either totally cease "or" just a no-frills baseline encoder should be offered.


Cheers

[dragongodz]

hmm what i posted here is just as true for this thread now
http://forum.doom9.org/showthread.php?p=772355#post772355
especially the amount of what could easily be considered rule 4 violations.

I could always update the VfW code. Remove bframes, etc.
thats like cutting off your leg if you have a broken ankle .... talk about overkill. simply limiting things, for example number of B frames limited to max of 2 and removing B pyramid etc etc etc would greatly reduce any risks for those who do not know what they are doing.

[Sagittaire]

thats like cutting off your leg if you have a broken ankle

Well bframe support for x264 is not essential for quality ... :D

[shon3i]

Cripled.
At that point is better cutting off VFW before ppl start to say x264 doesnt support b-frames and other stuff...
Yes better remove than be lame

[Eretria-chan]

Why does no one listen? Why not just let people use what they want are write a text specifically saying: "Please note that due to limitations in VFW, you cannot use b-frames. If you want to use b-frames, concider using MeGUI or a similar encoding GUI."

[max-holz]

so boring.....:rolleyes:

[SeeMoreDigital]

Why does no one listen? Why not just let people use what they want are write a text specifically saying: "Please note that due to limitations in VFW, you cannot use b-frames.I guess it's because in order to refine the x264 encoder further and keep it's development moving forward, it's not a very helpful pandering to the whims of AVI users who constantly ask questions regarding compliance and AVI hacks ;)

Personally I favour "Micro$oft's" VfW/AVI approach (never thought I'd hear myself say that). ie: ditching anything in future VfW versions of x264 that harm/break compliance!

[celtic_druid]

Well cutting the leg off would definatly prevent you from walking on the broken ankle, so there is definatly some logic to it.

[Tima]

Maybe a fair solution is:

- take a current x264 source from SVN
- name it 'x264_VFW-release_xxx-discontinued' or so..
- release this package separately somewhere. (maybe with binaries ;))
- Delete VFW from current branch
- enjoy and forget about legacy :)

....
Splitting VFW-related code to another branch is good too.. :)

[ChronoCross]

Why does no one listen? Why not just let people use what they want are write a text specifically saying: "Please note that due to limitations in VFW, you cannot use b-frames. If you want to use b-frames, concider using MeGUI or a similar encoding GUI."

because by adding a note that they won't read it simply makes them find the developers or post on these forums asking for vfw updates (KRP, yourself, and many others). If we just eliminate it completely then we don't have to deal with that because there will not be any vfw to complain about.

To SeeMoreDigital:

The cli encoder can encode without all the cool stuff too. no need for vfw for that.

[SeeMoreDigital]

To SeeMoreDigital:

The cli encoder can encode without all the cool stuff too. no need for vfw for that.Indeed...

However I (as I suspect are many others) am a GUI only type of guy :(


Cheers

[Sharktooth]

there are plenty of GUIs for x264 CLI

[dragongodz]

it's not a very helpful pandering to the whims of AVI users who constantly ask questions
of course. its much better to pander to the whims of those who want to dictate how and with what people do things. riiiight. ;)

by adding a note that they won't read it simply makes them find the developers or post on these forums asking for vfw updates
and simply limiting the way options can be used, such as max number of B frames(not total removal because that isnt needed) etc etc etc, you dont have to worry if anybody reads a text file or not. ok you will still get some people asking why its limited but all you have to do then is point them towards either a text file or a sticky such as is on here. ye i know that sounds really complicated right. then again look at how many times some people have posted the same thing over and over .... and no i dont mean those who want to use avc in avi. :sly:

If we just eliminate it completely then we don't have to deal with that because there will not be any vfw to complain about.
oh YOU have to deal with it ? are you a dev then ?
infact devs do not have to answer anything either for your information. if you dont like a question being asked repeatedly then why not point to where its already been answered or totally ignore it ?

[Sharktooth]

i updated vfw several times in the past and bundled it with my builds.
i was asked several times (always by the same ppl) to add this and that and sincerely i wont do it anymore.

[ChronoCross]

and simply limiting the way options can be used, such as max number of B frames(not total removal because that isnt needed) etc etc etc, you dont have to worry if anybody reads a text file or not. ok you will still get some people asking why its limited but all you have to do then is point them towards either a text file or a sticky such as is on here. ye i know that sounds really complicated right. then again look at how many times some people have posted the same thing over and over .... and no i dont mean those who want to use avc in avi. :sly:


yeah but for each vfw user we are going to see threads going "why don't vfw have this". Then each time we have to point them to the sticky or to the txt file or wherever. It takes up time over and over and over again. because we know two things. People don't read stickies if their new. and they don't use search either.


oh YOU have to deal with it ? are you a dev then ?
infact devs do not have to answer anything either for your information. if you dont like a question being asked repeatedly then why not point to where its already been answered or totally ignore it ?
I have to deal with it because I answer questions on the forum, help people figure things out in 2 irc channels, I also do pm replies, and private chats. That is why I would like to see more people using the cli.

[bond]

everyone hosting x264 stuff, should simply not offer vfw for download anymore and also not compile it anymore, that would be a first step ;)

[Eretria-chan]

I think then you would recieve other questions such as "Where is there no VFW for x264???" ...or... "Why don't x264 show up in vdub???" ;)

[bond]

I think then you would recieve other questions such as "Where is there no VFW?" ...or... "Why don't x264 show up in vdub???" ;)well there will be a learn process, but everyone has to start somewhere ;)

[Eretria-chan]

Maybe ;) But I doubt you will stop recieving these stupid questions wether you actually kill VFW or not, because people just don't listen, and that's the way it always has been apparently...

[ChronoCross]

I think then you would recieve other questions such as "Where is there no VFW?" ...or... "Why don't x264 show up in vdub???" ;)

No because it would be labeled as cli. I would rather recieve that question than "why does this not work" "when will you be adding..." "why are the devs so slow" etc.

I settle for 1 question over 3.

[Tommy Carrot]

yeah but for each vfw user we are going to see threads going "why don't vfw have this".
This is not really how i see it. I didn't see anyone demanding anything for a long time, but every time when you see someone mentioning the vfw codec, you start your usual rant about the crappyness of vfw, and the thread is doomed to end in a flamewar... Also, there are significanly less complains about the vfw codec than about megui or even the cli encoder (remember the problems with gpac).

[ChronoCross]

This is not really how i see it. I didn't see anyone demanding anything for a long time, but every time when you see someone mentioning the vfw codec, you start your usual rant about the crappyness of vfw, and the thread is doomed to end in a flamewar...

because we have already stated how shitty the vfw is and how it should not be used. The multiple problems with it, the reason it should be abandoned. no one listens to the technical arguement about why it should be gone but rather they spend all their time going "I like it cause it's easy".

[Tommy Carrot]

because we have already stated how shitty the vfw is and how it should not be used. The multiple problems with it, the reason it should be abandoned. no one listens to the technical arguement about why it should be gone but rather they spend all their time going "I like it cause it's easy".
But your technical arguments are usually overexaggerated. As i said several times, the only really problem with vfw is the b-frame lags, and that is _only at editing_. At playback the user will not notice anything, so even if not everything is done correctly, the user will not care. The missing frames is not a necessarity, it's just how it's been implementated in x264.

[ChronoCross]

But your technical arguments are usually overexaggerated. As i said several times, the only really problem with vfw is the b-frame lags, and that is _only at editing_. At playback the user will not notice anything, so even if not everything is done correctly, the user will not care. The missing frames is not a necessarity, it's just how it's been implementated in x264.

but we are also assuming for the time being that these are for personal backups and not for distribution. Even if they are for distribution you should be accomodating for the standard (.mp4) because either way they have to install new filters to play H.264 content. What's one more filter? (mp4 splitter)

Addition: one of the arguements of vfw people is that there are editing tools, but if the bframe lag is all about editing tools then that removes that arguement immediately.

[Sharktooth]

there are other problems expecially at editing... i already said it in the other thread.
dont forget not all avc decoders are able to decode avc in avi due to the "hacks"...

[Eretria-chan]

What about vdubmod? It is able to save to a different container than AVI, is it not? Or am I missing something here?

[bond]

What about vdubmod? It is able to save to a different container than AVI, is it not? Or am I missing something here?virtualdubmod cant save native mkv

for what that means :search:

its simply a pita to unfuck the streams coming from vfw and storing them in nice mkv or mp4 files

[Tommy Carrot]

Addition: one of the arguements of vfw people is that there are editing tools, but if the bframe lag is all about editing tools then that removes that arguement immediately.
The editing is still much easier with vfw. The b-frame lag is just a minor annoyance, with a little experience it can be handled easily, while for mkv and mp4 there is no editor suitable for more complex jobs. I know this might change in the future, but presently this is what we have.

[shon3i]

What about vdubmod? It is able to save to a different container than AVI, is it not? Or am I missing something here?
Yes he can to mkv/ogm

[Sharktooth]

the problem is not the container... but how VFW works.
if you use mkv within vdubmod the mkv will be written in vfw mode...

[shon3i]

the problem is not the container... but how VFW works.
if you use mkv within vdubmod the mkv will be written in vfw mode...
Yes we know

WFV is BAD
AVC in AVI is evil
bla,bla

[max-holz]

What's the point about all this discussion?
You have the source code and you can develop vfw by yourself, open source programs are so called for that reason.

[Kopernikus]

Note that the CLI of x264 makes use of vfw to read avi/avs files.

[Sharktooth]

Note that the CLI of x264 makes use of vfw to read avi/avs files.
what you smoked? :D
CLI does not open avi files and has native avs support.

EDIT: Sorry, maybe it's me smoking too much... avi input is there.
however there are no problems coz it wants yv12 in both avs and avi.

[GodofaGap]

I have to deal with it because I answer questions on the forum, help people figure things out in 2 irc channels, I also do pm replies, and private chats. That is why I would like to see more people using the cli.
Sorry, but you don't have to do that. That is your own choice. It's every user's right to ask something or request a feature, and it is your right to not answer and a developers right to deny the request. Neither side can dictate what the other is allowed to do, the world just doesn't work that way.

Actually, it's very simple. VFW source code is in the x264 svn. People can compile it, use it, distribute it, delete it, do whatever they want it as it's there. If it works fine for them, why should anyone care? I'm sure that person couldn't care less if someone else is using MP4 or MKV. If developers don't want people to use VFW, they should immediately remove it from svn.

Can the discussion now please go back to real development issues? 5 more pages of nonsense for and against VFW aren't very interesting. :(

PS. In the last 20 revisions or so, 3 were specifically for VFW. Why is no one screaming at the developers here? ;)

[Sharktooth]

coz it was an external contribution.
btw there were complains on irc.

[GodofaGap]

Well find all of those people and yell at them!!!

But you kinda missed the point. (it still takes a dev to make a commit, no?)

Anyway, I'm going to follow my own request now...

[Yong]

Well bframe support for x264 is not essential for quality ... :D
please correct me if im wrong,
are you talking about that b frames isnt important in x264?
Just done a small test, h264 video clip that contain b-frames is "visually" look better than no bframes...

[Sharktooth]

bframes efficiency in h.264 is much higher than asp... they ARE essential for quality... except in some rare cases.

[Sagittaire]

I repeat Bframe are not essential for quality : make encoding with and without bframe and see subjective and objective result if you want ...

It's very hard to see difference between:
me5 and me6
wpred and no wpred
trelli and no trelli
bframe or no bframe
1ref and 16 ref
High profil or Main Profil

but it's very easy to see difference between:
me5 1ref main profil and me6 wpred trelli bframe 16ref high profil


If you want blind test I can make that : very hard to see difference between sample with and without bframe ...

[Yong]

I repeat Bframe are not essential for quality : make encoding with and without bframe and see subjective and objective result if you want ...
Please read sharktooth and my post...

It's very hard to see difference between:
me5 and me6
wpred and no wpred
trelli and no trelli
bframe or no bframe
1ref and 16 ref
High profil or Main Profil

but it's very easy to see difference between:
me5 1ref main profil and me6 wpred trelli bframe 16ref high profil


If you want blind test I can make that : very hard to see difference between sample with and without bframe ...
Here is the answer:
Encoded with --crf 35 --weightb --mixed-refs --b-pyramid --filter -6:-6 --no-fast-pskip --bframes 2 --aq-strength 0.5 --aq-sensitivity 15 -8 --no-b-adapt
http://www.mytempdir.com/490701

same parameter but without b frames:
http://www.mytempdir.com/490711
This video clips look bad as it have many "soft" block and white block(?), file size is bigger than clips above too.

Please tell me which one look better ;)

[nm]

For a more meaningful comparison, you should have encoded with a fixed bitrate and two passes, not with --crf.

[Yong]

Ok my comparison might be meaningless, its just a quick test only :D
but the point of this comparison is show the b frames efficiency.
as for CBR and 2pass encoding, ive done it alot already,
imo CBR never look better than nth pass encoding :)

[Sagittaire]

Here is the answer:
Encoded with --crf 35 --weightb --mixed-refs --b-pyramid --filter -6:-6 --no-fast-pskip --bframes 2 --aq-strength 0.5 --aq-sensitivity 15 -8 --no-b-adapt
http://www.mytempdir.com/490701

same parameter but without b frames:
http://www.mytempdir.com/490711
This video clips look bad as it have many "soft" block and white block(?), file size is bigger than clips above too.

Please tell me which one look better

crf 35, -6,-6 for inloop, 2 bframe with useless bpyramid, useless adaptative quantisation : your setting are simply ridiculous ... :D

And finaly 2 876 Ko (bframe) vs 4 016 Ko (no bframe). Bframe is certainely good for quality and save perhaps something like 5% of bitrate but certainely not 30% like in your "demonstration".

[foxyshadis]

Ultra-low bitrate (35 certainly qualifies) requires 2-pass for max efficiency, and a heavy inloop (2,2) will probably improve compression and visual looks. -6,-6 is only useful for very high-bitrate, where inloop is off for most blocks anyway (such as crf 10-14).

b-frames' usefulness is directly proportional to bitrate and framerate, the higher they are the more you save and the more b-frames you should use. At the bottom of the quality scale, you're right, they sometimes make it look worse at the same bitrate, though removing them isn't nearly as good as just adding 50 to the bitrate.

[dragongodz]

i was asked several times (always by the same ppl) to add this and that and sincerely i wont do it anymore.
and of course you have every right to do so and there is the sticky about missing things in vfw so people can be pointed to it if they have such requests etc. why people seem unwilling to point people to the sticky does amaze me though. instead we have this massive thread polution going over the same things repeatedly.

Then each time we have to point them to the sticky or to the txt file or wherever. It takes up time over and over and over again.
ahhh so you would rather spend all this time posting how many posts(?) saying how you think its all evil etc etc etc rather than point to a tiscky or tell them to read a text file ? if you really cared about time then you would use the fastest method to tell them, and thats not all these posts.

I have to deal with it because I answer questions on the forum, help people figure things out in 2 irc channels, I also do pm replies, and private chats.
Sorry, but you don't have to do that. That is your own choice. It's every user's right to ask something or request a feature, and it is your right to not answer and a developers right to deny the request. Neither side can dictate what the other is allowed to do, the world just doesn't work that way.
my point exactly. you do NOT have to reply to anything so your making a big deal out of HAVING to answer the same questions etc is not true.

btw there were complains on irc.
and we should care why ? you can just as easily ignore messages from people on irc as ignore posts here. it really is that easy.

Can the discussion now please go back to real development issues? 5 more pages of nonsense for and against VFW aren't very interesting.
i agree. this has all been gone over time and time again. thats why i gave a link to the last thread where this was carried on and what i said about it all before that thread was closed.

[Yong]

crf 35, -6,-6 for inloop, 2 bframe with useless bpyramid, useless adaptative quantisation : your setting are simply ridiculous ... :D
ya, im bloody noobish from hell:eek: :D
so far i only use abr/2pass for encoding, i use crf and others options for experimental propose only:rolleyes:
i dont know crf will give me what bitrate but the difference is big for my ridiculous low quality clips(with b-frames 180kbps, without b-frames 254kbps iirc)
as i said its just a quick test and i know what am i doing.

You always say this options useless, that options useless,
im so dumb please tell me why they are useless?:rolleyes:
And finaly 2 876 Ko (bframe) vs 4 016 Ko (no bframe). Bframe is certainely good for quality and save perhaps something like 5% of bitrate but certainely not 30% like in your "demonstration".
may be my test show the efficiency of b-frames with one pass encoing?:cool:

and i updated my comparision again:
2pass encoding with -B 256 -b 0 -r 5 -f -6:-6 -A all -m 6 -w -p 2 --b-pyramid --me umh -8 --mixed-refs -t 2 --b-rdo --bime --no-fast-pskip --no-b-adapt
http://www.mytempdir.com/491344

with 2 b frames
http://www.mytempdir.com/491353
imo the clip contain b frames still look better, less annoiying blocks and much stable.
If you still say b-frame is useless, and hardly to see any difference between 2 clips, i surrender, you win...(im tired:rolleyes: )

[Sagittaire]

1) Setting
Inloop : for common user best subjective interval are generaly in [-4;0] and certainely not -6 moreover with q>30 for average quant
Adaptative quantisation: useless because patch is removed in your build
2bframe with pyramid bframe: useless bacause you must use at least 3 bframe is you want optimal pyramid bframe.

2) Your sample
Your sample is very particular sample : scene transition are always fade transition. In your particular sample fade transition use very higher average quant for PPP sequencies than PBP sequencies. In fact in your particular example sample without bframe use very higher average quant than sample with bframe. IMO sample with bframe is very better for metric than sample without bframe. It is not general case.

I can find If you want very particular sample with only high motion and no adaptative bframe : in this case sample without bframe will be always better. I can find particular example to show powerfull of weighted prediction, reference frame, pyramid bframe ... but it's only particular example and advantage for these functions are in general case small.

Here most common encoding (not only fade transition) with common average quantizer (crf 25 encoding bitrate).

Sample without bframe (http://multimediacom.free.fr/Video/MI3_x264_0bframes.mp4)
PSNR = 43.79 dB

Sample with 3 bframe (http://multimediacom.free.fr/Video/MI3_x264_3bframes.mp4)
PSNR = 44.05 dB

Advantage for bframe are small here and hard to find visual differencies. Be carefull I don't say "sample without bframe is the best". I say only that advantage for bframe is small in general case, like I say advantage for multi referencing frame is small in general case, like I say advantage for pyramid bframe is small in general case ... etc etc

[Sharktooth]

b.frames advantage on a whole movie is unquestionable.
trailers and other stupid examples are useless coz they have lots of scenechanges and usually show action scenes.
this prevents the codec to efficiently place b.frames (turning off adaptiveness kills the efficiency as well) so it's not good for measuring b.frames efficiency.
Encode a set of full movies with and without b.frames and look at the differences... then we can talk about efficiency.

[Sagittaire]

b.frames advantage on a whole movie is unquestionable.

Certainely, you can save bitrate with bframe, wpred, multi ref frames or other functionnality. Adaptative Bframe are always good functionnality for H264, good but certainely not essential. For me inloop is an essential functionnality in H264 but certainely not BFrame. I can make good encoding at high average quant without bframe but not without inloop ...


trailers and other stupid examples are useless coz they have lots of scenechanges and usually show action scenes.

Well trailer change only real compressibily level but all scene in trailer are real movie scene. Have to scenechange at 25 frames or at 100 frames don't change conclusion for bframe effeciency or other functionality if you choose good trailer (low motion and high motion, no fade transition ... etc etc)

But I can make complete encoding with real movie in real condition with exactly the same result. Bframe can save maximum something like 10% of bitrate and not more.


and simply limiting the way options can be used, such as max number of B frames(not total removal because that isnt needed)

And if you want absolulty use bframe in avi you can because the first bframe are the most important if you use bframe. More than 1 bframe save generaly a low bitrate, 3 bframes + pyramid too.

Use bframe in avi in not a problem, don't use bframe in avi too ... but IMO use compliant MPEG4 MP4 container for compliant MPEG4 ASP/AVC video stream with compliant MPEG4 AAC audio stream is the logical way !!?

[foxyshadis]

I have a suggestion: Eliminate --me esa from normal builds. (incl. vfw) It's only meant as a debugging/testing mechanism anyway, and is not intended for normal use, yet some people use it figuring "it must be higher quality if it takes longer". So it should be restricted to being compiled behind a specific (or general debug) #define.

[Kostarum Rex Persia]

You are not right, foxyshadis. If x264 user want to use that setting, let use it. Many people want slowest settings, and I aren't thinking on me.

[Manao]

I wonder, if there was an option --format-harddrive, would you use it ? Well, it's the same for --me esa. However, I would not disable it, but add a big fat warning telling how lame it would be to use esa in an everyday encode.

[Kostarum Rex Persia]

Yes, of course. Big fat warning telling how lame it would be to use esa in an everyday encode sounds OK.

[Sirber]

I blocked ESA in RealAnime since it's just useless.

[Ferux]

I always used ESA, but it's on video's which are important to me (home video's) and the colors are quiet blurry.

So you say it doesn't improve things? (That would be good news for me since my encodes take 7 days..)

[foxyshadis]

No, it is only infintesimally better than umh (multi-hex) on most sources, if at all, and many, many times slower.

[Sirber]

No, it is only infintesimally better than umh (multi-hex) on most sources, if at all, and many, many times slower.If it's 1% even better, it's 300% slower. Does not worth it.

[foxyshadis]

http://img301.imageshack.us/img301/8227/ssimtable6fx.jpg
&
http://img67.imageshack.us/img67/850/x264table7jz.png

It definitely isn't even 1% better, at least in the tests in the settings (http://forum.doom9.org/showthread.php?t=107699) thread, but I guess "many many times" is a bit of an exaggeration, 200-300% more usual. Subme7 is a much better use of the time and even that isn't amazingly useful, but at least it could give a small visual difference.

[Ferux]

Subme7 is a much better use of the time and even that isn't amazingly useful, but at least it could give a small visual difference.


Thanks for the explanation.

btw, i used both (esa and RDO level 2) :)

[shon3i]

Why bob0r builds don't have AQ Patch like ChronoCross. I downloaded lastest ChronoCross build and test this patch and there is big impact in quality especialy at dark scenes

[foxyshadis]

Because bob0r's builds are automated and intentionally direct from svn? Not everyone fully trusts the patches, or they'd be in svn.

[Caroliano]

I'm also in favour of eliminate --esa in normal builds, or at least make dificult and discourage it's use, like changing the name to --Insenely-Slow-And-Useles-Exaustive-ME, and keep it in "secret". Like FLAC's --super-secret-totally-impractical-compression-level (I'm not kiding! (http://people.ucsc.edu/~rswilson/flactest/)).

but I guess "many many times" is a bit of an exaggeration, 200-300% more usual.--esa was even slower some time ago, but pengvado made it 2~3 times faster in revision 388: https://trac.videolan.org/x264/changeset/388

[GodofaGap]

I wonder, if there was an option --format-harddrive, would you use it ? Well, it's the same for --me esa.
Well, it's not *really* the same. :rolleyes:

But if we go that way I can think of some more options that could be removed (merange and no-asm to name some), but what I don't understand is how anyone would benefit from doing this... IMO such things are better to be handled by GUIs.

[Isochroma]

Of course, I use ESA and RDO L2 too, so I hope it stays in there, at least for the CLI. Encoding time for me is no object, and any improvement in quality is desired!

[akupenguin]

Encoding time for me is no object, and any improvement in quality is desired!
Before you say that, make sure it actually does improve quality. On some videos, UMH is better by a similarly small amount...
oh no, have I just incited him to encode every movie twice, with esa and umh?

I should just skip to the point and add --placebo. The end user wouldn't be able to tell the difference, and it'd give me tons of spare CPU-time to further my own nefarious plots!

[Caroliano]

But if we go that way I can think of some more options that could be removed (merange and no-asm to name some), but what I don't understand is how anyone would benefit from doing this...
MErange is already a bit restrict (it is capped in 16 for dia and hex, etc) and higher values can be beneficial with low frame rate material (someone said that, but don't gave results to check IIRC), although it do more harm than help normaly... No-asm is an no-one-know option, that is fine where it is.

The harm of public know esa is that some people put everything in the max and then complain about the inefficience of x264 and even H.264. Or simply take toooo many time to get an infimous gain in quality, or none at all.

[foxyshadis]

Iso: Have you ever done an abx of uhm and esa? Before committing to an option that could double or triple your encoding time, I would make sure you can even spot any difference, let alone one that could be definitively called "better". It could mean the difference between a 18-hour dvd backup and a 48-hour one, on your 2500+.

I did it with subme 7 and could only spot very marginal differences when I tried, at the same filesize, so I stick to subme 6. But I wouldn't call it useless for real encoding, like esa, just slower than I prefer. (no-asm at least looks like the debugging option it is, since in theory it gives exactly the same results. perhaps rename esa to debug?)

[rushin_911]

I suggest keeping it. I think I've read somewhere on the board some people use it for stuff such as music videos (which are usually short), not to mention simply allowing the freedom of choice. I would think that any blocking or whatever option be from the gui of the encoder, since probably anyone using the commandline is knowledgable enough to know the effects of the available options (or at least the main ones).

[Isochroma]

Agreed.

[gumimaci]

Hi,
Where can i get ChronoCross build source code. I need the patched source code or the paches which are working with the latest svn.
Thanks.

[foxyshadis]

http://files.x264.nl/Sharktooth/?dir=./x264_patches

x264_p8rd.9_update2-391.diff (aka subme 7) does not merge into the current codebase, but the others should present few problems. x264.nl contains the main source.

[gumimaci]

I know where can i get Sharktooth old patches and the latest svn, but i have trouble to merge it. I want to know that someone update these patches or is there any merged source.

[ChronoCross]

All the patches present a shitload of problems at this current time. none of them except AQ merge out of the box. you literally have to merge them manually the first time around and then recreate the .diffs. right now I see no reason to use them until the developers pick them up again as the current features seem to provide the same quality. I will continue to add the AQ patch to all builds I make in the meantime due to popular demand.

[Kostarum Rex Persia]

Thanks for that effort, ChronoCross.

[shon3i]

@ChronoCross your build with AQ patch is cool. AQ is very powerfull tool for dark scenes. Is there some option to force bob0r to add patch in "official" build and MeGUI

[Sirber]

can AQ help at 318kbps, anime content, 640x480@24FPS in dark scenes?

[ChronoCross]

@ChronoCross your build with AQ patch is cool. AQ is very powerfull tool for dark scenes. Is there some option to force bob0r to add patch in "official" build and MeGUI

I wouldn't recommend having him include it in the official builds. Or using the word force for that matter. the official builds should be svn only.

Like I said on IRC AQ is not the most effective command and it is not done in the best way possible. which is one of the reason it hasn't been committed.

[shon3i]

can AQ help at 318kbps, anime content, 640x480@24FPS in dark scenes? Probably yes, You should be try.

[Todesengel]

Sharktooth, can you make build with current (or average) bitrate indication, like MENCODER's?

[Romario]

@ Todesengel

I really doubt it, because Sharktooth is still in hospital.

[Sharktooth]

i got home but i still have to recover the data from a broken raid 0 array...

[skyjaker]

i got home but i still have to recover the data from a broken raid 0 array...


Luckily you got backups...

[dimzon]

Hey!
Seems like MSU perform some tweaks around x264 ABR for low bitrates
http://www.compression.ru/video/x264/x264_improvement_en.html

http://www.compression.ru/video/x264/images/image002_en.png

http://www.compression.ru/video/x264/images/image004_en.png

[shon3i]

@dimzon did you see this topic http://forum.doom9.org/showthread.php?t=108438

[Kyle_Katarn]

x264 still crashes when used with PhotoToFilm (VfW) : http://www.kcsoftwares.com/?p2m

What's wrong with x264 ??

[SeeMoreDigital]

x264 still crashes when used with PhotoToFilm (VfW) : http://www.kcsoftwares.com/?p2m

What's wrong with x264 ??Every now and again I suffer crashes with JPGAvi...

I've tracked it down to some source image types having a bit depth less than 24 and/or some source images having resolutions below "mod4".


Cheers

[CREXbzh]

Every now and again I suffer crashes with JPGAvi...

I've tracked it down to some source image types having a bit depth less than 24 and/or some source images having resolutions below "mod4".

then you don't encode videos below mod4. It's sub-optimal anyhow!

[Kyle_Katarn]

Every now and again I suffer crashes with JPGAvi...

I've tracked it down to some source image types having a bit depth less than 24 and/or some source images having resolutions below "mod4".


Cheers

I'm using x264 default settings and 24bit JPEG images.
PhotoToFilm is available here : http://kcsoftwares.com

Can't understand what's wrong... Does someone knowns how to debug x264 or track down this crash on codec's side ?

[SeeMoreDigital]

Can't understand what's wrong... Does someone knowns how to debug x264 or track down this crash on codec's side ?Hi Kyle,

Indeed.... I've just tried it with some JPG source images that work perfectly with JPGAvi but crash in your application :(


Bummer!

[ChronoCross]

x264 still crashes when used with PhotoToFilm (VfW) : http://www.kcsoftwares.com/?p2m

What's wrong with x264 ??

There is nothing wrong with x264. There is something wrong with VFW in general however. do not use it. if you want to use x264, export your files losslessly and then encode it with x264 cli.

[SeeMoreDigital]

There is nothing wrong with x264. There is something wrong with VFW in general however. do not use it. if you want to use x264, export your files losslessly and then encode it with x264 cli.I wonder how the x264 VfW codec is able to work with JPGAvi then?

Cheers

[Kyle_Katarn]

Is it possible to trace x264 processing in order to see what makes it crash ?
PhotoToFilm crashes because of an exception raised inside of x264 codec.

[akupenguin]

Just like tracing any other program. build x264 with --enable-debug, and run it under gdb or your debugger of choice. (In the case of vfw, run your whole app under gdb, and it should catch x264 too)

[Kyle_Katarn]

the problem is that i my application is multithreaded .. and written in Delphi ;-(

[akupenguin]

gdb can handle mulithread, and delphi should be ok as long as the crash happens in C code.

[DarkFoon]

There is something wrong with VFW in general however. do not use it.
Not this again!! :rolleyes:

[Sharktooth]

Not this again!! :rolleyes:
why not? chronocross is right.

[DarkFoon]

Ugh...

Everybody, since we all know where we stand on the subject, let's just respect the other party's opinion, and let things be. Nobody is going to convince anybody else on this topic, that is clear. Therefore, it is a waste of time discussing (read: arguing) it at all.
Especially here.
If you want a VFW flame war, start a new thread titled "VFW sucks!" and enjoy. Or better yet, start your own forum website titled "DeathToVFW.net" and battle there.

And to you noobs out there about to post some problem you're having with x264 in Virtualdub: use your head a little bit before posting! Don't make a general acusation ("x264 is borken!") until you have pinpointed the problem. That is called making a good bug report. If the problem lies with VFW, you're S.O.L here. Use the CLI or a different codec. Or, fix the problem yourself.

[Sirber]

Use the CLI or a different codec. Or, fix the problem yourself.Or use RealAnime ;)

[Kyle_Katarn]

The problem is that i'm unable to fix the problem myself because on the lack of knowledge on codec developement and what's under x264 hood.

That's why i'm looking for the kind assistance on some developpers from this excellent forum :-)

[DarkFoon]

@Kyle
It sounds like Akupenguin's suggestion is where you should begin. If you have more problems after trying that, maybe PM him (with his permission) so as not ot set off the anti-VFW trolls.

[Kyle_Katarn]

Allright ! I was not trying to feed the trolll... only to get some assistance ;-)

I'll contact Akupenguin.

[Kostarum Rex Persia]

Ugh...

Everybody, since we all know where we stand on the subject, let's just respect the other party's opinion, and let things be. Nobody is going to convince anybody else on this topic, that is clear. Therefore, it is a waste of time discussing (read: arguing) it at all.
Especially here.
If you want a VFW flame war, start a new thread titled "VFW sucks!" and enjoy. Or better yet, start your own forum website titled "DeathToVFW.net" and battle there.

And to you noobs out there about to post some problem you're having with x264 in Virtualdub: use your head a little bit before posting! Don't make a general acusation ("x264 is borken!") until you have pinpointed the problem. That is called making a good bug report. If the problem lies with VFW, you're S.O.L here. Use the CLI or a different codec. Or, fix the problem yourself.

Yeah, I support his attitude:angry: This isn't place for flame wars.

[ChronoCross]

Yeah, I support his attitude:angry: This isn't place for flame wars.

your one to talk. you create 99% of the flamewars that happen in this and other threads. Please do not try to make yourself look like a saint.

[DarkFoon]

your one to talk. you create 99% of the flamewars that happen in this and other threads. Please do not try to make yourself look like a saint.
Let ye who is innocent cast the first stone...

Don't point fingers Chrono, you're no saint either.

[ChronoCross]

Let ye who is innocent cast the first stone...

Don't point fingers Chrono, you're no saint either.

I don't create the illusion of sainthood either. So I'm allowed to point out things like this.

[Sharktooth]

Well, there's no saints here. PPL use what they want, but PPL should also understand VFW is mantained by contributors and not by official devs.
PPL should understand VFW is not the right way to encode with x264 or any other AVC codec.
So any x264 VFW problem is secondary and it's not granted to be fixed or even looked into.
So posting about x264 VFW problems can only make us (the ones you call anti-vfw) swear to remove the x264 VFW completely from the project and that will only piss the devs...
Is it clear? Problems with VFW? you wont find the answer here...

[dragongodz]

Is it clear? Problems with VFW? you wont find the answer here...
no you are right. you will only find the same old blather over and over and over etc etc etc.

So any x264 VFW problem is secondary and it's not granted to be fixed or even looked into.
hmm isnt the sticky about vfw lacking certain features pointing to that ?

actually since bond seems to share your views(from his postings) i would suggest he make a sticky where all vfw/avi haters can post all the reasons they think its wrong etc etc etc. then you can simply point to that instead of this constant polluting of threads with the same stuff over and over.

[DarkFoon]

i would suggest [bond] make a sticky where all vfw/avi haters can post all the reasons they think its wrong etc etc etc. then you can simply point to that instead of this constant polluting of threads with the same stuff over and over.
I concur.

I also would promote a separate thread where proponents of VFW could post their problems, and people kind enough who are interested in helping (instead of preaching why VFW is bad) can offer assistance.
A thread title like "x264 VFW problems"

If somebody goofs and asks a VFW question here (in x264 dev), they should be pointed to the correct thread (x264 VFW), and their post moved there. The important part would be NOT flaming the person for their folly.
People seem to get so angry over this topic. It's just a software standard. But I guess some people need something to be upset with. However, I digress...

All this flaming on the topic is silly, and an administrator taking sides is unfortunate. That means that the moving of threads will not happen should somebody goof the topics, and instead a simple mistake (e.g. posting a VFW question in x264 dev)will re-ignite the flaming. People make mistakes; keeping our heads here seems difficult. Seriously, it's worse than the OpenBSD mailing lists: people get attacked for the smallest things there.

Honestly Sharktooth, I did not know that VFW was maintained by contributors, and not the official devs, until you said that. I wonder how many other people did not know that. Is that stated somewhere (obvious) where people will see it?

You also assume I am one of the "VFW people" as you call them, but I haven't stated my opinions on VFW.
I'm going to say it once:
I don't use VFW. I have no reason to. I have moved on, and no thanks to anybody ranting in doom9 about how bad VFW is and that MKV or MP4 is far superior to AVI. I came to my own realization at how cool MKV is. (actually, I was curious about what it was, and when I experimented with it, I found that I like it)
I wish there were a program like VirtualDub for MKV, I am convinced that would convert many people. But there is not, and who knows, maybe I'll write one in a few years.

[ChronoCross]

Also remember doom9 closed all the vfw help threads, feature request threads, and development threads.....so I kinda think the boards position on the subject is made.

[DarkFoon]

Well, then the VFW camp is screwed.
How unfortunate.

[dragongodz]

Also remember doom9 closed all the vfw help threads, feature request threads, and development threads.....so I kinda think the boards position on the subject is made.
ahh so now you can read minds too ? i have to assume that since no reason was given for the closure except in the case of people asking about features being added to the vfw version. in that case it was simply that it had been asked many times before and people asking again would infact be violating rule 1/1a.

however look at what those threads turned in to, exactly what you are seeing here now. nothing more than the same things being pushed by the exact same people. both pushing for vfw to be updated or pushing for people to stop using it do not really belong here. the first has been answered in a sticky, which opponents of vfw should be pointing out, instead of posting the same thing repeatedly, and the second should be stopped just as hard IMHO because it advances nothing. just pushes ,not suggests, a persons opinion on what others should do or use. you want to give real reasons then make 1 post, such as the sticky i suggested, and point to that. arguing or trying to ram your opinion down someones throat with multiple posts every time someone asks something will get you nowhere.

if all else fails you CAN ignore such posts ,as you have already been told.

[ChronoCross]

Your doing the same thing you protesting against. your telling me to not say anything about being anti-vfw. you are saying they have a right to talk. so basically your saying they can talk but I can't? I could remind them as many times as I want the problems with AVC in vfw. as long as there are people posting about it I will continue to advocate against it. Until both sides STFU completely I will continue to advocate for the cause.

[max-holz]

Which is the use of --enable-shared?

[ChronoCross]

--enable-shared build libx264.so

[akupenguin]

Which is the use of --enable-shared?
If you don't know, then it's not for you.

[max-holz]

If you don't know, then it's not for you.
As I can understand is not for win OS.

[squid_80]

So posting about x264 VFW problems can only make us (the ones you call anti-vfw) swear to remove the x264 VFW completely from the project and that will only piss the devs...
Removing vfw completely from x264 would be quite a disaster, since avisynth is vfw based... Strange that none of the anti-vfw posts have mentioned this. :sly:

[dragongodz]

Your doing the same thing you protesting against.
hmm so me asking for all this constant repeating of the same b.s. to stop is the same as what you are doing ? riiiight.

your telling me to not say anything about being anti-vfw. you are saying they have a right to talk. so basically your saying they can talk but I can't?
try actually reading what i typed instead of trying to say i said something i didnt.
i said to put your arguements in 1 thread, preferably a sticky, and point to that instead of these pointless arguements that keep going on and get nowhere. also you could then mention they would be breaking rule 1/1a, especially so if it was a sticky so stuck there for all to see.

as long as there are people posting about it I will continue to advocate against it. Until both sides STFU completely I will continue to advocate for the cause.
cause ? its now a crusade is it ? :)
nobody is asking you to like it and nobody is saying you have to answer questions about it. you do that on your own. however you also contribute greatly to this thread pollution whenever it starts. i have suggested what i think would be a better and cleaner way to handle it. if you dont like that idea then why not suggest a better way yourself, because all these repetative posts are just a waste of space and convices nobody of anything.

[akupenguin]

Removing vfw completely from x264 would be quite a disaster, since avisynth is vfw based... Strange that none of the anti-vfw posts have mentioned this.
LoadLibrary("avisynth.dll");
See avs2yuv for an implementation this way. No vfw involved, unless of course the script itself uses it, but that wouldn't be x264's problem.

[Sharktooth]

DarkFoon and dragongodz have you finished polluting this thread with you VFW bullshit?
No support for VFW here, and please stop discussing about it.
This thread is about x264 development and x264 VFW is not part of x264 development. it's mantained by contributors and actually there aren't any.
:search: :readrule: read the stickies and STFU, please.

[Guest]

@Sharktooth

Please read and follow forum rules, specifically, rule 4: be nice to each other, do not use profanities, etc.

http://forum.doom9.org/forum-rules.htm

[buzzqw]

please... fair play !
no offensive word or whatever to offence

BHH

[Sharktooth]

@Sharktooth

Please read and follow forum rules, specifically, rule 4: be nice to each other, do not use profanities, etc.

http://forum.doom9.org/forum-rules.htm
i played fair till now. there are stickies and other threads where discussing those things.
everytime i get here there are ppl whining about something that's cleartly wrong...
im sick of repeating always the same things (as other competent ppl do and keep doing).