On a side note, be sure that you have the appropriate video codecs installed, specifically, ffdshow. This should allow you to dump high quality AVIs, better than the standard codecs supplied with default Windows installations.
Thanks for the encode, Flygon, but wow my computer (iMac 2GHz Core Duo / 2GB RAM) cannot handle 1080p Flash videos. We're talking like one second per frame here.
Wow, that should be able to play it fine. Try updating flash? Or maybe try a different browser/updating browser?
I don't know how plausible this is, but if someone could make a version of the .AVI or .MKV with subtitles explaining a lot of the glitches, it seems like it would be greatly appreciated. Heck, I'd even write the subtitles with the relevant times they should be displayed if someone else would put the video together.
It's easy to do with MKV or MP4 as softsubs. But yea I would need that text file first.
Unfortunately, this was publish before the final encode was done. The torrent currently posted is INCORRECT.
Edit: Now it's the correct torrent. Well I've learn my lesson for this. Next time I won't rush anymore, since I got burned this time.
aktan: Processing... (taking forever to audio sync it)
And when have any set of rules been so strict as to not allow exceptions? Even laws can have exceptions, depending on the situation (as determined by judges, who's job is to interpret the law).
I'm a bit confused as to why I was quoted? oO. I'm saying I'm encoding, but it's taking me a long time due to audio desyncs from Mupen.
I don't remember now, but I do believe the possibility must have occured to me...
But I might just try it out again in the future.
There is another thing, though. It seems that CRF might also vary greatly depending on the source, and that just kindof seems to defeat the purpose of it. Except that it's faster since it's 1-pass.
Not at all, sources do vary greatly in terms of how compressible it is. Take a clip which is just still motion, vs a clip with all fast motion. Which do you think needs more bits? Btw, just to clarify, "CRF way too high" really means a CRF value way too small, but I think you got what I meant.
I'm not sure if we're implying the same thing!
In my experience, CRF consumes way too much bitrate in hitting a desired "quality" factor. I may need to experiment with this feature, but my results so far have shown that I have been able to hit much lower size with 2-pass bitrate instead (with same visual quality, basically) of CRF (which I used before).
Ever think that maybe you just set a CRF way too high? The only way to test, is find a bitrate, and have both hit that bitrate, then compare. If 2-pass is indeed better, the CRF at the same bitrate should look terrible. If both looks pretty much the same, it just means you've been setting a way too high CRF.
"May be" is a poor argument here. The results vary considerably depending on exactly what it is that you're encoding.
An approach that I have taken in the past is to use --crf 20 on a sample segment to get an approximate target bit rate, and then experiment with bit rates in that vicinity. This can be overly time-consuming if --crf 20 is "good enough"; I usually only go through with it if --crf 20 gives particularly poor results on the bit rate front (as happens occasionally with runs for recent platforms and/or some Genesis runs).
In most cases, I have found --crf 20 yields bit rates comparable to what we consider to be "good visual quality" for publication purposes. There are exceptions, but for the type of work we do on the site the difference is usually closer to Aktan's quoted estimate than anywhere near 2-3 times off the mark.
EDIT: By the way, with the level of knowledge of encoding some of the people here are demonstrating, I'd encourage giving encoding some of the runs in the queue a try. A little practical knowledge in what the site needs from encodes goes a long way in these sorts of discussions, and we can always use more encoders!
I'm not talking about what CRF setting is good or what bitrate setting is good. I'm talking about how well CRF and 2-pass distribute bits. If you compare CRF and 2-pass at the same bitrate, does 2-pass look better? Both CRF and 2-pass have different ways of distributing bits, and I'm saying that both does a very good job with 2-pass being 1% better.
The problem is indeed the bitrate, but you can get the same quality with substantially less bitrate with 2-pass bitrate, so that is why I would recommend it over constant rate factor. It may be in the range of 2-3 times more efficient.
This is wrong though, it may be only 1% more efficient. Nowhere near 2-3 times.
You guys are all very late. I already helped him and he's done now.. lol
EEssentia: While 2-pass does distribute the bits better, it's quality is only slightly better than CRF. The main problem is guessing the bitrate. Unless you wanna reencode the file 10 times just to find the bitrate you "like", CRF is a lot faster. There is a middle road though. That is encode in CRF first just to find what bitrate, and then encode it again in 2-pass. It's basically like 3-pass.
Also MeGUI is nice and newbie friendly, except last time I checked, the x264 MeGUI updates to is really outdated.
There are parts of the video running at 30 FPS (the non-loading screens) and there are parts that run 60 FPS (the loading screens). Both the MP4 and MKV posted are variable frame rate. Maybe what mplayer sees is the average frame rate which is 29.088 according to MediaInfo reading the MP4. If you download the streaming version, it will be constant frame rate of 60. This is why I said it goes "up to" 60 FPS.
I haven't watched this but I figured I'd ask this question now, since it will be brought up at a future date anyway. If this is found enjoyable by everyone, should it be published alongside the current run? And if so, what happens if another submission using another character is made/submitted? As I understand it, there are 8 available characters for this game. And from what I remember of the published run, at least 15% of it was watching cut-scenes of ships flying, which makes me doubt the need for 8 individual published runs. So where should the line be drawn, and what sort of criteria should we use to favor one character over another?
As mention in the Lute thread when it was on WorkB, and also by ugetab, only the characters Blue and Lute are short enough to be TASed with Blue supposedly having some kind of an ending, unlike Lute.
Hello, I'm the director/presentator of "88 miles per hour" the french broadcast dedicated to the TAS available on Dailymotion.
Recently I recieve a mail from someone at Dailymotion which is really interested to help you getting the best quality for your videos. All the people who are uploading video on DM should ask for the "creative content" and become motionmakers.
With this the video quality is really better (check 88 miles per hour) and there is no time limitations.
So if I were you I'll ask, it's free and really helps:-) If you have any problem having your validation MotionMaker , let me know I can ask directly to the right person at DM.
Hope it will help, unfortunalty there is not way to put 60 FPS movies on the website (you can send it but it will be converted) , but the quality would be at least two time better.
Thanks for the help! About the 60 FPS, if you press ctrl + tab while having the focus on the flash player, statistics show up and I saw it was 60 FPS. Are you sure it doesn't support 60 FPS?