FFMPEG: lastest build - ffvfw-20041301.exe
 

Ok, ok, I am so honored to be with you tonight to accept my award. First, I would like to thank my mother – taught me persistence by the way she made me wear my raincoat even on hot summer days without a cloud in sight. Secondly, I owe a debt of gratitude to my dog Sparkle……

Ok, enough funny business. I have a question to ask all of you. How many reading all of the posts just accepted the fact that ffvfw crashed on 2nd pass encoding? Or even better yet, tried it one time, saw that it immediately crashed, and did not do anything more? For a while, I to accepted ffvfw’s fate. But, not anymore.

First, I want to make it perfectly clear. I am using the lastest build - ffvfw-20041301.exe? I do not want any confusion about that. Secondly, I can honestly say that the two pass process works perfectly. You must make sure that the path of the stats file is a real path on your computer (the default value is E:/ - but since I do not have a E:/, the program crashed). When performing the second pass, look what I discovered – MAX BITRATE!!!
:ole:
Bitrate problem solved!!! Also, the process works by determination of the target file size - after several tests – the target was right on target – so in some way – bye bye file size prediction!!! (I really hate setting the final file size as constant - so I propose some way to use the first pass file to determine the final size of the second pass file - that way streams are teaked to how much data they need)

Several observations that I have made, allowed me to conclude that ffvfw really did not know what the hell it was doing. I would have huge Q spikes AFTER the bitrate increased – allowing me to believe that the program was reacting so slowly to how the bitrate was being encoded – kind of encoding blindly. I realized that the second pass must work – otherwise the encoder was real garbage.

Another observation, some of you stated that that program was buggy – however I can honestly say that after twenty different encodes (with hundreds of different setting combinations) (oh, I know to some of you that does not sound like a lot, but I just started testing last Friday), I have never had the program crash in any way – not once – in my opinion the program is as stable as a rock.

Another observation, H.263 works perfectly. Try it!! I have encoded with H.263, brought it into TMPGenc DVD author and it recognizes it as a mpeg stream. Marcellus persistence stating that the program worked in H.263 allowed me to believe that it does work, despite Kwag’s instance that it does not work. (Donde esta el maestro???) We need to find how exactly how it works, and what it actually does. Logic tells us that the encoded file will not be recognized as mpeg, but it is!!! I have noticed that in every case of encoding with H.263, the file is always bigger.

Another obervation, this encoder wants the Q level to change. Marcellus explains this best:
Thanks Marcellus!!!

CONCLUSION: It seems to me that this is the way the program was designed to work. It might be possible to get Xvid quality in mpeg (once we treak the settings). Furthermore, as far as I am concerned; TMPGenc and CCE are just old junk...

I hope that everyone is on the same page as me (test it!!) and sorry, for the earlier questions. But, I have to start somewhere...


Stats:

KDVD creation (~5 hour DVD)

Number of frames: 73,086
Time: ~50 mins
Resolution: 704 x 480

First pass size: 1,598,978 KB
Average Bitrate: 4,024
Bitrate Peak: 14,762 (ah, the old peak problem)
Q level: 2 (solid as a rock)

Second pass size: 748,324 KB (target size of 750 MB)
Average Bitrate: 1,883
Bitrate Peak: 6,269
Q Level (average): 3.97
Q Level (peak): 6.21
(yes, the Q level changes - as it should)

Aviscript used (bit heavy on filtering):

Re: BREAKTHROUGH!!!!!!!!!!!!!!!!!
 

NO NO and NO :!: :twisted:
You don't get it, do you :?:
You are encoding MPEG-2. Not H.263 :!:
If you had encoded H.263, you COULDN'T import it into ANY authoring program.
Read the H.263 specifications:

http://www.cs.ccu.edu.tw/~cwlin/cour...s/h263plus.pdf
http://www.ece.utexas.edu/~bevans/co...ion/sld001.htm And again, H.263 doesn't work on MPEG-2 decoders.
You're encoding standard MPEG-2 :!:

Edit: This will probably make more sense, and be more clear: http://www.ece.utexas.edu/~bevans/co.../FinalTalk.pdf

-kwag

ok, ok, forget about H.263 (it is a side issue anyway)...

What about the rest????

Second pass doesn't work for me.
At least, in the sense of target size.
My target drive was K:, and I changed it to F:, and now I don't get a crash. Weird, but it works :roll:
But I get the same size after encoding 1-pass, and same file size on the 2-pass.
Can you post the screenshots, for the parameters you used on the 2nd pass :?:
Because I can't reproduce what you did.

-kwag

Sounds like a start, oh, I forgot to mention that I used Virtualdubmod 1.5.4.1 Let me see, I used the default settings...trying to keep it as simple as possible.

Make sure the stats file that it creates on the first pass has a proper directory. In the two passs tab, I used "D:\video.stats." I used max bitrate - 9024 kbits/s. I also set output to raw frames, becasue using this it seemed to me you did not have to mux it later.

I used second pass int....

let me go in order -
Generic - 18/1 (your settings)
Motion estimation - (your settings)
Quantization - H.263 Min Q = 2, Max Q = 25 (rest was your settings)
(just tried your notch matrix - worked fine)
Masking
Ratecontrol
Credits
Two passes - 1st pass "D:\video.stats."
Two passes - 2nd pass"D:\video.stats." max bitrate = 9024 kbits/s
Curve compression - defult
alt. compression - defult
(have also tried "high - sine curve")
Output
Store frames to external - raw frames

sorry for being verbose- but I want to make sure you are using the same settings....

8O
That setting is only enabled on One pass constant bitrate :!:
There's no "bitrate" setting on the "two passes - 1st pass", which is what's supposed to be used for a 2 pass encode, because the 1st pass is supposed to be an "analysis" pass :!: That's the way I have it set too.All about the same, but I set MAX bitrate on the 2nd pass to 5,000Kbps, and still, the MPEG encoded is the same file size, either on 1st pass or 2nd pass, with bitrates above 7,000Kbps :roll:

-kwag

The first pass is an analysis, but it also creates a file - a huge file. Make sure the file names are different in the two passes!! (that might be the problem) - I don't think that the program can write over a file - it will just crash!! At the end of the process, I am left with two files - one first pass huge file and one smaller second pass file.


Not sure what you mean - just forget about one pass - I am only dealing with two "mode" tabs - 1) "two passes - 1st pass" 2) "two passes - 2nd pass int". The slider bar at the top of "two passes - 1st pass" is grayed over (like it should be), in "two - passes - 2nd pass int" you can pick the size of the final file.

Just noticed that my FOURCC is MPEG - not MPG2 - (that should not matter though)

Ratecontrol is completely grayed over

I did not enable picture processing w/ ffdshow




[/quote]

Never mind, it was my stupidity :!:
I had MIN and MAX Q all set to "2" :x
Anyway, I'm encoding a second pass, and now it seems it will be on target ( a sample ~12,000MB )
Anyway, you might as well leave the quantizer set to MPEG2, and not to H.263, because the result is identical, anyway you set it.
The "master" format is really driven by the primary setting, in this case MPEG2.
There's no effect changing the qualtisizer from H.263 to MPEG.
Anyway, there's a problem with this encoding scheme, and it's the VBV buffer size :!:
I just got a value of 14 on the encoded sample, and that's unuseable for DVD purposes.

-kwag

GOOD!!!

damm, forgot about the VBV issue - I am going to burn a test DVD-R to satisfy my persistance...

ok, just burned a DVD-R...and it plays perfect!!!

Tested on my piece-o-crap Malata....

I think the problem might rest with Biterate Viewer....

Kwag...Can you recommend some optimal settings on the second pass encode?? What you might suspect would give good quality...like which curve aggression is best....some of the percentage values....just off the top of your head - what you think might be the best...I am going to start trying to fine tune the second pass...

Do you think that it might also be possible to use another program to modify the stats file??? I know for Xvid this is possible...

Poerschr,
As I told you more than once I give BV some very good credit these days, and I assure
you others will have problems playing the files with such low vbv buffer :twisted:
Or else let's just wait 48h untill others have the chance to try it out too.
I'm saying this because I prooved it here.
I was having some doubts about VB too so I went to a store and tried it.
Besides my cousin's player had issues too!
Nevertheless, indeed it seems you have made some real progress.
For that I have to congratulate you.
Cheers

hi poershr, congratulations on your findings

I'm glad that I'm not the only one who has a "freaky" player able to crunch what ffvfw outputs. So I guess you could use my sticker :D :D :D
http://marcellus_vcd.tripod.com/FFVFW-compliant.jpg


I tried also myself sometime ago 2-nd pass encoding. Worked perfectly for me also, no crash, but since the general opinion here was it crashes I didn't start an argument about this. I don't like to enter myself in arguments and besides I presumed that is has something to do with the fact that ffvfw isn't finished yet. I heard some people here saying that ffvfw performs completely diferent on diferent machines so I assumed that "genenerally" ffvfw crashes on second pass but "particularly" in my case doesn't.

Now I'm starting to believe that there are few people here up to test for themselves, many just take for granted what Kwag says and ban anybody that doesn't follow the "official line". It's natural since Kwag has a great aura but I think anybody can be wrong sometime.

Anyway I'm not so interested in 2-nd pass encoding myself since it doubles the time needed for any encoding, for myself the "constant bitrate" stuff do the job.

One observation: it's true that you can set the max bitrate in second pass but ffvfw takes the value you set there as an orientative value, since in my experience it passed over that value in the real encoding. It's true that not by much, but it did.

Bye
marcellus

READ THIS :!: (go to first reply of mine)
My only problem was (as I know this now) that my quantizer values was set sharp to 3 (AFAIR).

Also now I can tell that this speed notes aren't proper. This is related to avs script in my case.

And one more thing I can say, is that in low bitrate movies I get beter results (read=quality) with MPEG1. I'm not doing KDVD, so MPEG2 is useles for me (yes, I've tested both MPEG and H.263 quantization types).

Hmm, nice post. It's a pitty some comments, not really necessary.
I DO my tests, and share results, positive and negative ones, because every result may be useful for all of us. Little time, little tests. But when I post, I can say what I tested and what I read or heard. I think everybody knows the difference between test and read.
Discussing somebody arguments or results... is it so extrange?. How do we get results, taking things for granted, or testing and discussing?. I think that for all of us a good argument is convincing, and a positive result something to test and confirm.
Of course, there is more experienced people, with more knowledge, whose statements maybe taken more into consideration, also extrange?. That doesn't mean blind following of statements, things are always explained, and if an explanation doesn't convince you, you can ask for another one. And at last, you, everybody is free to test whatever, even if nobody supports ones idea. Little of us are posting (I suppose that more people is testing, but little is posting) on mencoder, and what?. I don't feel banned for foolowing a track that isn't an official one, if this really exists.
We may be very happy with last advances in ffvfw, that I think never was banned, neither the way is now being used (2-pass).
Congratulation poerschr :D , let's see if we can improve it, its speed, and the VBV issue (I do have problems with my player with low VBV)

Hi Marcellus,
Strong words, or shall I say strong thinking, if I might say.
I've been saying here and I will repeat myself countlessly that I have at least 2 standalone players that don't like such low vbv when trying to mux as DVD. Plus, lot's of messages on bbmpeg...
Now, when I tried it at the store (not really a store, more like an Hi-Fi/Video section at the supermarket) I perfectly remember trying it on at least 8 different models and 2 of these failed to reproduce the clip.
Other 2 read it but with lots of blocks appearing in the image.
I say those were macroblocks that wouldn't belong to the picture, with strange colors inside(white,cyan,etc) like if the muxing had failed.
This even happened on an almost still picture :roll:
So even if this is a big percentage of players that can read it, it ain't certainly 99% :evil:
I am a big enthusiast of libavcodec based encoders, otherwise I wouldn't have started the mencoder 4 windows thread with a few other guys here.
I am thrilling :D with the results posted by Poerschr but I must ask for more testing from other guys out there.
Thanks and C ya all tonite

Note that perharps these standalon just can't play KVCD and that is not related to VBV buffer.

I agree with you that Marcellus is a little too far when saying few people do test.
All peoples that actually post a lot here (Inc, digitall, kwag, you, me and others that I surely forget...) we ALL DO much more tests than anyone here before responding to a thread.

(that's also why I didn't post in all ffvfw thread recently, as I do not make test these days ;-))

Hmm,
Interesting Phil.
Back to the basics because maybe I am mistaken.
A true compliant PAL DVD stream would have to comply amongst other things with:
- MPEG2 stream with 720x576 or 704x576 (I know there are other option for MPEG1)
- VBV buffer=224
- GOP size=15
This should be +/- enough. The rest is done with the muxing, right?
Now this stream is suited for both SVCD or DVD. I only have to change the VBV to 112 or 224, right?
Again the rest is taken care by the muxing, right.
If so it shouldn't be a problem with the standalone not being able to play KVCD since I'm doing KDVD which should be ~99% compliant with DVD, right?
So what am I missing?
All my tests with ffvfw or mencoder have been based on KDVD stream, not KVCD, because both my standalones refuse to play KVCD (odd thing BTW).
Though they play all KDVD produced with both CCE/tmpg/mencoder and last but not least ffvfw as long as I keep the vbv at 224.
If I'm assuming something wrongly, please correct me.
If not, I am convinced that vbv=14 is not enough for ~20% of the players I tested so far.
I hope nobody feels offended with my words. :)
I just like to keep it inside the standards as far as I can so I can visit my folks and carry some movies for a nice "Holiwood" evening. :wink:
Cheers everyone

Maybe is not the proper thread to bring this up but how am I supose to feel when I asked kwag an opinion about H.263 quantization and all I received was theory and nobody bothered to test this stuff an say: "Well, I tried it, I looked at the result and I can say that it does (doesn't) anything". The only feedback was from Kwag and everybody else didn't move a finger. Or at least didn't post anything but theory crap (in poershr's thread), like such a thing is impossible and so on, in kwag's aproval warm shelter. Escuse my french, but some people here are so lazy that let Kwag do all the stuff, ask him for opinion on anything and the man is only a man with 24h like everybody else. He can't test everything, he skips probably some ideas because he doesn't believe in them, but NOBODY in that particular case took the time to look into it.
At least, Poershr, that everybody huried to ban that he doesn't do tests, asked himself about it and didn't swallow it already chewed.
So, if you don't want to test a thing and you only assume the result at least keep quiet and let anybody say what has to say.
BTW, my point of view about "constant bitrate" algorithm was finally seen yesterday by rds_correia, but the same idea I exposed about a month ago and was passed as nothing because Kwag wasn't enthusiast about it. This tells pretty much.
Sorry to be so agressive, and I hope we are still friends:D
marcellus