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.