02-20-2004, 09:50 PM
|
Free Member
|
|
Join Date: Feb 2004
Posts: 45
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
I apologize for starting a new thread…however, I seems to me the best way to bring this insight to attention. If you would like, I would add my comments to the appropriate topic.
It seems to me that ffvfw is becoming a great little tool...however; the encoder contains a small flaw that has caused it to escape further scrutiny. Approximately 20% into the encoding process, ffvfw establishes a solid and straight Q line. It seems to need some time to find the best settings, thus making tests with small sample files useless. This is the reason why many have not had very positive results because only samples were used. If you used the full file, it seems to me that after a while the Q line stabilizes.
Marcellus found something similar in his post.
Quote:
At the beginning the encoder does not respect your setting regarding the bitrate, using a very large quantizer value. But as the encoding goes on it self adjusts to a more apropriate value (by lowering the quantizer) and in the end you will have a right sized file. As a result, the quality at the beginning of the movie is poorer for a few minutes (it has a lower bitrate than needed)
|
(One should note that he was mistaken about the bitrate setting – but that hardly matters here)
Also, incredible reported something similar in his full encode of the movie “The Core."
Quote:
Also, has anyone taken a look at the following:
I know that this guy is coping some of kwag’s discoveries. I thought that some of his findings were interesting. - nevermind
|
Someday, 12:01 PM
|
|
Site Staff / Ad Manager
|
|
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
02-20-2004, 10:05 PM
|
Free Member
|
|
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by poerschr
This is the reason why many have not had very positive results because only samples were used. If you used the full file, it seems to me that after a while the Q line stabilizes.
|
That means that quality of begining of any video will be bad, and at least, won't be the same at all that the rest of the movie.
And you call THAT a good encoder ?
Quote:
Also, has anyone taken a look at the following:
|
Nope. Avalon was banished from this board for unfair behaviour. So no link to his site their, please.
And Avalon didn't find anything, he just made test upon our discoveries and has already dropped ffvfw for an other encoder, exactly when people here dropped it also.
Just try to make an encoding with Q=20 as he claims to have done and do not be surprised to never obtain the quality of the snapshot he provides.
Forget this poor guy PLEASE !
|
02-21-2004, 04:26 AM
|
Free Member
|
|
Join Date: Dec 2003
Location: Omicron Persei 8
Posts: 322
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
In fact, Phil, I'm still using ffvfw. I don't se this "lack of quality at the beginning" cause I set a hard fit quantizer value to 3-3 or 2-3 (in large movies 2-4, but I don't do them often). I make great results, no bitrate overating. Why you'll ask? Because I find this encoder very usefull to do my VHS backups. They are in 352x288, and with low motion scenes in 3/4 of the movie I get no peaks above 2500. In fact with low action moves even with SVCD resolutions it gets pretty good quality (pretty good = the same as with TMPG, some times beter). But personaly I don't sugest this encoder for backups of DVD while it is still wild, and hard to bridle, and you won't get good quality as simple as with TMPG.
As for full clear up, I do encodings with MPEG1 and standard matrixes, while ffvfw produces very poor quality with Notch matrixes.
EDIT: As for this ****** guy, perfect Q=20 setings, I can only say
__________________
Go for SECAM =)
|
02-21-2004, 10:37 PM
|
Invalid Email / Banned / Spammer
|
|
Join Date: Feb 2004
Location: Bucharest, Romania, GMT+2h
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hi everybody!
Well, I didn't made a post for a looong time, I feel a litle bit rusty so I will be looooong. So beware!
@poerschr: I'm glad that I'm not alone noticing the way this encoder works.
Quote:
(One should note that he was mistaken about the bitrate setting - but that hardly matters here)
|
I'm not sure how I did mistake about the bitrate, so I would be very happy if you would be more specific.
For me it's pretty much clear that FFVFW has a simple but effective way to "guess" how much quantizing has to make in order to end up with a right size in the finished file.
At the begining it starts up with a quantize value that it "thinks" will do the job. After a while it looks at the medium bitrate that it has so far. If that medium value is higher than the bitrate we set, then it slowly pushes "medium quantizer" higher, if it's smaller it does the opposite. By "medium quantizer" I mean a sort of tendency to choose quantizer values around a "medium" value. I think that absolute differece between actual medium bitrate obtained "so far" and the "desired" one gives the value of the "pressure" to increase or decrease the "medium quantizer" value.
Now, if enough content has been encoded already and the medium bitrate obtained is very near to the desired bitrate the "pressure" to change the "medium quantizer" is near 0 so the quantizer value become almost linear.
Again, if some change in the character of the movie occurs and it becomes more bitrate demanding, after a while the absolute difference between the medium bitrate obtained so far and desired bitrate increases so the pressure to increase the "medium quantizer" also grows. So the quantizer line will go up.
Anyway, the final result IMHO is very good and pleasant to watch on tv comparing to tmpegenc at the same bitrate with all the fluctuations in q value everybody make such a big fuss about.
B U T
For that algorithm to work the encoder must be free to choose what quantize value it needs. If I put a small maximum q value the medium bitrate will always be higher than the chosen one, meaning a constant pressure to increase the q value and a barrier that stops it to increase. The result: a "good" straight line in the graphic, at the limit I put in settings. The price: a wrong final file size and insane maximum bitrates. No offence but this modus operandi seems to me completely wrong and any complaints laughable. It's like complaining that you can't shift gears in your newly bought stickless car the way you were used to.
To be more specific I think that many of us are too much used with the way cce and tmpegenc work and want to make FFVFW work the same way with a lot of headache and no rewarding results. We have to chage the way we are used to do things, or we'll end up drinking from the toilet because we think is a sort of fountain. I'm sorry if I offend somebody, I'm reffering to a common way that people (me included) sometimes react to changes and progress.
As for the VBR/Over-DVD bitrate issue, well, it seems a real flaw but I can't say anything usefull, because I don't have the proper equipment to test it. Anyway, DVD back-up it's out of my range of interest for the moment.
@Dialhot & Hydeus: The problem with poorer begining quality (BTW I don't have it anymore due to some new settings I use) was perceivable only on the monitor (hardly on tv) and it was anyway insignificant. (I don't intend to make masterpieces anyway, an analogically broadcasted signal is already FUBAR comparing to any DVD). At the time that issue was for me a small price for a corect sized good quality final file, without the hassle of prediction, multiple passes and so on. And it made cce and tmpegenc look like jokes at 700 kbps.
Later I found some settings that made me even happier (sorry, I only put links, my free hosting site doesn't seem to like that use of it's space):
My settings are (for 352x288 PAL, heavily denoised source):
Generic tab:
Motion estimation tab:
Quantization tab:
That way the quantization is the same for I, P, and B frames, getting rid of fluctuating quality with the GOP size issue. Values of 1.00 give an error so I tricked it with 0.99 and 1.01
Masking tab:
built-in values
Ratecontrol tab:
Here the value of 1 means actually 100%, I think is a flaw in interface.
With those settings (the latest I discovered to give good results for me are those in ratecontrol tab) the bitrate viewer says something like that (at various moments, as you can see from the screenshots):
Right at the beginning:
http://marcellus_vcd.tripod.com/bitrate1.gif
Afterwhile:
http://marcellus_vcd.tripod.com/bitrate2.gif
http://marcellus_vcd.tripod.com/bitrate3.gif
At the end the q line is straight. Total time for the movie is ~45 min. (2 Seinfeld episodes)
It seems that with those settings the encoder has the tendency to change q rate very slow and to stay longer at a specific q level. With those settings I obtain good quality encodes even with animation (Mission Hill series) at around 570 kbps (8 episodes on one CD - about 175 minutes with 56 kbps mono audio). At such bitrate both cce and tmpegenc give laughable results (even cce with 4 pass encoding). So, for me, is a big Bye Bye for those two.
Beside my Seinfeld daily encodings in the last weeks I succesfully recorded three movies from Star Wars series (and tomorrow I prepare for Episode 1-Phantom Menace that my favourite station will broadcast). I am very pleased with the results, the only issue I have is the blockiness (mostly unnoticiable on tv) in less detailed areas (as snow covered landscapes in "Empire strikes back") and I blame for this the value of 2 as a minimum quantizer. To put some noise in the source is very ugly at 352x288 because is already very little information in the frame to eat it away with noise. Any noise is simply too "big" at 352x288.
So long
marcellus
|
02-23-2004, 01:42 AM
|
Free Member
|
|
Join Date: Feb 2004
Posts: 45
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hello..marcellus....
Yes, I have not given up on this encoder. Kwag mentioned in one of his earlier posts that the bitrate setting was not actually the bitrate setting. It was for setting the VBV. However, this finding seems unusual to me because you have been encoding with a bitrate value of 720 for a long time, and you have not had any problems. If bitrate was actually a setting for VBV, then I think that your VCD would skip alot, but you report that they do not.
Also, what kind of matrix are you using?
Also, I am curious about your settings, however none of your graphics work becasue you have not set them for outside permission. Can you change that?
|
02-23-2004, 08:06 AM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
Poerschr,
We're all here to share experiences but since I've read your posts all around I've seen that you didn't mention much testing by yourself but you keep questioning everybody's experiences.
I might agree with you on one thing though, and that's about the slider for bitrate being the vbv buffer setting.
I find it hard to believe that Milan thought of that slider for the vbv buffer but I can't argue with anyone that in fact it does change the vbv buffer figure.
That's why I didn't questioned Kwag's report.
I myself think that either the encoder is screwed up or we don't really know how it works.
But unless I got a good testing that support my theory I'm not going to question any of the guys here.
Please bear in mind that according to Marcellus postings he is using a TOO very LOW vbv buffer value, perhaps vbv=7, and although he can play it correctly on his standalone most of us wouldn't even see the first 10 seconds.
If you don't believe us feel free to test it on several standalones and see what happens.
Hope I helped.
C ya
__________________
Rui
|
02-23-2004, 09:43 AM
|
Free Member
|
|
Join Date: Feb 2004
Posts: 45
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
I just downloading the program last Friday, so my testing has just started...So far the Q line has been completely stable...however, I have gotten the bitrate spikes reported by others...
It is my opinion that we do not know how that program works 100% - I find it hard to beleive that marcellus' player is all that good - logic tells me the simpllest explaination is the answer - Does marcellus have some unique player? No, it would rather be that we are not inprepreting the data correctly.
Marcellus, what is the name and model number of your DVD player?
|
02-23-2004, 10:07 AM
|
Free Member
|
|
Join Date: Feb 2004
Posts: 45
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
I take that back...they were not really bitrate spikes..but rather more deliberate, more like bitrate mountains...
|
02-23-2004, 12:27 PM
|
Invalid Email / Banned / Spammer
|
|
Join Date: Feb 2004
Location: Bucharest, Romania, GMT+2h
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@poerschr
Quote:
Also, what kind of matrix are you using?
|
Well, I'm using H.263 quantization type (whatever that means) because it seems to give me better quality and that way the encoder always uses standard matrix.
Quote:
Marcellus, what is the name and model number of your DVD player?
|
I didn't know that my player is so special. Is a sony dvp-ns 330. It's not free of issues. Actually I never could make a SVCD with starting menu that this player could play (but I never use menues or chapters so it doesnt bother me) . Also it plays SVCD with stuttering but if I mux and burn mpeg2 as VCD the stuttering is gone (also it sees menues). Also it plays the sound before the image by about 175ms so I mux the tracks delayed. (this problem occurs only in VCD snd Svcd, not DVD).
Hope I was helpfull
Marcellus
|
02-23-2004, 03:37 PM
|
Free Member
|
|
Join Date: Feb 2004
Posts: 45
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
The issue with you DVD player was the fact that it supossedly was playing VCDs without a correct VBV. I remember that Kwag stated something like, "you must have some special player", however I can see that it is not a special player afterall....
I think that part of our problem might be a relyance upon Bitrate Viewer...
Marcellus....check your inbox, I sent you some mail....
|
02-23-2004, 06:48 PM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
@Poerschr,
Man, you really can't give up, can you? Sometimes that's a quality...
I'm usualy a very stuburn guy, too.
I say you should try burning a 5 minute clip of an ffvfw encoding.
Check it with free version of bitrate viewer, which is very reliable, and see that the vbv is ~7.
For starters, you'll probably have lots of problems muxing the clip with audio. At least I did.
Even if you succeed, run to your favorit Hi-Fi store and ask the guys to try that clip on a couple of standalones. That's what I did.
Then If you tell me you succeeded in your task I'll give up bugging you
Nevertheless, I completely agree with you that we haven't understood ffvfw 100%. Also I think that there must be a way to choose constant bitrate and have the vbv buffer we want, period.
Otherwise Milan was asleep when he built the encoder in the 1st place
Cheers
__________________
Rui
|
02-24-2004, 04:17 AM
|
Invalid Email / Banned / Spammer
|
|
Join Date: Feb 2004
Location: Bucharest, Romania, GMT+2h
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
For starters, you'll probably have lots of problems muxing the clip with audio. At least I did.
|
I didn't mention that when I mux FFVFW with standard VCD settings in BBMPEG the muxer spits out error messages. But if I increase the buffer size from 46 to 230 (as in SVCD) BBMPEG keeps quiet. I didn't have problems playing even with the value of 256 that BB lets you put there. So, as you can see, I have no respect for standards and my player either. Actually is frightening what I realized, that I might not play what I burn on any other player, if this I own gets broken. But, what the hell, I will alwas have a computer ... Actually I have a video card with video out but I never conected it to a TV because I'm too lazy and my computer's HDD's and fans too noisy to enjoy anything...
Quote:
Originally Posted by rds_correia
Nevertheless, I completely agree with you that we haven't understood ffvfw 100%. Also I think that there must be a way to choose constant bitrate and have the vbv buffer we want, period.
|
You must be a religious person
Well, the program has been built in a way that works well for me and it doesn't for the majority. If you think that Milan left a backdoor that nobody discovered untill now you are very optimistic. I think that the only way this program will work for everybody is that some smart and generous programmer take the source and dig into it and make it work. Because otherwise I think we all are a bunch of monkeys trying to operate a defective Ferrari if we think that only some settings will make this program work
Marcellus
|
02-24-2004, 04:41 AM
|
Free Member
|
|
Join Date: Dec 2003
Location: Omicron Persei 8
Posts: 322
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
... bitrate viewer, which is very reliable, and see that the vbv is ~7...
|
Actualy, BV shows half ot the VBV value, for unknown reason. Ask Karl, Phil, or Inc. and they will tell you the same story. So 7 x 2 = 14, and it's still far bellow of 40 (VB=20) for VCD standard.
Quote:
Originally Posted by marcellus
Quote:
Originally Posted by rds_correia
For starters, you'll probably have lots of problems muxing the clip with audio. At least I did.
|
I didn't mention that when I mux FFVFW with standard VCD settings in BBMPEG the muxer spits out error messages. But if I increase the buffer size from 46 to 230 (as in SVCD) BBMPEG keeps quiet. I didn't have problems playing even with the value of 256 that BB lets you put there.
|
I'm doing ffvfw encodings with MPEG1 (CBR=1147 (VBV40) or 3321 (VBV112)) and I'm muxing this with BB SVCD mode, and forced mux rate to 0, as all propose, and I get no errors at all.
Quote:
Originally Posted by marcellus
So, as you can see, I have no respect for standards and my player either.
|
We (Me+my player) neither
__________________
Go for SECAM =)
|
02-24-2004, 07:56 AM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Hydeus
Actualy, BV shows half ot the VBV value, for unknown reason. Ask Karl, Phil, or Inc. and they will tell you the same story. So 7 x 2 = 14, and it's still far bellow of 40 (VB=20) for VCD standard.
|
That's what I'm saying. For VCD maybe it's not a very big deal but for SVCD and (K)DVD that
value is just a plain disaster.
Quote:
Originally Posted by Hydeus
I'm doing ffvfw encodings with MPEG1 (CBR=1147 (VBV40) or 3321 (VBV112)) and I'm muxing this with BB SVCD mode, and forced mux rate to 0, as all propose, and I get no errors at all.
|
Then you don't have many ways to up or down the bitrate with the bitrate slider.
Milan called it constant bitrate slider for some reason, right?
Otherwise he would have called it vbv buffer slider...
This is where I understand Kwag's tests but tend to think Marcellus is right.
If I move that slider up and down I can see real differences in bitrate and in file size as well as movie quality.
So I have to agree with Kwag that the way we use it we have to stick with 1147/3321/6426 to
have correct vbv buffer values 40/112/224.
But I also agree with Marcellus when he says that the slider changes bitrate and movie
quality as I think it was what Milan intended it to do.
Quote:
Originally Posted by Hydeus
We (Me+my player) neither
|
No Hydeus. In fact you are having lots of consideration for the vbv buffer.
You use 1147 and 3321 which provide 40 and 112 which are standard vbv buffer values.
As for Marcellus I cannot say the same since he is using 14 as you said.
Lucky him for being able to watch it on his standalone.
__________________
Rui
|
02-24-2004, 10:14 AM
|
Invalid Email / Banned / Spammer
|
|
Join Date: Feb 2004
Location: Bucharest, Romania, GMT+2h
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
As for Marcellus I cannot say the same since he is using 14 as you said.
Lucky him for being able to watch it on his standalone.
|
Well, since my player is so special, I designed a special sticker for it, because it deserves it.
I hope one day everybody will be able to use it
|
02-24-2004, 10:32 AM
|
Free Member
|
|
Join Date: Jun 2002
Location: Germany
Posts: 1,288
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@marcellus : none of the pictures you linked at on this page are reachable.
__________________
j3llyG0053
|
02-24-2004, 10:58 AM
|
Invalid Email / Banned / Spammer
|
|
Join Date: Feb 2004
Location: Bucharest, Romania, GMT+2h
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Jellygoose
@marcellus : none of the pictures you linked at on this page are reachable.
|
How come? This is weird! I have no problem clicking on the links an opening images in a new window...
Does everybody have the same problem?
N.B. I didnt't embed images in page because my provider doesn't like that behaviour, I just put links.
|
02-24-2004, 11:04 AM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
It's open a new page and then...
I see this message:
Quote:
403 Forbidden
You must supply a local referer to get URL '/FFVFW-compliant.jpg' from this server.
|
|
02-24-2004, 11:13 AM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
Yep,
Same here Prodater64.
Can you doble check that Marcellus?
Cheers
__________________
Rui
|
02-24-2004, 11:36 AM
|
Invalid Email / Banned / Spammer
|
|
Join Date: Feb 2004
Location: Bucharest, Romania, GMT+2h
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Well, I still have no problem but this means nothing, since I 'm probably on the same sub-network with that server. As I can figure it out I have to look for another free host for my files that is not so sh**ty as my current one. I will be able to do that only tonight, when I arrive at home. BTW, can anybody recomend a free site? I could use a hint.
Sorry for any inconvenience
Bye
Marcellus
|
All times are GMT -5. The time now is 06:28 PM — vBulletin © Jelsoft Enterprises Ltd
|