I've replaced the encode with a new version using a new method of N64 capture that fixes the following:
- Fixes messed up audio
- Fixes a/v desyncs completely
- Fixes missing video frames
All this and it's easy than before to capture (though still computer time consuming ~_~).
This seems to not currently be available for download; the movie file is not found. Any idea what happened?
Oops, I just noticed these messages as somehow after the server move, I don't get notifications about threads I watch anymore. Anyway, yea I forgot to fix the links after I changed the x from capital to lower case. Let me do that now.
While a savings of 57 seconds might have provoked the authors to whoop a bit in excitement, I suspect the desired word in the movie description was "whopping". :)
I'm trying to figure out why the time is 41:18.38
At that point the game's credits have been rolling for awhile, so no input would be present or needed there, right?
If anything, the last input would be at around 40:2x.xx after skipping the final cutscene with Zero and the scientist, if I'm not mistaken.
It's probably due to the fact (problem?) that kkapture skip frames during screen transitions when capturing using the TAS soft GPU plugin. I've figured out a slow fix for this but have not put it into practice yet.
I'm not solely concerned with motion; I'm concerned with clips that have proven to be codec-poisonous for testing purposes. Larger file sizes will mean there is more room for seeing the effect of tuning any particular option, and we will be able to better see the relative impact of any changes that are made.
I don't see it this way. Why would codec poisonous clips have more room for seeing effect. What about them makes them more likely? Just cause they use more bits? Couldn't the use of more bits is just plain due to the textures are all so different? I mean, to me, if I just sequence completely different looking frames every frame, I would think it be codec poison and not very easy to optimize at all no matter what settings I choose.
Runs that did not encode very well does not mean it has a lot of motion. In fact, to me, it may mean the opposite. The changes in the texture was so great that x264 counted it as a new texture and not motion, hence why it grew so big (mostly texture info and not much motion info and I think we can agree that texture info is a lot bigger than motion info).
Good work moozooh! I do have a problem with your conclusions though. I think testing one clip is not enough to make conclusions. I think it would be better to test a variety of clips with different types of motion before making a conclusion. Basically, who is to say that the clip you used has a ton of motion to x264, and not a ton of different textures instead? It's a great start, but I think more testing is needed before a conclusion.
Great job, but I think you should also mention what x264 version you are using as each version may have different changes/features that affect the size/speed/(and quality if it wasn't lossless).