Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
Raiscan wrote:
Gah. While that particular frame *partially* shows what I'm trying to get you to see, it doesn't seem to have shown up very well. Something with red and green will show up better, for example Mario on a green hill with blue sky in the background.
Compare that frame with the lossless lanczos bmp you made. Pay extra close attention to the colours. Not very lossless if the colours have changed, is it? :)
Yeah, the RGB to YV12 colorspace conversion (x264 always uses YV12) causes a slight color loss. Forgot about that.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
Ferret Warlord wrote:
Okay, is it normal for the timer to go all screwy when watching an MKV with VLC? It seems with every MKV I've watched the timer was jumpy within a five second range. Doesn't affect the video any, however.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
Yes, the N64 encoders are too modest.
The encode of the 5:33 run compared to lossless:
Too much grain is introduced in N64 encodes, whereas NES encodes typically look transparent.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
moozooh wrote:
Yes, these people are called publishers. Badger them if videos look bad. (Beware, though: harsh replies from adelikat's side are not to be unexpected.)
Also, if you read Johannes's first two posts, he was on about a different thing; namely, increasing bitrate limit for N64 or abolishing it altogether.
Maybe I'm just bad at explaining in English..
ZeXr0 wrote:
The point is, the bitrate should be ajusted so that the game look good, even if that means having a bitrate that takes 6mb/min. That's pretty much it. Nothing more, nothing less.
That was my one and only point from the beginning.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
What exactly am I overlooking?
First of all, about 90% of the encodes for any platform don't even come close to the limit you're talking about.
I never said most games need to exceed the limit. The point from the beginning was that the ones that do need to exceed the limit should not look bad. Many N64 encodes look bad.
The point was never what was considered complex to encode, it was that games that need it should be given higher bitrate. In my opinion, we should forget about the 4 MB/min limit, and use the lowest bitrate that will actually look good, instead of striving to barely fit the 4 MB/min limit, and possibly sacrificing things like seekability and compability in the process, just to get a somewhat decent looking (and sounding) video file.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
eternaljwh wrote:
Encoded TASes take up roughly 40G of my disk, about half that drive.
That's your problem. We shouldn't have to make bad looking video just so you can fit more on your HDD.
ShinyDoofy wrote:
(just ran a test encode and found 470kbps of video for ingame scenes only to be damn near publishable quality at 320x240)
The problem is that what's currently considered "publishable" quality for complex 3D games is not good enough. The complex 3D games generally use too low bitrates. NES game encodes nearly always look transparent, while encodes of complex 3D games look very lossy. Look at the Mischief Makers encode, for example - the intro starts out extremely blurry and suddenly sharpens. This is a clear sign of a too low bitrate.
ShinyDoofy wrote:
Generally raising this limit would potentially result in a lazy encoder just going with a higher bitrate instead of trying harder.
Anything above 2 MB/min is overkill for NES games, but the limit is 4 MB. Has this resulted in people using unecessarily high bitrates for NES? No. In my opinion, we should encourage higher bitrates for the complex 3D games, so they don't look very lossy while the simpler games look perfect. There's no reason the video quality of encodes should depend on the game's complexity. Encoders shouldn't have to ask for special permission to use a bitrate as high as needed to make the encode look decent. This does not mean the encoders should be lazy and go with unecessarily high bitrates.
bkDJ wrote:
1st pass should be done with a crf of the encoder's choosing (picking 22 to 26 seems reasonable) and pass2 should just use that bitrate. That way you are encoding to a certain quality and don't have to guess a good bitrate. Oftentimes, it will be less than the 414 kbps limit (assuming 128kbps sound) and mroe efficient than a guess.
Also since pass2 is like 20% better than pass1, you can also do like pass1 at crf19-23 and make pass2 20% lower bitrate and be near exactly the same quality. All this gives every game an equal chance to look good at a reasonable filesize. Naturally the more demanding 3D games' encodes will be bigger this way but not "bloated."
My 2 cents.
Not a bad idea. However, with that method, bitrate allocation won't be as accurate as it would be with the same bitrate for both passes, but that can be solved by doing a third pass.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
Derakon wrote:
Well that last line came out of nowhere, and I don't think it was warranted. But you're entitled to your opinion.
I'm simply trying to make a distinction that you aren't, as evidenced by your line "N64 games need much larger file sizes to look good." This is not universally true. While it is true in general, I wouldn't be surprised if, say, Paper Mario would look fine with our current "standard" bitrate. My main goal here is to make certain that we don't end up just inflating file sizes unnecessarily.
Sorry if I'm being rude. I was never encouraging inflating file sizes unnecessarily though.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
Derakon wrote:
Johannes: it sounded to me like you were saying "All N64 games should be allowed higher filesizes", while I was saying "All games that would look crappy at low filesizes should be allowed higher filesizes". That's the only significant distinction between what I said and what you said.
I don't think I've seen an 8-bit or 16-bit TAS yet that would significantly benefit from a higher filesize, but that doesn't mean there won't be one in the future (and I pulled out Gunstar Heroes as an example of a time when we could've used this rule in the past). I do think it quite plausible that there are games out there that don't benefit significantly from a higher filesize, though, and I don't want to see our dialup users get punished just because the encoders weren't as efficient as they could be.
Only the complex 3D games need higher file sizes. I never said any 8- or 16-bit game did. Only the complex 3D games do. Simple games don't need to have unnecessarily high file sizes just because complex 3D games should be allowed to have higher file sizes when needed. NES games typically look good at 1-2 MB/min. N64 games need much larger file sizes to look good.
I think it's about time we stop caring so much about dialup users. There aren't many of them left, and soon there will be none. Either way, only the few games that will truly benefit from larger file sizes, and therefore should be allowed to have larger file sizes, will actually have larger file sizes, and the quality difference is worth the slower downloads. It's starting to seem you're arguing just for the sake of arguing.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
Xkeeper wrote:
Johannes wrote:
I'm not saying all games should have higher file sizes, only the ones that actually need it.
I think you entirely missed his point.
On the flipside, I'm sure there are N64 games that wouldn't benefit significantly from larger filesizes, and there's no need to force our dialup users to suffer exorbitantly long download waits.
I interpreted this as that he thought I meant all games need higher file sizes. My point was that higher file sizes should be allowed when there's need for it, while games that don't need it stay the same.
Did I get it wrong?
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
xPi wrote:
h264 and cpu usage
could things like Cabac cause lots of extra cpu usage?
CABAC's impact on CPU usage is minimal. B-frames usage, b_pyramid and more reference frames do, however, make the videos more CPU-demanding.
andymac wrote:
There is no reason to still be using MPEG-2 - H.264 is far superior. Would you care to explain what exactly is unstable about it, except for the high CPU usage on 6 year old computers with shitty hardware/decoders?
Basically what you're saying here is if you had a video format which could not be played on any other computer but yours, and the quality was lossless and file size was a mb/min, then it would be perfect. What you're missing here is the fact that there may be quite a few people who have shitty 6 year old hardware, and if that's the case, and they don't have a ROM, then H26.4 is definitely not for them. So here's a radical thought: why don't you try using a different format, or encode in more than one format? It doesn't necessarily haveto be mpeg-2, but it will run on any machine without question.
Wrong. What I'm saying is that if 99.6% of the people here can play it, it's good. Like duksandfish said, even an ancient laptop can play my encode with ffdshow.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
andymac wrote:
Hows the current 120 stars run going?, if it still is going. Isnt mr_robert_z doing one? and if he is, is he just a little bit pissed that by the time he finishes, there will be another billion timesavers available?
The audio seems to desync for me, and the picture seems oddly fuzzy. It also seems to cause FFDShow to use alot of cpu on my laptop, far more than is usually required to decode h264...
That's weird, it works fine for me :\
Oh well, thanks for the report, I guess. Anyone else can confirm/deny this? I'd like to know what I'm doing wrong...
It looks fine, but seeking.. doesn't work right.
(Also, the bitrate is higher than needed, the image is too thin (you're supposed to force a 4:3 aspect), and the fps is 59.999 instead of 60.100 like it's supposed to be.)
But I think it's good enough, and it has my name on it!
Haha~~
Me,too. Me,too...
Um, a yes vote from me. 6.5/9.5. It just looks awesome on a page to quote someone, who's in turn quoted someone else ect...
as for the review... well, you're walking, which can't be good for the entertainment, but on the technical side it's amazing. the bullet bill skip is... unexpected. I wonder if you could use that in the actual SMB run, in 8-2 maybe?
Also doesn't everyone know where they can get they're hands on an SMB rom? And if they don't have it, they can always just go to youtube, which is the obvious choice, rather than worry about a perfect encode. Why do you have to use H26.4 anyway? can't you just go with the good old MPEG-2? H26.4 seems like a shitty format when it comes to stability. It's only a 7 minute video anyway, so size won't really matter.
Of course size matters, when a 10 MB file can achieve the same quality as a 60 MB file. This site was born from the need for high quality video files for publication, and a good filesize to quality ratio is among the requirements. When 160 kbps looks transparent, there's no need to use 960.
There is no reason to still be using MPEG-2 - H.264 is far superior. Would you care to explain what exactly is unstable about it, except for the high CPU usage on 6 year old computers with shitty hardware/decoders?
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
negjay wrote:
I'm not a fan of Mario movies, but I'll comment on the videos. I tried Johannes' encode, and it's like an .mp4 from SDA; 100% cpu usage. Usually the h264 videos from this site take up no cpu at all.
I can't even watch a HQ run from SDA, it just completely thrashes my Athlon Barton 2800+.
I don't know which h264 setting does it, but it's quite unfriendly to those without hardware h264 decoding or fairly recent processors.
As an aside, HappyLee, your English has improved to the point where you are very easily understood. At this rate you will sound like a Briton within a year.
It takes 3-6% CPU in fullscreen for me. :/
Ver Greeneyes wrote:
Both encodes were very blurry for me until I turned of 'VMR9 mixer mode' in Media Player Classic (well, that or switching to the Overlay Mixer). I never knew that could have such a large effect.
Did you mess with the settings? It could be caused by hardware or software related issues. All "mixers" look crystal clear on my computer.
The audio seems to desync for me, and the picture seems oddly fuzzy. It also seems to cause FFDShow to use alot of cpu on my laptop, far more than is usually required to decode h264...
That's weird, it works fine for me :\
Oh well, thanks for the report, I guess. Anyone else can confirm/deny this? I'd like to know what I'm doing wrong...
It looks fine, but seeking.. doesn't work right.
(Also, the bitrate is higher than needed, the image is too thin (you're supposed to force a 4:3 aspect), and the fps is 59.999 instead of 60.100 like it's supposed to be.)
Too much grain is introduced in N64 encodes, whereas NES encodes typically look transparent.