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

Haven't tried KDVD but all my KVCD's and SKVCD's played perfectly on my Cyberhome 300.

Offtopic
"Sorry" is apology for something that we don't wanted to do, and not for intendet behaviour :!:
Stange way to get one, with this words :?

Back to the topic.
I think that posting some experiences is only resonable, when we get beter (differend) things. Everyone knows results produced with default setings (as your famous H.263 q-type, witch is set after instalation). I've maded some tests (and I think not only me) and there was no diference betwen MPEG q-type. This might be reason of no response. And youre constant bitrate idea was baned with regard for VBV incomplience.
If you want us to understand youre way, then try understand our ways of testing.
Regards.

I apologize again and I hope that everybody will be able to forgive me. :oops:
I am a choleric person and often I get into trouble because of that. My friends are used to it. I'm not a mean person and I never try to offend somebody on purpose but somehow I mange to do that and when I do it I feel sorry.
Well, when I put a question I expect an answer. Kwag did respond but I think to another question. So I waited for another answer, to my question. How am I supose to know that you did some tests? (BTW, you are first person, beside kwag, that says something straight about it). Why didn't you post anything? Well, I felt really bad. All I could assume is that I was given "let this stupid new guy alone with his stupid questions" treatment, because kwag already spoken. And I further got the impression that when kwag says that something is red nobody tryies to see for himself. Perhaps is only my impression and I apologize for my missunderstanding.

It's not such a big issue anyway, I already forgot it (was a month ago) - to some extent is normal to misstrust the newcomeers. But poershr's findings and questions bring this issue up in my head and I spit it out. I'm sorry for my sharp tongue.

I promise I will not post in this thread again untill I have somethin usefull to say about 2-pass encoding.

Best regards and (I hope) no hard feelings! :D
marcellus

I didn't realize that you could feelt this way. So now accept my apologize.
For now, as I know youre behaviour, I can filter contents from emotions :)

Keep testing.

I don't have hard feelings.




Ok, I must go hurry now, cause my astrophisic lecture begins in half hour :D Si ya.

PS: @ALL
:?: Is there any way to change VBV after encoding. I mean like crack file :?:

The only way I know, is processing the MPEG file with the very first BETA versions of TMPEG, which had a VBV option on the "tools" section.
That will re-process the MPEG file, and create a new one with the correct VBV size.
Right now, the low value of 14 produced by ffvfw, is extremely low and you can actually see blocks and strange artifacts, specially on scene changes, due to the small size.
It's really too small to keep a descent buffering scheme, not to mention compatibility issues. And I mean "standard" DVD compliance.

-kwag

Hi everybody,
Let us all try maintining cool as we always do.
I don't take Marcellus or anybody else here personally, yet.
It's good we don't give up easily when we think about something and test to make sure.
One thing that I think I should apologise is for having stopped posting regularly my test results on the ffvfw thread.
But that's just because I was more commited with the Mencoder 4 windows thread since the begining...
I can say that I didn't test h.263 results because I was already more on the mencoder thread.
But I tried the slider for const bitrate since you posted your results Marcellus, and I must say that I always tended to agree with you more than with Karl, since the begining. I mean, in result of my testings...
But I cannot fight a bad vbv when one of my players crashes, and also one from my cousin, too.
Again, I'm sorry for not posting when I should have but I only didn't because I was already more commited to find my way over mencoder than with ffvfw.
Hell, I'm using ffvfw with mencoder through makeAVIS :wink:
Don't anybody get angry because it can't help anyone.
We just have to support more each other than we have lately.
But look: the forum doesn't stop. Newbies register everyday and everybody has to give them a hand with prooven tools we've used so far like tmpg.
That doesn't leave much room for testing two new beauties like ffvfw and mencoder.
That's just it. :wink:
So have some good testing everybody.
C ya

Racer in the other ffvfw Thread gave me these links to that mentioned TmpgEnc Version which "should" have VBV options in its Tools-Section.

Till now I didn't test it as I never had these low VBV issues again.

TMPGEnc-0.11.20.97.zip (Main Program) http://www.pcphotovideo.com/Download...0.11.20.97.zip

tmpg_en0725.zip (Update to .12 and Japanese to English Translation) http://www.pcphotovideo.com/Downloads/tmpg_en0725.zip

Hi Inc & all,
I did test it but it seems it only supports vbv=40.
I didn't see support for 112 or 224.
Sorry for not having posted it before :oops:
Mencoder didn't give me a chance to do it...
Cheers

You're right. I forgot about that :!:
It's only good for VCDs. Not for DVDs.

-kwag

rds_correia, what encoder did you use when testing for low VBV???

Hi Poerschr,
As far as I know it's the latest version from 2004.
I guess it is a build by Athos from the doom9.org.
I never tried with the not so buggy version that Hydeus mentioned already.
Say, if we can fix this problem with vbv I'll prefer using ffvfw instead of mencoder because it's far more friendly :wink:
Keep up with the good work.
I promise I'll try to assist you when possible.
Cheers

My thoughts about the encoding....

When comparing a SVCD created with TMPGenc (using kwag's notch matrix) and the newly encoded second pass stream created by ffvfw(704x480 - H.263 setting - NOT Kwag's matrix), I noticed that for high bite rate scenes ffvfw won hands down...it kicked ass!!

Oddly enough, both files were about he same size...~750MB, maybe even the ffvfw encoded files was smaller...however, the difference in resolution being the main factor...

The way that ffvfw created blocks was very different - I could definately see that ffvfw was much more intellegent than TMPGenc - it was able clearly define blocks around areas that were in the distance. The blocks also seemed solid - this might be due to the H.263 setting - I am not sure). From reading kwag's documentation about H.263, it seemed like this might make sense. (if you guys are positive you do not want to talk about H.263, I will not bring it up again - I just wanted to mention that becasue it was the settings that I already used)

As far as I am concerned, I did not like the precense of these blocks - that is just my personal taste.

I tried another test - this time wilth a lower resolution - 576 x 480. I noticed that the grip filter does not accept this - that is a same! It seemed to me that the encoder repoprduced eactly the same quality - that was funny - I expected these block to disappear (or at least lessen). This allows me to conclude that the way the encoder is currectly functioning is a product of settings - and that much more compression is possible or reproduction of perfect DVD quality at low bitrates is also possible....

As I written in another thread I blame for blockiness of ffvfw the minimum setting of 2 that it let you put as minimum quantizer. The nondetailed areas I think get sometime over-quantized. In my wish list of ffvfw improvements a minimum quantizer of 1 should have its place. But anyway I prefer this blockiness, that I'm not finding very annoying, to other artifacts of other encoders (at small bitrates, where I like to play).

marcellus

P.S. I'm happy and gratefull for the good tolerance for my lack of proper behaviour. I will try not to abuse it in the future again :D

What is a shame ? To not accept a resolution THAT IS NOT A VALID RESOLUTION ? I don't think so :!:

Sansgrip, the author of the gripfit filter, knew sooooo much more about video encoding than you that you should bite your tongue before arguing like this ;-)

Valid (PAL) resolution is 480*576, not the opposite.

Note: will you realize a day that your H.263 video won't play in lot (perhaps all) of standalones ? Did you try yours ? (I didn't see that in your post, but you probably already said it).

Dialhot, you are really an annoying guy....I have tried for such a long time to keep everything professional, despite some bitter comments...

Do you think that I do not know that it is not a valid resolution??? It's called testing...I did not want to go as low as half DVD....

Man, you guys get on my back for not testing, and then you come back and ask me a question like did you try playing your video??? If you tested the H.263, if you followed your own advise, maybe you would already know the answer to your question...

oh, and I was never arguing anything...just reporting my findings...It's a shame that Sansgrip never allowed for invalid resolutions, for testing purposes...Does this mean that I don't like Sansgrip's filters?? Does this mean that I think Sansgrip knows more about video than I do?? Does this means that I don't like Sansgrip?? NO NO NO I think that when I say, it's a same - it is becasue I like all of the work that Sansgrip does and very gratefull for this great plugin, I wish that I could use it in my experiment...

I wish we would stop wasting time on these personal attacks....it does not seem to get us anywhere...We are all on the same side....I was trying to convery my findings, but you blew right past the most important information and went right to some comment about Sangrip's grip plugin that is not really that important.....It does not make any sense to me....

Does this post help us??? nope, not one frecking bit!!

:lol:
Notice how Phil is in a good mood today :)
Also notice that he never holds to him what he needs to say from his experiencing/testing/knowledge 8)
You see, we don't discriminate newbies in the forum even because they may be very much experienced guys but have just found the forum.
We just like to feel that if someone tries something a bit out of specs, many testing is performed by everybody before saying that it's a major breakthrough or start using such a method by default.
For instance we all know that the majority of players support GOP size superior to 15/18 for (K)DVD.
But from much testing around we agreed to maintain the templates at 15/18 because we noticed from some reports how several standalones didn't like that.
But above all this, everybody tries to help everybody :wink:
Even if opinions on some subject don't match.
Cheers

Cool down Phil :lol:
And for future for you: when anybody mention again H.263 with FFVFW, it means "H.263 quantization type" not H.263 stream. Ok :roll:

In fact H.263 stream have no purpose, because of ... goto offtopic

Offtopic:
Now we have (still in beta produce) H264 format, which from my opinion (for now of course) isn't acceptable at all. But it is still only constant bitrate encoding, so no wonder 8)

I've downloaded this TMPEG VBV version. I'll proceed to tests.

@Poerschr,
Hey, when I wrote my last post you still hadn't post your latest one.
I have to let you in on story about me and Phil.
We also started on the wrong foot when I started posting here.
The subject was about correct YV12 codec, which is obviously something that doesn't exist :arrow: I needed a codec that I could use with tmpg and that would allow me to use avs 2.5x that uses YV12.
And even though I would swear that ffdshow was able to do the trick Phil always told me to install Nic's XviD codec.
In the end, as usual, Phil was right :wink:
Although I could tell you that ffdshow should be able to do the trick, but obviously not as efficiently as Nic's XviD.
In the process I read some sharp posts by Phil, but I completely understand it.
The man was right, he knew he was right, and there I was at his thread posting bull that I wasn't completly sure to be true in every case.
So everybody relax. Do some more testing.
Acknowledge that some of us don't hold things back when they have something to say.
Just don't nobody be rude.
Be cool 8)

This TMPEG sets very strange 36 (72) VBV value, no mater what option is preffer :screwy: But for VCD it should be enought. Sad that only for VCD.

Hi Hydeus,
Just to be sure: what value did BV report before using tmpg for fix? Did you have 7?
Cheers