Log in

View Full Version : x264 development


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38

Kostarum Rex Persia
2nd March 2006, 03:18
BTW, can anyone explain to me what is GStreamer? Never heard for that.

ChronoCross
2nd March 2006, 03:20
BTW, can anyone explain to me what is GStreamer? Never heard for that.


it's called google. repeat after me. google.

http://www.gstreamer.net/

Sharktooth
2nd March 2006, 10:03
I am currious about this whole argument.
When people say "no vfw" I wonder what could we use as a replacement? I heard some one mention GStreamer, so I looked it up. It looks really promising, for my very limited knowledge of it.

Are there any others? Some maybe be developed by the brilliant people who populate this maginficent forum? What else would work, because I like my Virtualdub, yet I am starting to really like MeGUI as well.
Thoughts/Suggestions?
there is DirectShow (for windows). Nero Recode uses it for example... oh, IIRC gstreamer is developed by matroska guys...
correct me if im wrong.

bond
2nd March 2006, 10:24
ok as this is the x264 development thread my proposal to bring this topic back to the topic:

split the x264vfw windows centric code from the x264 svn and let vfw advocats take it over and develop it in an own project
just like other x264 guis (megui, staxrip, whatever), and x264vfw is only a gui and not more, are also developed in own projects

Inventive Software
2nd March 2006, 10:28
Bloody hell, I think I opened a can of compressed worms with the VFW mention.

My 2 cents: Firstly, VFW is still used quite a lot, and until a viable and WORKING alternative arises, I'll continue to help along the development. Secondly, the developers of x264 deserve to have a VFW implementation to give the masses what they want.

Inventive Software
2nd March 2006, 10:30
ok as this is the x264 development thread my proposal to bring this topic back to the topic:

split the x264vfw windows centric code from the x264 svn and let vfw advocats take it over and develop it in an own project
just like other x264 guis (megui, staxrip, whatever), and x264vfw is only a gui and not more, are also developed in own projects
Isn't that what sex264 was for? AFAIK development has stopped on this, as the VFW in x264 is miles better.

celtic_druid
2nd March 2006, 10:32
Not sure that giving the masses what they want is ever a good idea.

No one really edits AVC avi's via VfW do they? If they only use it for encoding then surely there are plenty of viable alternatives already?

Eretria-chan
2nd March 2006, 14:05
No one really edits AVC avi's via VfW do they? If they only use it for encoding then surely there are plenty of viable alternatives already?
If it works, then it works for me. I just want an easy-to-use GUI and no CLI crap. That's all I ask for. But no one seems to heed that :scared:

bond
2nd March 2006, 14:13
If it works, then it works for me. I just want an easy-to-use GUI and no CLI crap. That's all I ask for. But no one seems to heed that :scared:we have an own forum for x264 gui encoders that are not using vfw and virtualdub

read up before you post

Eretria-chan
2nd March 2006, 14:18
we have an own forum for x264 gui encoders that are not using vfw and virtualdub

read up before you post
I know that. But they are not VFW.
And I like vdub =)

bill_baroud
2nd March 2006, 14:38
so what ? with them, you choose an avs file, set the encoding options, and then encode. With vdub, you open an avs file, set the encoding options and then encode. Why the f*** do you want to use vdub ?
Setting encoding options is even faster in megui, there is less mouse movements to access them, so if you're really that lazy (because you doesn't want to change) you should use megui !

Sharktooth
2nd March 2006, 14:40
I know that. But they are not VFW.
And I like vdub =)they must not be VFW, since it's VFW that causes problems with AVC and unfortunately vdub is based on VFW.
so, it's only a matter of learning to use other tools instead of vdub.

edit: also with megui you dont even have to set the options every time, just use pre-made profiles or create your own ones...

Eretria-chan
2nd March 2006, 14:45
so what ? with them, you choose an avs file, set the encoding options, and then encode. With vdub, you open an avs file, set the encoding options and then encode. Why the f*** do you want to use vdub ?
Setting encoding options is even faster in megui, there is less mouse movements to access them, so if you're really that lazy (because you doesn't want to change) you should use megui !
Dude, there is a reason I use RA4. I don't know avisynth. I don't know CLI. I want to know neither. I just want an easy-to-use GUI that does it all for me.
I agree RA4 is pretty much all I need (because it handles everything for me), but that doesn't mean VFW is bad. If it works, then it is all we need. If it does not work, then we must use something else.
And I know vdub more than megui and other encoding tools.

bond
2nd March 2006, 14:50
realanime encodes with x264 to mp4/mkv without vfw/avi too :rolleyes:

Sharktooth
2nd March 2006, 14:53
Dude, there is a reason I use RA4. I don't know avisynth. I don't know CLI. I want to know neither. I just want an easy-to-use GUI that does it all for me.
I agree RA4 is pretty much all I need (because it handles everything for me), but that doesn't mean VFW is bad. If it works, then it is all we need. If it does not work, then we must use something else.
And I know vdub more than megui and other encoding tools.
well, you dont need to know CLI, avisynth or anything... megui has a script creator, creates the command line for CLI etc... for you.
just use the ONE CLICK ENCODER function and you're set up.
VFW creates non compliant files that can create problems for playback and for editing.
AVC is not supported in VFW and you may end up with unplayable files in a near future.
BTW, RA4 doesnt use VFW nor vdub... it uses x264 CLI...

Eretria-chan
2nd March 2006, 14:54
realanime encodes with x264 to mp4/mkv without vfw/avi too :rolleyes:
Sure, but I don't have to do anything. Just like VFW. No CLI and no avisynth - just like I want it.
And now I don't want to continue this discussion, so this shall be my final comment.

Sharktooth
2nd March 2006, 14:57
Eretria-chan... you're telling us there are programs just easy to use as vdub/vfw... so what's the problem??!?
RA4 is good and does the encoding the right way as does megui and staxrip...

Eretria-chan
2nd March 2006, 15:01
I suppose I can clarify to you a little :)
I'm AGAINST using CLI directly (eg typing a lot of options as a dos prompt). I'm AGAINST using avisynth directly (because there is hundreds of command which I can't possibly remember, plus I don't understand anything about what those commands do).
BUT, I don't mind using a program that handles it.
I'm not against those tools. But I'm not against VFW either.
I AM against, however, those who badmouth VFW. Because VFW works for me and I like it and it is easy to use. When I use VFW, I have no need for the "not supported" features so VFW is quite adequate for me.

Conclusion:
Direct use of CLI + avisynth = BAD.
Use of tools like RA or MeHUI = Okay.
Use of VFW = Okay (NOT BAD).

Sharktooth
2nd March 2006, 15:04
well, what im trying to say is VFW and AVC is a bad choice coz AVC is basically incompatible with VFW and even if the devs made some hacks to make it "work", it causes problems.
So, it's better to use other codecs with vdub (or VFW in general).

Eretria-chan
2nd March 2006, 15:07
If it works, if I can do what I need with VFW and AVC, I'm happy. That's all I need. Therefore I don't agree with your when you badmouth VFW. Sure, it may be old, sure it may require hacks - but it works! And it's easy!

If I need more advanced features, I would try some more advanced products.

bond
2nd March 2006, 15:11
it doesnt work correctly, and thats the point

you get a slight desync and you have missing frames (just two of the many problems)...

inform yourself before you mix yourself into such discussions, clueless newbies kicking in only lead to bad blood

Sharktooth
2nd March 2006, 15:11
you didnt understand... the advanced features are already in AVC and it uses it everytime you encode...
it's not safe to say it "works"...

Yong
2nd March 2006, 16:29
I suppose I can clarify to you a little :)
I'm AGAINST using CLI directly (eg typing a lot of options as a dos prompt).
There is someting called "batch file"(it just a text file),
it can execute alot of command at once as you defined in the batch script...
I'm AGAINST using avisynth directly (because there is hundreds of command which I can't possibly remember, plus I don't understand anything about what those commands do).
http://www.avisynth.org/index.php?page=AviSynthManual

imo a simple batch file isnt too hard to write. ;)

example(dgindex -> generate a simple avisynth script -> encode):

@echo off
IF '%1'=='' GOTO EOF
IF "%~1"=="%~dpn1.avs" (GOTO ENC) ELSE (IF "%~1"=="%~dpn1.avi" (GOTO AVI) ELSE (IF "%~1"=="%~dpn1.mpg" GOTO AVS))
:AVI
echo AVISource("%~1" ,false) > "%~dpn1.avs"
GOTO ENC
:AVS
IF EXIST "%~dpn1.avs" GOTO ENC
start /low /b /w D:\DGIndex\DGIndex.exe -IA=5 -OM=0 -IF=[%~1] -OF=[%~dpn1] -exit
rem 1=MMX, 2=SSEMMX, 3=SSE2MMX, 4=64-bit Floating Point, 5=IEEE-1180 Reference, "6=Skal MMX", 7=Simple MMX
echo loadplugin("D:\DGIndex\DGDecode.dll") >> "%~dpn1.avs"
echo mpeg2source("%~dpn1.d2v").Crop(0,56,-0,-56).hqdn3d() >> "%~dpn1.avs"
GOTO ENC
rem fps=23.976.Crop(0,64,-0,-64)..ChangeFPS(15)
:ENC
echo %date% %time%
echo Avisyth Script loaded:
more < "%~dpn1.avs"
set x=start /belownormal /b /w x264 -I 300 -i 30 "%~dpn1.avs" --progress
title X264 Encoder [%1]
%x% -B 600 --me umh -A none --filter -6:-6 -o "%userprofile%\desktop\%~n1.264" --bframes 0 --frames 500
echo %date% %time%
pause>nul:
:EOF

Eretria-chan
2nd March 2006, 17:00
I did use AVC in VFW some time long ago and it worked fine (at least it looked fine to me), so that adds to my argument. Although I don't use AVC in VFW so much because I let programs handle all the settings for me (RA), so I will not speak of it much.

As long as you get a file that can be watched, then it works, by my definition. And it has in the past. Dunno about now.

As for batch files, CLI & co: that is old school. That was used when DOS was around, and now it isn't anymore. The future is GUI. At least, that is what I think. I don't want to fool around with command lines or batch files and write 20 lines just to encode a file. And even the avisynth manual is confusing for those who don't know how video encoding really works.

In vdub, select the frames you want to delete and select edit -> delete. To resize, add a filter, enter the new size and select a method. What is good here is that I can see a preview of what the result will be with the specified resize method. Piece of cake. But not in avisynth.

But I shan't talk of VFW anymore since you only seem to bounce it back on me and it makes matters worse.

708145
2nd March 2006, 17:13
As for batch files, CLI & co: that is old school. That was used when DOS was around, and now it isn't anymore. The future is GUI. At least, that is what I think. I don't want to fool around with command lines or batch files and write 20 lines just to encode a file. And even the avisynth manual is confusing for those who don't know how video encoding really works.


mental arithmetic is old-school as well ever since people have calculators, right? :rolleyes:

My point: Both variants, CLI and GUI, have it's use. But this is independent of the VFW discussion!

edit: We should separate editing from encoding. For editing use whatever you like, preferably lossless keyframe-only AVI, but for encoding either use:
a) VFW to encode to an ancient codec of the pre ASP era (before 1999); AVI is fine here as well.
b) use a proper chain and container to encode to advanced codecs
But please don't bug developers with VFW support for advanced codecs. It is disturbing and annoying!

Adub
2nd March 2006, 17:33
Okay for curiousity sake, how would one go about designing a codec interface through Directshow? My guess is that it would look alot like FFDShow? If so, developers go crazy. I love FFDShow, and if it would replace VFW altogether that would be fine by me.

Am I wrong? Are there other designs for Directshow?

Eretria-chan
2nd March 2006, 17:38
@echo off
IF '%1'=='' GOTO EOF
IF "%~1"=="%~dpn1.avs" (GOTO ENC) ELSE (IF "%~1"=="%~dpn1.avi" (GOTO AVI) ELSE (IF "%~1"=="%~dpn1.mpg" GOTO AVS))
:AVI
echo AVISource("%~1" ,false) > "%~dpn1.avs"
GOTO ENC
:AVS
IF EXIST "%~dpn1.avs" GOTO ENC
start /low /b /w D:\DGIndex\DGIndex.exe -IA=5 -OM=0 -IF=[%~1] -OF=[%~dpn1] -exit
rem 1=MMX, 2=SSEMMX, 3=SSE2MMX, 4=64-bit Floating Point, 5=IEEE-1180 Reference, "6=Skal MMX", 7=Simple MMX
echo loadplugin("D:\DGIndex\DGDecode.dll") >> "%~dpn1.avs"
echo mpeg2source("%~dpn1.d2v").Crop(0,56,-0,-56).hqdn3d() >> "%~dpn1.avs"
GOTO ENC
rem fps=23.976.Crop(0,64,-0,-64)..ChangeFPS(15)
:ENC
echo %date% %time%
echo Avisyth Script loaded:
more < "%~dpn1.avs"
set x=start /belownormal /b /w x264 -I 300 -i 30 "%~dpn1.avs" --progress
title X264 Encoder [%1]
%x% -B 600 --me umh -A none --filter -6:-6 -o "%userprofile%\desktop\%~n1.264" --bframes 0 --frames 500
echo %date% %time%
pause>nul:
:EOF
How long did it take to write that example? That's exactly what I want to avoid. I do not want to write batch files to use with encoding. Using GUIs is much easier.

708145: Again, you also seem to miss the point, unless you typed wrong. ASP codecs with VFW works perfectly fine. I have done it many times. I have been able to encode/decode and even edit with mostly no problems. Which is another example of what I try to point out: If it works, then whatever it is, buggy, old or whatever, there is no reason not to use it, as long as it works. And with ASP codecs, if you hve not noticed, it works. And therefore I am happy to use VFW with ASP codecs.
Again, note, that even if it might have some limits, it has worked fine for my purposes, and thus it should not be excluded. It works and that is what an end user wants. Don't kill it! :scared:

And DirectShow scares me :scared:
It's so easy to b0rk. But when used properly, it works like a charm and it is easy to extend (NOTE: This does not include actually programming a new filter >_<).

bond
2nd March 2006, 17:46
there is no need for a directshow interface

x264.exe is perfect as it is, its portable, it outputs perfect files
and there are great guis even the dumbest user can use

so what else is needed?

yeah, dumb people not wanting to learn how to push the "start encoding" button in megui will never stop using vfw

708145
2nd March 2006, 17:54
708145: Again, you also seem to miss the point, unless you typed wrong. ASP codecs with VFW works perfectly fine. I have done it many times. I have been able to encode/decode and even edit with mostly no problems. Which is another example of what I try to point out: If it works, then whatever it is, buggy, old or whatever, there is no reason not to use it, as long as it works. And with ASP codecs, if you hve not noticed, it works. And therefore I am happy to use VFW with ASP codecs.
Again, note, that even if it might have some limits, it has worked fine for my purposes, and thus it should not be excluded.

Dear Eretria-chan,

please have a look at the posts earlier in this thread stating that ASP (with B frames) in AVI is a hack which needs support by every tool involved in the chain including decoder!

It made tools break which were correct but didn't include that hack! Besides it is becoming more and more a stretch to inlcude advanced codec capabilities like b-pyramid and the likes into AVI. Yeah sure it would work if developers would spend 90% of their time for supporting obsolete tech. Let them concentrate on improving stuff and learn to use a proper GUI instead.

A small related question: :devil: You obviously don't seem to be interested in advanced codecs so why are you discussing here at all. Just use AVI with MPEG1 and be happy. :angry: You miss all the advanced stuff anyway.


edit: I won't post about this topic in this thread anymore. This leads to nothing. Coding some ELDER instead :>

Eretria-chan
2nd March 2006, 17:59
I must repeat: it works, does it not? You can play files and encode and edit them, right?
I DO care for new techs. Let me tell you...
See, I don't think it is bad to use VFW for things such as ASP, so don't kill it! Obviously, in time, it will become obsolete because it doesn't support all the new advanced stuff, but... that is then.

Maybe you shouldn't use VFW with AVC... but that is a small problem since good GUIs like RA exists. But what for ASP? It works! It works! Let VFW remain for the sake of ASP, where it works.

And bond seems to hate everything but CLI and obvious GUIs like RA. That's a shame... why can't evenyone use something in their own way - like they want to?

bond
2nd March 2006, 18:03
you get a slight desync and you have missing frames (just two of the many problems)...read that a thousand times...

Eretria-chan
2nd March 2006, 18:14
Whatever... this is leading nowhere anyway.

JimiK
2nd March 2006, 18:57
Right, this is leading nowhere. Why don't you guys just let everybody encode the way he/she likes too. There is no law that everybody has to make good encodes. If people use VfW and are happy with the result, so be it. And just ignore all the "we need this and that in VfW" requests. If people that develop the codec feel no need to work on the VfW interface, than thats o.k. There are people that use VfW that are capable of extending the interface. When they do so, they can let others benefit from their work. If people want to use VfW and are not capable of extending it, well, then that's bad luck.
One word to the batch script of Yong: I don't think it took too long to write that. Compared to the encoding time of a 2 hour movie, such a thing is done in no time. And you can reuse it with slight alterations for your next encode. Some time ago, I was using a batch-script to encode some episodes of a series where all files should come out the same size. I also did cut the intro out. All I had to do was to tell the starting and end frame of the intro and the script cutted it out from audio and video and muxed the files in the end. So command line can be extremely helpful. By the way, Linux is one of the comming OS and with its commandline it's just faster to use.

ChronoCross
2nd March 2006, 19:14
Or we could just remove it and not have it cluttering up space in the svn. Just like I got rid of my windows 98 CD's so should we get rid of the vfw.

Revgen
2nd March 2006, 19:15
@Eretria-Chan

You really should be asking for better encoding tools, not codecs. Once there is a Vdub-like program that can cut and edit MP4 and MKV containers all this pro-VFW anti-VFW crap can stop.

I honestly can't understand why these two camps can't come together and find an editing solution that can work for everyone. The codec devs shouldn't be blamed for this at all.

ChronoCross
2nd March 2006, 19:28
Just typical. Someone steps in and says "everyone should agree," then someone comes and throws it down the recycle bin.
Ffs, this is just like company vs company who use DRM to hinder both users and other companies and demand that their own technology should be used.
Let people use what they like! Let developers create solutions like THEY want!
There is no right or wrong...
Though I am sure someone will come in and reply something the other way around and completely disagree with anything sane that is written around here.

ChronoCross's last reply was the most stupid and idiotic reply I've seen today. I give it a 10 of 10 in stupidity.


listen *insert bad word here* you haven't even given one good reason other than your a too big of a lazy *insert bad word here* to learn cli and avisynth. Meanwhile myself, sharktooth, bond have given technical reasons(read the million other threads on this) as well as future practical reasons as to why vfw support in x264 should be canned. but you vfw lovers and your "because it's easy" excuse we have to continue to listen to countless people wondering when support for new features will be added to vfw, or why doesn't my vfw encode work right, why is my audio, etc.

if your gonna call me stupid please read every other thread on this issue and then call bond, sharktooth, doom9 and others idiots as well because they have said the same things I have.

Revgen
2nd March 2006, 19:51
Here's an idea.

How about you guys delete your posts and PM each other. That way you both don't get striked by Bond. He's not here right now, so you both have time.

Eretria-chan
2nd March 2006, 20:00
That is a good idea. I retract my statement since it offends someone.

foxyshadis
2nd March 2006, 21:53
The last 4-5 pages should probably be split and merged into the vfw thread (http://forum.doom9.org/showthread.php?t=105929) instead. Really, discussing the topic is about as useful as abortion at a pta meeting, because no one changes their mind and everyone leaves angry anyway.

Kostarum Rex Persia
3rd March 2006, 01:46
Yes, Doom9, please split last 3 pages into vfw thread.

Zero1
3rd March 2006, 01:56
Bleeding hell, just accept that ASP + AVC in AVI/VfW is wrong and requires hacks.

There is a right way and a wrong way of doing this. Both "work", except the wrong way means you are restricted quality wise due to some missing features. Why not just do things the right way and have a HQ working video that no one will have (or should have) issues with?

celtic_druid
3rd March 2006, 02:38
I could always update the VfW code. Remove bframes, etc.

ChronoCross
3rd March 2006, 03:04
I could always update the VfW code. Remove bframes, etc.

yeah but really what would be th epoint of that? our whole arguement is that vfw limits the features and you just proved that. why settle for less features simply because your too lazy to learn the new stuff(not talking to you c_d, but to the vfw people)

celtic_druid
3rd March 2006, 04:25
The point would be that it would work. No lag, no dropped frames. No more arguments.

leowai
3rd March 2006, 07:18
The point would be that it would work. No lag, no dropped frames. No more arguments.
This make me thinking of the someone is driving a ferrari on an uneven country road with extremely limited speed. Yes, it runs on the road and it's OK if that's the only feature he/she really needs from that ferrari.

Now, why don't we drive that fantastic car on the high way with its full power? If you've never tried the full potential of the car, would you know how much the car is considered "wasted" when it has been only used on the country roads?


*For those who don't know what ferrari is, please simply ignore this thread. :D

celtic_druid
3rd March 2006, 07:59
I'd still rather have an NSX-R GT. My point is that is basically how it is currently with VfW. If you want the Ferrari, then you don't use VfW.

SeeMoreDigital
3rd March 2006, 10:14
I could always update the VfW code. Remove bframes, etc.Most of my tests with MPEG-4 AVC have been without B-VOP's....So I think it would be interesting to have a "no-frills" version of the x264 encoder.

By-the-way, what is the correct term to refer to an AVC codec which does not offer stuff like B-frames, Qpel, etc.... Is it "baseline"?


Cheers

Sharktooth
3rd March 2006, 10:27
Cripled.
At that point is better cutting off VFW before ppl start to say x264 doesnt support b-frames and other stuff...

bond
3rd March 2006, 10:49
microsoft also doesnt allow using b-frames in their wmv9 vfw encoder, cause they know avi and vfw simply are not useable for b-frames

apart from that using avi not only sucks because of vfw but also because of the lack of interoperability
what we see with the mpeg-4 asp mess is that avi causes a pita as every decoder needs to support specific codec stuff (like different fourccs and other codec specialities)
if people simply use mp4 or native mkv that mess problem is totally gone and interoperability is reached

there are so many arguments against avi/vfw i guess i should write a summary or so :D

SeeMoreDigital
3rd March 2006, 11:11
Cripled.
At that point is better cutting off VFW before ppl start to say x264 doesnt support b-frames and other stuff...Taking this point further.....

If we don't want the same mistakes to occure with MPEG-4 AVC as it did with MPEG-4 ASP in AVI, then I agree, development in the VfW encoder should either totally cease "or" just a no-frills baseline encoder should be offered.


Cheers