x264 development

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

[neuron2]

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