x264 development

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