No more vfw x264 builds?

[COREiP]

Bond I got lots of respect for you and what you have done but this makes no sense. Why do you have to ban topics about x264 vfw... Some of us prefer to use vfw because its simple... nobody is asking for you to build anything.

[ChronoCross]

wow another person about to get a strike.

[DDogg]

Hmm, it always worries me when somebody much smarter than me starts making my decisions for me. I know there must be an excellent reason, but I still prefer to make my own decisions about what is best for me - and make my own mistakes. Free world and all that.

Another thing I know for sure is having a vfw x264 version is sure nice for those of us trying to tinker a little and upgrade our knowledge. VDubMod is pretty dated I guess, but then so am I. Playing around with x264 in in VDubMod is like wearing an old comfortable pair of jeans - even though I know eventually I'll need to get a new pair cause they are worn out. Keypoint here is that it is my decision when to chuck them out, not anybody else's - no matter how well meaning they are.

[ChronoCross]

x264 in vdubmod is kinda like buying a pair of shoes with rocks permanently inside. It works alright for awhile but then you end up breaking your feet and you can no longer switch shoes. It doesn't help that the way you walk is just a tiny bit crippled and you look retarded in the meantime.

[foxyshadis]

So what's the worst that can happen. People still use nandub, of all things, or VDub 1.3c, or Divx 3.11, or AC3 in mp4, but we don't close every thread that mentions them. We just recommend something newer and more compliant, and tell them most people here won't be able to (or want to) help them if they keep using it, so they're on their own.

The x264vfw dogpiles are one of the reasons that Doom9 has a reputation as a bunch of arrogant pricks. (Which I don't believe, but everyone I've pointed here says that's their first impression after reading a few threads, or what they've heard online.)

[ChronoCross]

I thinkt hat is based on the fact that most people come here looking to ask a question and expect a walkthough. and when they get told to use search it pisses them off.

The reason that the modderators are taking a hardline stance on this is because it's causing everyone who spends time helping people learning to pull their hair out when someone insists on using avi, when it is very clear that this was never what avi was meant for.

I always get a good laugh when people cannot figure out why when their using a method that should have died awhile ago they get crap quality or poor sync or stream errors they always cry.

Isn't the fact that you bascially have to spend more time learning the workarounds for such tasks when you could just spend the time learning something like MeGUI to do all of that? It seems like a waste of time to me.

I'll go back and use the old 5 1/2 floppy machine in my parents garage simply because it fits like a shoe and is easy to use.

these vfw pricks need to look at it like this: They always want NEW features, NEW AND BETTER compression, NEW 64-bit architecture (this one is for you KRP), and yet they still insist on using OLD AND OBSOLETE VFW. Hypocritical if you ask me.

[DDogg]

Couple of things - (I feel a DD soapbox fit coming on)

ChronoCross, you seem to have taken it upon yourself to speak for the mods. Did you speak with them about that first?

On top of that, Sirber instructs Bond to close threads including positive comments by very respected members like SMD as well as twice instructing Bond to issue strikes to people who spoke out. Amazingly those instructions were followed.

That is totally inappropriate and unacceptable conduct for a non mod and I know of what I speak as one of the older members, and ex mods of this forum.

Second, yeah, the Doom9 forum is elitist, and was always designed to be, BUT there were safeguards put in place to protect from abuse of power. One of those is the right for members to respectfully disagree (which I am doing)

Third, who wants to use an AVI? There are some of us who would like to use CQ x264 with AC3 in a MKV format who don't care about chapters and all the other stuff. It works fine for now

Fourth, people will naturally move off VFW gradually as the GUI and other tools stabilize and are not actively bleeding all over the place and having their bandages changed daily. Until then, some folks don't really appreciate intrusions from those who spend a large amount of time proclaiming to know it all, for all the rest of us.

Remember, the D9 is a living virtual community. It may not be a democracy, but it is supposed to be benevolent and welcoming to new people (who translate into new talent). It does not exist as a few peoples personal club used for personal agendas. It exists to compile, refine, and spread specialized knowledge of a complex and difficult subject, and to teach that knowledge to those who will come after and replace those of you that burn out.

Best to all good things D9. May it be here 10 years from now healthy and strong as ever.

Bond, if you feel this is out of line then do what you gotta do. No hard feelings and I hope you know you are truly appeciated.

[quake74]

I don't really care about vfw since I don't use it, but I'd like to suggest that the admins (doom9/sirber/bond or whoever) puts up a new sticky (or change the old "About the missing option in the x264 VfW") to include a (semi)official statement along the lines of:

"Most of the admin/moderators of this forum believe that vfw is an old technology and should not be used with modern codecs and especially x264. Forcing x264 to work with vfw can only be accomplished with a series of hacks which take time away from actually improving x264 compression. For this reason, we (most of the admins/mods/etc) do not support at all any vfw build of x264. So people asking for help will probably receive none, and people complaining about the lack of vfw will probably receive a strike."

Obviously the statement should be rewritten by somebody who knows what he's talking about ;)

[Kurtnoise]

x264 rev 581 : no more vfw. Isn't that clear enough ?

[crnagora]

x264 rev 581 : no more vfw. Isn't that clear enough ?

Cruel world :(

[check]

You could always try this: http://forum.doom9.org/showthread.php?t=95415

I don't really understand the complaint that the vfw interface is easy to set up. I tried real anime 4 a few month ago, and that is far simpler. Perhaps "familiar" is a better word?

[Sirber]

but I'd like to suggest that the admins (doom9/sirber/bond or whoever)I'm no admin :D Just a simple user.

@check

x264gui is outdated.

[Irwin]

I asked authors about special version realanime, megui or others - "special" -> that works on below 256Mb ram. I have only 192MB ram and Vdub&h264 works superb (with avimux and he-aac sound i get normal sync audio and avi output) but when i run this "piece of cra..." Megui or realanime -> "256MB needed"

x264 for vfw is strongly needed


sorry for my poor english

[Sirber]

@Irwin

If you don't use filtering x264 will use less than 100MB RAM. Also, I don't remember your email/pm ;). If extra ram is needed, windows will swap other stuff. RealAnime won,t block you. Only thing, RealAnime 5 quality profiles are ment for P4 3Ghz and equivalent.

[DarkZell666]

These complaints were bound to happen, x264.nl's survey concerning x264's usage showed that only hardly less than half of the users still used vfw.

I can understand the dev's dropping vfw since it isn't their main pre-occupation, but that doesn't mean nobody else can continue developping it ! It's open-source, bl**dy hell ! Just connect to the SVN and checkout the previous's revisions's sourcecode !

If vfw is really needed (which seems to be the case), then a user that has much interest in vfw should continue development and provide builds if he has some time (maintaining a dll and an ini file shouldn't be too much hassle :))

However, I don't agree much with Sirber and bond's anti-vfw reckage. DDog is right I'm afraid, we're big enough to decide what we want to use. Hints as to why not use vfw are still welcome, as long as you provide an alternative (which Irwin didn't find in the first place).

@Irwin : I can suggest you use leiming's x264 gui (works with the cli), it's very light, and even if it has a couple of silly bugs for now (and doesn't come bundled with the required software either xD), they might get resolved if you really need it. Mencoder264 would be another nice alternative for you (uses mencoder as the name suggests).

For other people who absolutely need to encode to h264 via vfw, use ffdshow's vfw helper (it also works for encoding ;)).

The solution to help people forget about vdub/vfw and the like is to provide _easy_ alternatives.
Learning AviSynth isn't easy for everyone (MeGUI isn't easy either imho) compared to vdub.
To add to what DDog was saying, so many of the GUI's out there need a VERY BIG usability improvement before the masses start using them.

[Kurtnoise]

For other people who absolutely need to encode to h264 via vfw, use ffdshow's vfw helper (it also works for encoding ;)).
This has been also removed is recent builds...:p


edit : about light vfw alternative : there is a gtk interface dedicated to x264. Not finished yet with 2pass mode but it's very promising.

[SeeMoreDigital]

To repeat what I mentioned yesterday, I still use the VfW builds because it's the only way I can obtain a reliable (non B-VOP) AVC stream to work with QT7 player!

Even then, any build higher than Sharktooth's Core 36 SVN 322 dated Oct 09 2005, won't allow me to generate 2-pass encodes with MPEG Mediator!

By-the-way, I've tried generating MPEG-4 AVC streams using Recode2, and StaxRip (x264). And while they play perfectly well in 99.9% of software media players, they don't play in QT7 player :scared: And using another "web based" media player is not an option due to "client" restraints!

If somebody knows why this is and can point me to which "QT7 player" friendly settings I should be selecting I will (of-course) stop using VfW and encoding to evil AVI.

[Sirber]

QT7 is not complient.
Also, the vids I make for iPod using x264.exe plays #1 in QT7 ;)

[Sharktooth]

To repeat what I mentioned yesterday, I still use the VfW builds because it's the only way I can obtain a reliable (non B-VOP) AVC stream to work with QT7 player!

Even then, any build higher than Sharktooth's Core 36 SVN 322 dated Oct 09 2005, won't allow me to generate 2-pass encodes with MPEG Mediator!

By-the-way, I've tried generating MPEG-4 AVC streams using Recode2, and StaxRip (x264). And while they play perfectly well in 99.9% of software media players, they don't play in QT7 player :scared: And using another "web based" media player is not an option due to "client" restraints!

If somebody knows why this is and can point me to which "QT7 player" friendly settings I should be selecting I will (of-course) stop using VfW and encoding to evil AVI.
I made a specific MeGUI x264 profile for QT ages ago.
IIRC StaxRip has it too and also AutoMKV.

[Kostarum Rex Persia]

wow another person about to get a strike.

I don't think so:readrule:

The x264vfw dogpiles are one of the reasons that Doom9 has a reputation as a bunch of arrogant pricks.

Yes, that's true, unfortunately. People (admins), you can't behave like that, it's not very polite.

[DDogg]

Speaking of alternatives to vfw which are simple to use, AutoMK is starting to work very nicely and has a comfortable AutoGK kind of feel to it. http://forum.doom9.org/showthread.php?t=113811

Certainly worth the effort to check it out and the author is very responsive, and gentle, with noob questions which is going to be a good part of its audience. [the program is still very rough in places, so be warned of that]

@Kostarum Rex Persia - Learn when to not rub salt in a wound

[Sharktooth]

Yes, that's true, unfortunately. People (admins), you can't behave like that, it's not very polite.It's NOT even YOUR forum... Understand the rules and understand this is a video technology oriented forum.
Old techs are not welcome (VFW is there from windows 3.x!!!).
Please refrain your ego and if you're looking for other solutions look for them in a separate place.

[SeeMoreDigital]

I made a specific MeGUI x264 profile for QT ages ago.
IIRC StaxRip has it too and also AutoMKV.Yes that's true...

But for some reason QT7 Pro is not able to re-mux the .MP4 file to an .MOV file :eek:

[ChronoCross]

that's because their mp4 splitter is damaged. Do you have any particular reason you need to have it switch containers? If it's playable in QT then why does it need to be .mov? .mp4 plays in itunes and on ipods.

[Sirber]

Apple moved from .MOV to .MP4, which is a great move :)

[Kostarum Rex Persia]

I only saying that this forum become quite strange, lately. And Doom9, as owner, don't know when to act and stop some users from talking bullshits.

And, I don't mean on moderators neither Sharktooth, who is good person.

[SeeMoreDigital]

that's because their mp4 splitter is damaged. Do you have any particular reason you need to have it switch containers? If it's playable in QT then why does it need to be .mov? .mp4 plays in itunes and on ipods.My clients require .MOV so they can add and/or amend their own "Annotation" information to each file ;)

[Sharktooth]

use avc2avi to mux raw 264 streams to avi so QT will gladly accept and mux them...

[Sirber]

use avc2avi to mux raw 264 streams to avi so QT will gladly accept and mux them...QT7 can mux AVI and AAC in MOV?

[Sharktooth]

He was using vdub with x264vfw so i suppose QT reads avi files...

[Sirber]

avi files with audio in it. avc2avi doesn't merge audio in the final avi.

[Sharktooth]

QT should be also able to read raw aac files...

[SeeMoreDigital]

use avc2avi to mux raw 264 streams to avi so QT will gladly accept and mux them...That would not work as QT7 does not correctly accept MPEG-4 AVC streams within AVI and you can't add other streams (such as AAC audio) with it either.

Currently I use VfW to generate 2-pass AVC "video only" (512x288 @ 480Kbps) streams from RAW MPEG-2 (720 or 704x576 .M2V) sources.

I then use YAMB to de-mux the AVC stream from out of the .AVI container. And YAMB again to re-mux the elementary .H264 stream together with my AAC stream into the MP4 container. And then QT7Pro to re-mux the .MP4 to .MOV....

It's some months since I tried StaxRip, but from what I remember it also kept altering my required bit-rate.... Maybe things have changed...


Cheers

[AVIL]

Hi all,

IMHO almost every person does a personal balance between pros and cons and make his personal choice. And all are respectable. Ok to the idea of evolve to best techniques. It is easy to explain the pros. However, it must also be alternatives for the cons. Only as an example, evolving Vdub to use this new technologies. Or promoting a reliable alternative to Vdub. Then, probably most of us will reconsider our choices.

Who wants the “silence of the lambs”?

[bond]

the threads were closed because this topic only leads to flames.
the thing is we already discussed all this a thousand times, didnt we? so why discuss this another thousand times?

doom9 even made a sticky because of discussions like this, pointing out two clear things:

If you miss these features, you have two options:

1) Use the commandline encoder (with a GUI frontent if you like, here's a list

2) Start Visual Studio and add the options on your own.so instead of talking out loud, learn to code and code your x264 vfw wrapper of choice.

adding to this there is no sense in non-developers whining around about the vfw x264 wrapper all the time.
what we see is that there is no real developer support for vfw. i mean pengvado even removed the vfw code from the x264 svn because he cant stand all this anymore. what else do you need more?

that said, i have a clear interest in keeping core developers of core opensource projects on the board. And when those devs get fed up by bugging of some user on doom9 its absolutely clear for me that the board has an interest in keeping those devs on the board instead of some guys who provide the community nothing but trouble!
its always the same persons who whine around about this, requesting from everyone everything all the time. and i am sure those persons dont even use all the things they ask for. apart from that they break the rules without seeming to care, like flaming people, talking in non-english aso. those guys should be happy that they havent been banned already for a long time.

[Sharktooth]

That would not work as QT7 does not correctly accept MPEG-4 AVC streams within AVI and you can't add other streams (such as AAC audio) with it either.

Currently I use VfW to generate 2-pass AVC "video only" (512x288 @ 480Kbps) streams from RAW MPEG-2 (720 or 704x576 .M2V) sources.

I then use YAMB to de-mux the AVC stream from out of the .AVI container. And YAMB again to re-mux the elementary .H264 stream together with my AAC stream into the MP4 container. And then QT7Pro to re-mux the .MP4 to .MOV....

It's some months since I tried StaxRip, but from what I remember it also kept altering my required bit-rate.... Maybe things have changed...


Cheers
I thought it wasnt possible coz of:
Yes that's true...

But for some reason QT7 Pro is not able to re-mux the .MP4 file to an .MOV file :eek:
... however, what's the problem using MeGUI then?
Use the x264 QT profile and be sure to use AAC-LC for audio. Mux the streams with megui or manually with MP4Box and there you go...

[Romario]

I am so sad, because x264 vfw doesn't exist anymore.

Long live VFW.

[SeeMoreDigital]

... however, what's the problem using MeGUI then?
Use the x264 QT profile..... I'm embarrassed to say I find MeGUI functions difficult to understand :o

I'm not into creating AVS scripts. For me I need to be able to input a RAW .M2V video stream, alter my horizontal and vertical cropping areas visually and manually enter my required output resolution...


Cheers

[Sharktooth]

I am so sad, because x264 vfw doesn't exist anymore.

Long live VFW.
Could you please stop making useless comments? Thanks.
I'm embarrassed to say I find MeGUI functions difficult to understand :o

I'm not into creating AVS scripts. For me I need to be able to input a RAW .M2V video stream, alter my horizontal and vertical cropping areas visually and manually enter my required output resolution...


Cheers
Tools menu-> Avisynth script creator
It has a preview window and most common operations are automated...

[bob0r]

Really, people this is your chance!!
The time has come to learn x264.exe with or without GUI.
I myself always used vfw too, but that was because there was no xvid CLI.

CLI makes you learn about an encoder, more options, and how stuff works. Using Megui can be very simple, but you can also go very advanced.

You can ask questions about filters to use in avisynth, how to improof your encodes, thats what this forum is for.

And when it comes to x264 CLI all you have to keep in mind is:
http://x264.nl/jab.gifhttp://x264.nl/jab.gifhttp://x264.nl/jab.gifhttp://x264.nl/jab.gifhttp://x264.nl/jab.gifhttp://x264.nl/jab.gifhttp://x264.nl/jab.gifhttp://x264.nl/jab.gifhttp://x264.nl/jab.gifhttp://x264.nl/jab.gif

Happy encoding everyone!

[DDogg]

the threads were closed because this topic only leads to flames.
the thing is we already discussed all this a thousand times, didnt we? so why discuss this another thousand times?

doom9 even made a sticky because of discussions like this, pointing out two clear things:

so instead of talking out loud, learn to code and code your x264 vfw wrapper of choice.

adding to this there is no sense in non-developers whining around about the vfw x264 wrapper all the time.
what we see is that there is no real developer support for vfw. i mean pengvado even removed the vfw code from the x264 svn because he cant stand all this anymore. what else do you need more?

that said, i have a clear interest in keeping core developers of core opensource projects on the board. And when those devs get fed up by bugging of some user on doom9 its absolutely clear for me that the board has an interest in keeping those devs on the board instead of some guys who provide the community nothing but trouble!
its always the same persons who whine around about this, requesting from everyone everything all the time. and i am sure those persons dont even use all the things they ask for. apart from that they break the rules without seeming to care, like flaming people, talking in non-english aso. those guys should be happy that they havent been banned already for a long time. I think anybody with some experience on this forum can feel your pain and frustration. Sometimes solutions to complex problems are simple. From what you said above, it is clear you most identify with the developers. That is a good thing as I know you stay on the very, very bleeding edge of all things in this area.

There are realities though. Mp4 is about to become mainstream and I fear you are about to be inundated with more and more beginner stuff mixed in with the more complex development topics. Something as simple as a MP4 entrance level forum with a mod(s) more tuned toward the average Joe Bumpkiss tool user may well be something for you guys to consider. It sure worked for Avisynth! Think about selecting "move" for all those posts that make you nuts and smile.

Or, maybe just get yourself a co-mod, or two, that is tasked with dealing with all things noobish - in a firm, but fair and evenhanded way (including striking old and new members who contribute to what some feel is a sense of mean spirited "leet-ness").

Long and short is you should NOT be required to deal with this crap stuff day n and day out. You are way too talented and provide a special glue for the developers here that must be respected at all cost. Maybe figure out a way where you can still enjoy what you do best and dump the crap on someone else who needs to pay their dues to this forum.

Wish you all the best.

[bond]

its our job as mods to make sure that this is handled: http://forum.doom9.org/member.php?u=77335 and it speaks for itself

plz dont mix "the poor newb wanting to use his vfw" with pure trolls.

[SeeMoreDigital]

Okay... I'll download and try using MeGUI again!

I'll start tomorrow.... So for all those who can provide help please be prepared to answer some really dumb questions ;)

Many thanks everyone

EDIT: Hi Bond... Jeez 15 strikes in 14 months... That's got to be a forum record. Maybe you could do with some additional moderator support?

[Sirber]

its our job as mods to make sure that this is handled: http://forum.doom9.org/member.php?u=77335 and it speaks for itself

plz dont mix "the poor newb wanting to use his vfw" with pure trolls.

hahaha, funny :D

[DDogg]

its our job as mods to make sure that this is handled: http://forum.doom9.org/member.php?u=77335 and it speaks for itself

plz dont mix "the poor newb wanting to use his vfw" with pure trolls. Understood trolls before you wrote it. Understand my point - Senior airline captains should not be required to clean the potty in flight. The distraction might cause a crash and most probably they would not do a very good cleaning job anyway - different skill-sets involved. ;-) [delegation is the key to handling complexity]

(@Sirber - toilet, loo, WC, crapper, head, pooper :p)

[Sirber]

@DDogg

I do not understand your "potty" thing. :confused:

[virus]

I'd like to throw my 2 cents into the issue, given that in the past I've contributed some stuff to x264's VfW frontend and that people keeps resurrecting that good old thread about x264gui - which was the VfW GUI without VfW (MeGUI would be an ideal replacement for it, except for that .NET 2 framework which doesn't run on old kernels and requires a download which is pretty heavy - and often costly - for analog modems... not that I care about Windows too much anyway - but I'm digressing).

I'm all for officially declaring VfW as dead, unsopported, obsolete, crippled, Evil(TM) and whatever - as long as you don't jump on someone else's bones for that, which sometimes has happened here. However, I don't think removing it completely from SVN was really necessary. Of course it's not lost, since you can always checkout a previous revision and reintegrate it if you wish, but that's an extra step and people meeting x264 after r581 might not even realize there was a VfW frontend to begin with.

Personally I'd have just removed the stuff from Makefile and configure and maybe added a short note in /vfw telling that piece of code is unsopported. That is, refuse to build something which may break lately due to changes in the core but basically leave it in as it is. That code might still be useful to someone, might still attract contributors, and generally, it doesn't hurt anyone staying all alone in its directory. After all, VfW has been in an unmantained state for a very long time throughout x264's history, but often it suddenly resurrected.

See, for example, how support for old architectures/devices in the Linux kernel is handled. Nothing gets removed until basically everybody has stopped both usage and maintenance of that part, and that part breaks in such a way that's no longer affordable to keep it in. In my personal view, a couple of the previous conditions aren't true for VfW - yet.

I'd rather encourage people to keep on educating people about the beauty of x264cli instead of overreacting by deleting code when there's no need to delete it. The principles behind the GPL would rather suggest to try and share the code as long as possible - even if unsupported, and let the user decide whether they want to take the burden to reintegrate it in some way.

[Sirber]

most users that want VFW don't want to go in the code.
So leaving it in or out doesn't matter much.

[tomos]

personally, i use both new and old.

if i encode a move or something, then i'd use megui. but if its an episodic thing, then i'd use vdub - only because, afaik,there is no 'simple' way of splitting the video afterwards.

i know mkvmerge can split video, but last time i used it you could only type in a timestamp. without being able to open the vid in vdub then its very awkward to do this.

IMO, mp4 etc is the future, but the tools for those of us who dont write code etc, isnt anywhere near as good for editing/splitting etc as they are for vfw and it looks like it will be years before we have those tools.

until that happens, i will use both. its not because i want to stick with vfw, its because not using vfw severly limits my options.

[DeathTheSheep]

its because not using vfw severly limits my options
Ah, the diversity and freedom of choice suffers another blow for the good of...uh, whatever the good in suddenly canning VfW happens to be (above posts hinted at...something or another, I believe). :P

Well, VfW is old, and I guess it is too easy for the average user, eh... Can't let 'em have it too easy; heavy-duty learning must be done! :P

I mean, it's not like my entire 13-page guide with explanations and illustrations has in one day been rendered completely and utterly useless...

And it's not like 50% of x264 users will be left in the cold, forced to switch to a whole new GUI, container, and jargon to receive any further updates to this one codec, and separately install GUI software to use this one codec, and install .NET framework 2 for this one codec (GUI), and other of such nasty things, eh?

This whole thing reminds me (unpleasantly) of having to learn and upgrade to a whole new OS (XP) or processor just to use a new version of a software (Windows encoder), when compatibility with the older ones could easily have been retained... Didn't you say something like that before, bond? :)

So here is my (constructive) suggestion: just keep the vfw code intact. The VfW is complete enough for the average user, is it not? Why force drastic and unnecessary change when leaving it the way it is takes virtually no effort?

Thanks for hearing me out.

[Sharktooth]

personally, i use both new and old.

if i encode a move or something, then i'd use megui. but if its an episodic thing, then i'd use vdub - only because, afaik,there is no 'simple' way of splitting the video afterwards.

i know mkvmerge can split video, but last time i used it you could only type in a timestamp. without being able to open the vid in vdub then its very awkward to do this.

IMO, mp4 etc is the future, but the tools for those of us who dont write code etc, isnt anywhere near as good for editing/splitting etc as they are for vfw and it looks like it will be years before we have those tools.

until that happens, i will use both. its not because i want to stick with vfw, its because not using vfw severly limits my options.
It already happened. Get avidemux.

[Sharktooth]

Ah, the diversity and freedom of choice suffers another blow for the good of...uh, whatever the good in suddenly canning VfW happens to be (above posts hinted at...something or another, I believe). :P

Well, VfW is old, and I guess it is too easy for the average user, eh... Can't let 'em have it too easy; heavy-duty learning must be done! :P

I mean, it's not like my entire 13-page guide with explanations and illustrations has in one day been rendered completely and utterly useless...

And it's not like 50% of x264 users will be left in the cold, forced to switch to a whole new GUI, container, and jargon to receive any further updates to this one codec, and seperately install GUI software to use this one codec, and install .NET framework 2 for this one codec (GUI), and other of such nasty things, eh?

This whole thing reminds me (unpleasantly) of having to learn and upgrade to a whole new OS (XP) or processor just to use a new version of a software (Windows encoder), when compatibility with the older ones could easily have been retained... Didn't you say something like that before, bond? :)

So here is my (constructive) suggestion: just keep the vfw code intact. The VfW is complete enough for the average user, is it not? Why force drastic and unnecessary change when leaving it the way it is takes virtually no effort?

Thanks for hearing me out.
Oh... that's a catastrophic report. But since x264 VFW was no longer mantained new features will not be implemented. You can still use an old version... im sure they're still around they work... oh and magically your guide is still good for those...
Also read what Virus said... all the VFW code is still on the SVN... you just have to know how to get it. A coder or a builder will surely know how to do.
All this "oh my god! it's gone... oh my god! bring it back! oh my..." it's a NONSENSE. Stop whining and get a life.

[DeathTheSheep]

Well, sometimes a report is necessary.
I'm afraid all the speed boosts and quality enhancements which are not encapsulated within the "options" will be missed out on. For instance, the drastic speed boost of exhaustive motion estimation would have been... "missed," you could say, if the VfW wasn't silently updated along with the CLI, with no added effort or cost to anyone (except the compiler, who would be doing 50% of x264 users a huge favor, really :)).

But on a completely different not, I'm afraid I don't see the "magic" to which you are referring ;).

[Sharktooth]

You know, VFW code is only a "wrapper"... you dont need to update it to get the latest shiny new internal x264 optimizations ... just compile libx264 and then compile the VFW frontend.
There is no difference if the VFW code is not in the current SVN... you can always get it.
For instance, i could build x264VFW rev600 (when it will be available) even if the VFW folder is no longer in the current SVN revision...
Now follow my suggestion and stop bitching and refrain to make childish comments (like this: http://forum.doom9.org/showthread.php?t=98247&page=7). It could only make it worse...

[DeathTheSheep]

i could build x264VFW rev600 (when it will be available) even if the VFW folder is no longer in the current SVN revision...
Really?! That would be nice of you, Sharktooth. 1 VFW build every 20 revisions would be great, actually... Maybe you could treat it as a sort of "consolation prize" to the people who lost out when they went with VfW? :)

Just a suggestion.

[Sharktooth]

It was an example. Everyone can do it but no one wants to...
So, start thinking doing it by yourself...

[DeathTheSheep]

Maybe it's just a matter of them (us) not knowing how, fearing the compilation of a codec to be a complicated process, and depending on the kindess and generosity of others who know the way around?
I suppose if someone handed me a short guide of "how to whip up a VFW-only" version, I'd give it a healthy shot and everyone would be happy again! :D

But even then, honestly, your optimizations are so dang good I can't hope to compete, ya know :D

[Sharktooth]

Well, i no longer optimize "to the bone" since some revisions coz some flags were causing problems.
However here's my configure and make commandlines:
./configure --enable-avis-input --enable-mp4-output --enable-pthread --extra-cflags="-I../gpac/include -march=pentium2 -mmmx -O3 -finline-functions -funroll-loops -ffast-math -fomit-frame-pointer" --extra-ldflags="-L../gpac/bin/gcc"
make fprofiled VIDS="../foreman_352x288.yuv ../coastguard_352x288.yuv"
nothing special, as you can see.
if you want VFW just add: --enable-vfw in the configure line but since the configure script was edited to remove VFW you need to get the VFW code from the SVN as well as the reversing the configure script prior to the VFW support removal then you can go...
Pretty easy, just make a script for that and you just have to type its name on the MSYS console command prompt...

... but im still sure ppl wont do it by themself...

[DDogg]

Might be a goofy question - I get the fact that it is time to move off Vfw, but is it theoretically possible for a VDub plugin, new internal code, something, etc., to allow Vdub to interface to a state of the art X264 of some type.

To put that differently, do we permanently lose the ability to use VDub with a non Vfw x264, or is it doable by somebody if they ever wanted to do it.

[Zero1]

Encoding isn't easy. No one said it would be easy. Of course for myself and fellow Doom9 members, encoding is probably second nature, so it's hard to remember what it's like being a beginner. Try to look from the outside in, back in the days when you encoded a video but it was blurry because you didn't know about IVTC and such.

Some people view Doom9 as a forum, elitist; and it's members elitist also. That may be true for some people, but I think that's an unfair comment. I think a more accurate word would be enthusiast. We are enthusiasts about quality, video compression and encoding in general, and as such we tend not to like regression and hacks/workarounds so that new standards and encoders may be used with old containers. In short it's counter productive.

The VfW-ites may view what pengvado has done as harsh, but I think it's one of his better decisions. He and his fellow developers are very proud of this work, it's efficiency and ability to give any commercial encoder (or professional, for that matter) a run for it's money. I can appreciate if he wants to dump VfW and keep it as professional and spec compliant as possible.

Now I say looking from the outside in; I can appreciate that not everyone can understand or learn encoding; some people simply can't take to something like that; that is why user friendly software like Nero Recode exists. You can still create high quality, spec compliant MP4 files with an easy GUI using Nero.

I think one of the main points, and something we tend not to think about, is the huge knock on effect these "hacks" can have. I mean look at MPEG-4 ASP; it's specified and supposed to be contained in MP4, but due to people being so attached to AVI and DivX wanting to create user friendly encoders, workarounds were created and AVI hung on for a few more years. Had we been using MP4 for ASP back then, no doubt MP4 tools and support would be much better than it is now (even though it is very good already). I also think that we would have some decent standalone devices, if things were done to spec.

As such, the format was neglected for a number of years in favour of creating workarounds for AVI; which is of course counter productive.

Yes, some of you have mentioned freedom of speech/choice etc. Well it's the devs freedom of choice to withdraw VfW support. That's how it goes in opensource, you take what is offered and be thankful for the time and effort put into the project; if you don't like it, offer to help, make suggestions where appropriate or learn to code yourself.

[Sharktooth]

Might be a goofy question - I get the fact that it is time to move off Vfw, but is it theoretically possible for a VDub plugin, new internal code, something, etc., to allow Vdub to interface to a state of the art X264 of some type.

To put that differently, do we permanently lose the ability to use VDub with a non Vfw x264, or is it doable by somebody if they ever wanted to do it.
Yes, you can load vdub plugin into avisynth.
However you can frameserve vdub output to x264CLI.
For both the "know how"s :search: ;)

[DDogg]

Yes, you can load vdub plugin into avisynth.
However you can frameserve vdub output to x264CLI.
For both the "know how"s :search: ;)Yep, I'll use search to find all my own posts and guides on those subjects - You know what I was talking about, wiseguy :)

[Sharktooth]

Sadly Vdub relies on VFW, completely...
You cant use directly a non VFW codec into Vdub.
However Avidemux is becoming a good alternative to Vdub.

[Romario]

Yes, Avidemux is good, but it's still not good enough.

Can anybody tells me how to use x264cli in terms of direct encoding via my TV card? Precisely?

[DDogg]

Sadly Vdub relies on VFW, completely...
You cant use directly a non VFW codec into Vdub.
However Avidemux is becoming a good alternative to Vdub.
Just trying to be part of a solution - Maybe if put our heads together we think of positive things to help people make the transition to cli. For example, cut-lists are a biggy to many VDub users and I know somewhere on this forum is a tool (by BB maybe?) to convert the VDub VCF project file into a set of trim statements for avisynth. Maybe putting together a small transitional guide with these type of things would be a positive outcome of this slight controversy. Perhaps this already exists and I have missed it. If so, give me a pointer please.

Here is the converter: http://forum.doom9.org/showthread.php?t=30587&page=2 I guess VDubMod 1.5.4.1 does not have the save edit list checkbox that VDub has, but 1.5.10.2 does

[Sharktooth]

Yes, Avidemux is good, but it's still not good enough.

Can anybody tells me how to use x264cli in terms of direct encoding via my TV card? Precisely?
No, for that you can continue using the actual x264VFW builds but frankly i would capture with a light lossless codec then re-encode lately with better settings...

[Romario]

Ok, Shark, thanks. Do you have any other idea.

For example, can you make an directshow x264 encoder. .

[Sharktooth]

Yes one. Ask milan to reintegrate x264 encoder into ffdshow while we wait for a proper capturing support in avidemux (or in other softwares).
DirectShow? it has its own drawbacks too...

[foxyshadis]

x264 was taken out of ffdshow because it was so old and had to be kludged in to make it work. We actually took it out because x264vfw was still there and doing a better job, maybe it'll have to go back in (hopefully more sanely, no modifying libx264 this time).

To clear up an earlier misconception, avidemux cannot split, save, open, or in any other way work with mkv files. If it was done in mp4, then it could be split up.

Avidemux's problems to me are mostly aesthetic; it has a generic linuxy/windows 3.1 feel to it, no matter what window manager you use. It's too big and busy (whereas virtualdub is too empty), and violates too many UI principles. If they could somehow convince phaeron to help, they'd be in business.

[DDogg]

Sharktooth, Ilike you said, MeGUI will open a VDub frameserved VDR file which is wrapped in an avisynth script using avisource. RGB24 of course, but I guess it is better than a sharp stick in the eye and it does work pretty well.

[d'Oursse]

Sadly Vdub relies on VFW, completely...
You cant use directly a non VFW codec into Vdub.
However Avidemux is becoming a good alternative to Vdub.

i've written a small interface to x264 in gtk. It's in svn. Someone was able to make it work with virtual dub and sent me his code.

I don't have a lot of free time, so there are not a lot of updates. But I want to maintain it. At least, it provides a gui interface on linux (I use it for avs3)

[DarkZell666]

After reading all this, I figured out it's a short-term loss for a long-term benefit ... (if new tools come out to replace the old ones ! easier said than done !)

Dinosaurs eventually disappeared so why not VFW ? ^^
It's all in the name anyway : video for windowsaurs =)

[Sharktooth]

Sharktooth, Ilike you said, MeGUI will open a VDub frameserved VDR file which is wrapped in an avisynth script using avisource. RGB24 of course, but I guess it is better than a sharp stick in the eye and it does work pretty well.
Yeah sure, but i think it's a bit complicated for the newbie.
Would you like to write a guide for it? I'm sure it will be added to the MeGUI wiki.

[DDogg]

Yeah sure, but i think it's a bit complicated for the newbie.
Would you like to write a guide for it? I'm sure it will be added to the MeGUI wiki. Sure, I already have most of the bits and pieces laying about the forum, just not tuned to MeGUI input. I don't know Wiki from Whacky so I'll just post it here someplace.

A base framework for someone to add and mod with more details. Not much to this:

1> Go to your Vdub, or VdubMod directory and run AuxSetup.exe. Choose "Install handler"
2> Setup Vdub or VDubMod as you always do except you will not need any compression. Just use video defaults.
3> File > Start Frame Server
4> Press "start" leaving name as is
5> A save dialog will come up. Name can be anything.VDR, but I prefer "Signpost.VDR" - Make a habit of saving it in the same place like C:\My_VDR_Files or such.
6> Verify all is working by opening another instance of VDub and dragging or opening "Signpost.VDR". You should see video.
7> Create a simple Avisynth script using - Avisource ("c:\My_VDR_Files\Signpost.vdr").converttoyv12() - Save this script as Signpost.avs and make sure if using notepad there is no .txt added on to it
8> Verify Signpost.avs plays in VDub, WMP, MPC
9> Open this script as your source with MeGUI
10> Proceed as normal
11> After finishing, It was always recommended to run auxsetup again and select uninstall handler
12> Send lots of notes to Sharktooth asking for MeGUI to natively open a VDR file (would need yv12 conversion in code of course)

Notes:
1> Somebody smarter than me will have to address the colorspace issue. Should the original script contain colormatrix? Dunno.
2> Once you set this up the first time and have created the initial Signpost.avs it is always reusable so long as you use Signpost.VDR as your frameserve filename and always save it to the same path.

[Sharktooth]

ok, thank you. Ill make sure it gets into the wiki ;)

[bananacreamandpeca]

its all so confusing, different builds, wich one was originally last non-tempered with, whats baseline, wich build wich company wich beta or alfa wich compile and wich source, whats vfw.

omg. im getting a headache

[Sirber]

http://encyclopedia.tfd.com/Video+for+Windows
http://encyclopedia.tfd.com/H264
http://encyclopedia.tfd.com/Source+Code
http://encyclopedia.tfd.com/Compiler

have fun!

[Sharktooth]

its all so confusing, different builds, wich one was originally last non-tempered with, whats baseline, wich build wich company wich beta or alfa wich compile and wich source, whats vfw.

omg. im getting a headache
Try with this: http://en.wikipedia.org/wiki/Suicide
sorry... i couldnt resist... :D

Jokes apart...
Well, guides are there for a reason... and this forum is a big source of knowledge.
All you need is time...

[Sirber]

Well, guides are there for a reason... and this forum is a big source of knowledge.
All you need is time...Time is money, which you can send to my paypal account :D

[bananacreamandpeca]

Try with this: http://en.wikipedia.org/wiki/Suicide
sorry... i couldnt resist... :D

Jokes apart...
Well, guides are there for a reason... and this forum is a big source of knowledge.
All you need is time...

Are you dutch???

[Sirber]

he's Italian

but let's not get personal ;)

[bananacreamandpeca]

Time is money, which you can send to my paypal account :D

Besides time theres a lot of patience needed.
And with all these threads and cross information and nerdy suff like all these abbreviaions.
Can you blame me for getting a headache just by the thought having to go through all that?
Im still going to do it ;)

Found an interesting source for video newbies yesterday:
http://www.animemusicvideos.org/guides/avtech/

pretty clear and very understandable.

[Sirber]

Well, I could teach you.

but it will cost ya.

that's right... all the tea :D

[DeathTheSheep]

Time is money, which you can send to my paypal account :D

Which one to send? Time or money? Because I can do time :D

[Sirber]

Which one to send? Time or money? Because I can do time :DWell, paypal currently doesn't support the currency "time", so if you could convert before using it, it would be great!

[buzzqw]

@d'Oursse
can you put in your sign the link to your (or where to download) gtk build ?

thanks

BHH

[DeathTheSheep]

Sharktooth: Your PM box is full :(

[ChronoCross]

Sharktooth: Your PM box is full :(

just the way he likes it if I remember correctly lol

[DeathTheSheep]

lol :D I guess it does save time to have it always full ;)

[check]

I mean, it's not like my entire 13-page guide with explanations and illustrations has in one day been rendered completely and utterly useless...

It hasn't. The options of the vfw are simply a subset of the options in the full CLI encoder. For example, see this that I wrote up: http://mewiki.project357.com/Video_configuration_dialog/X264_Configuration
Even thought one was written for vfw and one for CLI, there is a significant overlap.

Your recommendations are still useful for those using the CLI encoder, the only thing you need to change is updating images and adding options that didn't appear in the vfw interface.

[Sharktooth]

lol :D I guess it does save time to have it always full ;)
yeah... i should keep my mailbox full too...

[ChronoCross]

everyone should read this (New rules for vfw discussions):

http://forum.doom9.org/announcement.php?f=77

[DDogg]

everyone should read this (New rules for vfw discussions):

http://forum.doom9.org/announcement.php?f=77
Suggest #4 be reworded for clarity.

[Romario]

delete this please

[SeeMoreDigital]

How about: -

4) When someone asks for help with encoding using x264 VfW, do not belittle them with replies such as "why are you still using VfW" or "you should not be using VfW". Your replies should be positively structured to help the poster in his efforts. If not you will be striked for violation of rules 11 and 16. Which means you are just one strike away from being banned!

[DeathTheSheep]

SMD: I like that! I think it sounds good n' fair!

[Doom9]

@SeeMoreDigital: Rules and regulations have a tendency to be worded more formally, as well as more broadly. You won't find any forinstances in a lawbook either. That is because if you try to be specific, you always end up missing things and have to keep on correcting.
@Romario: It's a free world, nobody points a gun to your head and forces you to come here.

[Adub]

Well said doom9. Isn't it about time to close this thread?

[SeeMoreDigital]

@SeeMoreDigital: Rules and regulations have a tendency to be worded more formally, as well as more broadly. You won't find any forinstances in a lawbook either. That is because if you try to be specific, you always end up missing things and have to keep on correcting. Indeed...

However, some of what Bond has written doesn't seem to flow quite right. Most probably because English is not his primary language....

I'm not criticising, just trying to lend a helping hand.


Kind Regards

[DeathTheSheep]

When I first read rule 4, I got the following out of it (until re-reading it a few times):

"If someone is asking for help for encoding with x264 vfw, noone should answer.
Only try to convince the user to not use x264 vfw. The answers should always help the user with his efforts."

In fact, that's almost exactly what is already written, but with added punctuation. Perhaps this is the opposite of what was intended? I'm unsure.

But I think the new system is quite acceptable and I give it my [preliminary] support.
:cool:

[edit] I B COOL new thing B Better :P

[bond]

obviously wrong. i rewrote #4 and hope its now not possible anymore to misinterpret it (be it on purpose or not...)

[DeathTheSheep]

Thanks! Sounds good! :D

[Blue_MiSfit]

great idea guys.. I had a comment regarding rule 4 but it was changed... so nvm.

~MiSfit

[falcon2000eg]

thanks bond for the announcement i think it is very fair rules,it was a madness.

[leiming2006]

and doesn't come bundled with the required software either

Now there is a package containing the required software. XD

http://my.opera.com/leiming/homes/files/necessary.rar

[ChronoCross]

Now there is a package containing the required software. XD

http://my.opera.com/leiming/homes/files/necessary.rar


you should remove the nero stuff. Unless you have a distribution license else you'll probably be recieving a cease and desist letter lol.

[leiming2006]

OK. I know.
Thanks for the information.

[d'Oursse]

@d'Oursse
can you put in your sign the link to your (or where to download) gtk build ?

thanks

BHH

I have no build of the the gtk interface right now. Btw, do you want a Windows build or a Linux one ?

[buzzqw]

i use windows, but if you can mantain two build (one for linux/one for windows) is surely better

thanks !

BHH

[bluebebe]

it's so stupid that the x264 crew removed the VFW dll from the codec pack, very lame i mean! my future is not encoding some mp4 from command line, i take virtualdub for this works and now i must read that this is not possible in future, cause it's outdated, not comprehensibly.

ok can anyone send me pls the last build with integrated setup and vfw dll? with such a measure i dont counted.

the next lamest setting here: You have to be registered five days to post messages bla bla bla!

[SeeMoreDigital]

ok can anyone send me pls the last build with integrated setup and vfw dll? with such a measure i dont counted.

the next lamest setting here: You have to be registered five days to post messages bla bla bla!Hmmm!

With the kind of attitude you display in your very first post I doubt you'll obtain any kind of repect or the help you want :eek:

You should have spent the "five days" reading our forum rules!

[bond]

the 5 days waiting period was too long? now you got another 30 days

[Morte66]

Tell me, is there another x264 GUI that works roughly like VirtualDubMod? You preview your video, trim the start/end/adverts with a frame-accurate audio/video cut, and feed whatever is left to x264 + optional audio encode + mkv/mp4 muxer.

It seems to me that what people really want is the VDM style interface/workflow. VfW is really a side issue, if people could get VirtualDubMod functionality without VfW most of the aggro would stop.

So is there anything suitable out there?

[Sharktooth]

AVIDemux is similar to VDub...

[shon3i]

AVIDemux is similar to VDub...
Sharktooth please stop, telling us known things. Avidemux don't have 20% functionality of VirtualDub. Maybe latter have it but until now, simmilar editor like VirtualDub dosen't exist.

And some ppls including me have problems with gtk runtimes, maybe when some rewrite avidemux into c/c++, then maybe will get full funcionality over vdub.

I am happy with x264cli, and i dont need to edit x264 files.

Maybe Nero make some editor, or implement something to NeroVision, that will be probably best solution for editing mp4 files.

[Sharktooth]

What does it misses? There's only one major issue... capture devices are not supported.
But you can always use vdub and frameserve the captured frames to x264cli... oh, wait... you can do it even with other input files!!! OMG... :p

[check]

@Morte, this might be of use: http://mewiki.project357.com/wiki/Using_.vdr_files_as_input

[DarkZell666]

@check: sorry but I believe you missed the point. Morte66 does refer to an easy _visual_ GUI (before/after preview for ex.). The frameserving part is just as painful as using avisynth scripts, for lazy people at least ;)

I don't understand what Avidemux's problem is ... it works marvels for me, even on XP SP1 :p One thing though, the latest x264+aac in mp4 file I asked it for played über-fast in mpui :x

@Morte66: if avidemux works for you, go for it because it's as close as vdub you can get ... :) No need to mess around, just choose audio & video codec, output container, and get rollin' ;)

[shon3i]

What does it misses? There's only one major issue... capture devices are not supported.
But you can always use vdub and frameserve the captured frames to x264cli... oh, wait... you can do it even with other input files!!! OMG... :p
No whole, avidemux is totality miss for windows. I don't want disturb this forum with bulshits which is alredy sayed. I am not vfw sympatizer i just want some editor like virtualdub, nevermind is open source or i must to pay for them.

[Dayvon]

@ See More Digital

How is it coming with your use of MeGUI and remuxing to MOV. This is something that I could really use to solve too. There is no question that x264 is better at encoding than Quicktime compressor, and right now I make QT compatible MP4 files with x264 and Nero AAC using MeGUI on a regular basis. If you can figure a way to essentially convert MP4->MOV that would be a huge step for those looking for QT compatibility with x264.

[SeeMoreDigital]

Sadly I've not had much success with MeGUI at all. But to be honest I've not had much time to give it time (because I'm in the process of re-modelling our bathroom).

That said, when experimenting with StaxRip and AutoMKV I do now know Sharktooth's x264 "QuickTime" profile is able to generate compatible encodes for QT7 player... But only if you disable "b-frames" ;)

[Sharktooth]

Quicktime 7.1 supports B-Frames (1 or 2... but i keep 1 in the profiles coz i had discordant reports) in MP4.
That said, i dont know if muxing into MOV has different issues...

[Dayvon]

I'll add to that. I run with this commandline (from MeGUI)
--ref 5 --no-fast-pskip --bframes 1 --b-rdo --filter -4,-4 --subme 6 --trellis 1
--analyse p8x8,b8x8,i4x4,p4x4 --me umh --threads 2 --thread-input --progress --no-psnr --output
and get great QT results at low bitrates. Nearly identical to most of my full CABAC HQ x264 rips.
Of course, I am talking about these files in MP4 not MOV.

[SeeMoreDigital]

Quicktime 7.1 supports B-Frames (1 or 2... but i keep 1 in the profiles coz i had discordant reports) in MP4.
That said, i dont know if muxing into MOV has different issues...Okay... here's what I've experienced so far....

If I generate an .MP4 encode using your QT profile "with" 1B-VOP. When I feed it into QT7 and try and save it into the .MOV container.... I get this (ie: it wont save to .MOV): -

http://img289.imageshack.us/img289/1453/with1bvopvl2.jpg

But if I generate an .MP4 encode using your QT profile "without" B-VOP's. When I feed it into QT7 and try and save it into the .MOV container.... I get this (ie: it will save to .MOV): -

http://img289.imageshack.us/img289/7374/without1bvopsw5.jpg


Cheers

[foxyshadis]

Have you tried the mov muxer in ffmpeg? And are there any other mov muxers that might work?

[clsid]

The mov container is pretty much the same as MP4, right? Perhaps you can submit a feature request to the GPAC devs to add support for writing/muxing QT compatible movs.

[Romario]

http://gabextreme.googlepages.com/DTSUnited_x264VfW.exe

[Sharktooth]

Okay... here's what I've experienced so far....

If I generate an .MP4 encode using your QT profile "with" 1B-VOP. When I feed it into QT7 and try and save it into the .MOV container.... I get this (ie: it wont save to .MOV): -

***IMAGE***

But if I generate an .MP4 encode using your QT profile "without" B-VOP's. When I feed it into QT7 and try and save it into the .MOV container.... I get this (ie: it will save to .MOV): -

***IMAGE***


Cheers
Maybe the MOV container or QT MOV muxer do not support b-frames or maybe it's another bug in QT...

[foxyshadis]

Sorenson video definitely has b-frames, and normal mpeg4 asp in mov works okay. I vote "bug in QT" until further information, but that doesn't help if you have to work around it. =\

[Dayvon]

FFmpeg doesn't mux to mov. Ive tried it, I swear 1,000 times (on OSX) and it just doesn't seem to do it. QT definitely prefers MOV to MP4 btw, the splitting/decoding of QT is NOT that good. For instance, QT can't recognize and play 5.1 AAC files in mp4. I've also found these weird quirks of the first or last frame of a movie appearing white in QT and normal in over media players.

All in all, Apple needs to get QT a touch up. These problems have been around far to long.

[SeeMoreDigital]

Maybe the MOV container or QT MOV muxer do not support b-frames or maybe it's another bug in QT...I suspect it's an QT7 bug....

Also, it makes no difference whether I use VfW to generate x264 streams with 1B-VOP - they still wont save to .MOV....

Given the B-VOP .MOV muxing issue is consistent (across both VfW and non VfW encoding methods), might it not be prudent to change the current QuickTime Profile to default to "0" B-VOP instead of the current "1" B-VOP - Until such time an x264/QT7 B-VOP work around is sorted ;)

Thanks guys... I'm glad we've managed to make this B-VOP/QT7 issue much clearer.


Cheers

[bond]

there is no sense in using mov over mp4, as qt handles both the same way

[SeeMoreDigital]

there is no sense in using mov over mp4, as qt handles both the same wayThe reason why I have to use .MOV is because my clients need to add/amend the files "Annotations" and have them viewable in QT7 player when required.

Sadly, QT7 automatically saves "Annotation" alterations directly to the .MOV container :scared:

[bond]

what is annotation?

[SeeMoreDigital]

what is annotation?These are: -

http://img146.imageshack.us/img146/7752/annotationslu7.png

You can input separate and detailed information for the file, the video stream and the audio stream (necessary when offering "credit" info). Then there's the "Presentation" and "Visual" information....

My clients add/amend this information themselves as required (usually on MAC's), so it's out of my hands!


Cheers

[bond]

interesting stuff. :thanks:

[Selur]

since I tried it yesterday muxing with ffmpeg needs to reencode the audio stream

ffmpeg -vcodec copy -acodec copy -i Input.mp4 output.mov throws an error
ffmpeg -vcodec copy -i Input.mp4 output.mov
reencodes the audio but works fine (tried with newest ffmpeg build from celticdruid)

Cu Selur

Ps.: haven't investigated this any further since reencoding audio didn't bother me and the resulting files play fine in quicktime.