Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Yeah, that's a pretty major color difference that would be noticeable in an in-game switch between the still background and the FMV. It seems like just a mismatch in color conversion standard. Does that FMV format specify a color conversion standard to use? If so, is psxjin reading and interpreting that properly?
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
What has happened in the past is that the forum database failed and "ate" a post, causing the poster to think it was deleted by administration. This was a misunderstanding. The tasvideos forums are known to have strange issues every once in a while. Perhaps this is what happened to you, DootBeep?
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
antd wrote:
Brutalal has created a spreadsheet that plots the optimal path (in terms of number of steps needed to run through a field). It details exactly when you will encounter a random battle and allows many configurable options on how to avoid them.
The problem is there are many ways of getting away from a battle:
1. Accept the battle and instant escape (685 frames)
This also reduces the danger counter to 0 (you get more battles as the danger counter rises)
2. Menu glitch (83 frames)
This glitch avoids a battle but the danger counter remains (eg, if you do 20 menu glitches in a row, you'll be getting a battle every few steps)
3. Stutter Walk (x frames)
This is clearly the fastest way to avoid a battle. The danger counter remains. The spreadsheet calculates how much stuttering is needed. You lose time for every stutter, but it is a tiny amount.
So we know that the battles are entirely deterministic and we even have a spreadsheet which shows the field lengths and when the battle will occur.
This is a segment in the game. The X axis are the steps and the Y axis is the danger counter. The white lines are the battles. You get a battle when the red line hits a white line.
What we need help with is in calculating the fastest way to avoid battles. In other words, should I menu glitch, stutter (sometimes not possible, easy to see when it is or not possible) or accept+escape a battle.
So, I want to know the fastest way through the segment I just posted above. Ideally we will need to optimise the data not just for one segment but for the entire game.
Anyone that can give ideas on how to accomplish this?
This is a very interesting problem. Where's the spreadsheet?
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
3DS has DSi mode available. It can play DSiware games. It also has a camera. It also uses the same power adapter (YAY NINTENDO, YOU FINALLY FIGURED IT OUT!).
WTF. Never mind. Apparently, ffmpeg's ZMBV encoder can only encode 8-bit paletted ("pal8" pixel format in ffmpeg) video. I know ZMBV supports higher bit depths and works wonderfully with YouTube (example 1080p video I uploaded as ZMBV), but ffmpeg's ZMBV encoder fails.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
To be fair, the fact that he posted this thread caused me to want to help. I don't think I would have chipped in so much information without this thread. Also, that thread doesn't mention ZMBV at all.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Encode from your RGB source to lossless RGB ZMBV using ffmpeg. YouTube handles ZMBV perfectly and ZMBV is a very good lossless format. For this, download a static build of ffmpeg from Zeranoe's ffmpeg builds page (32-bit or 64-bit; doesn't matter; the exe is in a "bin" subdirectory somewhere in the archive), then try the following ffmpeg command, which should result in a pretty small lossless RGB ZMBV with lossless FLAC audio, all of which YouTube will handle properly.
If you must use h264, you should give x264 RGB data because it now does the color conversion properly. You should be using bt470bg color matrix for everything to accurately reproduce colors when converting from RGB to YUV and back to RGB. YouTube will do the conversion to RGB properly with a tv-range YUV 4:2:0 video using bt470bg color matrix. The quality should be lossless so you don't get YouTube transcoding lossy to lossy.
For x264, the following is as good as you can make it without losing quality and without spending too much time ("placebo" is usually many times slower than "veryslow" without much file size reduction).
To help others, it would be useful to try both commands, compare file sizes, and post your findings here.
Edit: Note that the x264 command line doesn't handle audio at all. You'll need to mux audio after you use it if you want to make an accurate comparison. You can do this with ffmpeg. Simply add these lines after your x264 line in your batch script, making sure to modify the input and output filenames as appropriate, like this.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Yes, the issue is obvious in any video playback system which properly handles the range flag. Those other people who watched the encodes either: were using incorrect video playback systems, didn't notice, didn't care enough to want it fixed, or wanted it fixed but didn't know how to go about suggesting (how) to do it.
As far as I know, there's no ready-made program which can detect this issue automatically. Since the issue is so obvious in any correct video playback system, an eyeball test with an understanding of color ranges and their surrounding settings should be considered good enough for this particular issue.
Considering your recent test video you uploaded to mediafire and linked in #tasvideos on freenode, this issue seems to be fixed for your future encodes.
As for past encodes, I'd like to see them fixed, but I can't and won't demand anything, being a lazy guy myself. The main reason I posted this thread was to bring the problem into the open and organize it rather than piping up in IRC every once in a while like I did in the past.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
I discovered yesterday that Aegisub can save a timecodes file in mkv timecodes v2 format, and tested just now whether it works from mp4, and it does! :) It's very easy to do. Just load the video in Aegisub and click "Video" -> "Save Timecodes File...".
Edit: Hmm. I tried to mux an mkv from using that video's timecodes file, video track, and audio track. It didn't work out very well. The video track ran at the expected rate and looked very good, but the audio was really early. Was something crazy done on a container level to align the audio to the video?
Edit: I added a container-level audio track delay of 666 ms and now the a/v sync seems to be perfect. The timecodes file tipped me off to a good delay value, as 666 was the first timecode in the file. Here it is in glorious synced mkv format. I tested it using Haali Splitter, LAV Splitter, MPC-HC's internal matroska splitter, and even VLC (2.0). All splitters worked perfectly for this video. :)
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Isn't the obvious solution to just use mkv instead? :P Just because the original is mp4 doesn't mean the fixed one has to be, I think.
Anyway, yeah, that seems to have fixed it here. I tested with LAV Splitter and MPC-HC's internal mp4 splitter. Nice job!
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
You have to disable whatever other mp4 splitter that's being used. If it's the internal MPC-HC mp4 splitter, it would be this one.
You can check what filters are currently in use like this (loaded video in screenshot is irrelevant):
Here, you can see I have Haali splitter ("Haali Media Source") in use for this particular file, which happens to be an mkv. If the loaded file was an mp4 file (such as the file we're discussing), you would see "LAV Splitter Source" there instead in my setup. With MPC-HC's internal mp4 splitter, you would see "MPC MP4/MOV Source". I can reproduce your issue, and I'm pretty sure that's it.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
It plays fine for me too. It's probably just whatever splitter you're using being unable to handle the silly characters that old version of mp4box wrote as the stream titles. Try configuring MPC-HC to use LAV Splitter Source and configuring LAV Splitter Source to handle mp4 files (probably not necessary; should be enabled by default).
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Apparently, the site has a slightly different implementation of BizHawk input file reading which requires a | at the end of each line. BizHawk itself doesn't even require this for playback, but adelikat's movie had it and Sonikkustar's didn't. Adelikat fixed Sonikkustar's file for him so he could submit it and intends to fix the site so it doesn't require that.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
The game needs to come to an end, after which it either resets or shows an end sequence, often including credits and/or a "the end" screen. Otherwise, the game isn't considered beaten.
In the cited example, the game reset after the end sequence was finished. It was necessary to use input to finish the end sequence that fast. Without the input, the game would have been beaten more slowly (or not at all? I'm not sure here). If you want to watch the end sequence at your own pace, either slow down your video player (MPC-HC can do this easily, including frame advance) or play and beat the game yourself. Speed runs beat games as fast as they can. End sequences are not exceptions.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
For this particular game, you shouldn't be watching the TAS if you haven't played the game. This game is available on multiple popular gaming platforms and is well worth playing.
This TAS diminishes the actual story to something difficult to follow anyway, so reading the cutscenes would be nearly worthless if you hadn't played the game.
Considering this, your complaints about not being able to read cutscenes and being unwilling to skip them anyway sound really immature, as if coming from a spoiled brat. MPC-HC has a keybind bound to the right arrowkey by default that skips 5 seconds forward, and another bound to the left arrowkey by default that skips 5 seconds backward. Download the encode, then use those keybinds when cutscenes come up. If you're not willing to do something so simple, don't complain. Instead, spend your time watching things you like watching, or better yet, playing Zelda: Ocarina Of Time.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
goofydylan8 wrote:
Lex wrote:
"Boo hoo! I can't read the cutscenes!"
That's ridiculous. We have plenty of Japanese TASes published on this site; even of games which have English versions (like SFC Dragon Quest 5 which has a pretty good fan translation and a DS remake with an official translation).
If this TAS is rejected for something ridiculous like that, I'd leave permanently and hope others would do the same. This is a great TAS. Rejecting something like this just because of language is completely asinine, like Swordless has said. There are more Japanese TASers than TASers here. We should continue to welcome Japanese TASes openly.
If you want to read the cutscenes, play the game. It's meant to be played. TASes are for people who've played the game already, not just a way to watch the game be beaten for you.
I see that, and I've always thought that should be removed. I disagree with it. Japanese is just as legitimate a language as English, and the Japanese version of a game is usually the original version, in the case of console games. Also, it's probable that there are more Japanese TASers than non-Japanese TASers. Alienating such a large user base is a bad idea if TASvideos wants to become more popular and remain that way. Besides, there's the last point in my previous post to consider.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
"Boo hoo! I can't read the cutscenes!"
That's ridiculous. We have plenty of Japanese TASes published on this site; even of games which have English versions (like SFC Dragon Quest 5 which has a pretty good fan translation and a DS remake with an official translation).
If this TAS is rejected for something ridiculous like that, I'd leave permanently and hope others would do the same. This is a great TAS. Rejecting something like this just because of language is completely asinine, like Swordless has said. There are more Japanese TASers than TASers here. We should continue to welcome Japanese TASes openly.
If you want to read the cutscenes, play the game. It's meant to be played. TASes are for people who've played the game already, not just a way to watch the game be beaten for you.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Swordless Link wrote:
I could never get the video to work on VLC or WMP or anything so I just waited til it was on YouTube (Glide64 never works for me so watching it on Mupen wasn't an option).
What are you talking about? Even the 10-bit 4:4:4 video works in VLC here. Are you sure you're using the latest version? I just tried in VLC 2.0.0 and the video runs from beginning to end with correct colors and frame rate.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
If the game can be played back with proper graphics with that run time, then the extra run time isn't necessary. If not, then the extra run time is necessary. Glide Napalm WX seems to be the most accurate, and therefore is what should be used to determine length. The run should be watched without corrupted graphics that aren't actually in the game, shouldn't it?
This is a segment in the game. The X axis are the steps and the Y axis is the danger counter. The white lines are the battles. You get a battle when the red line hits a white line. What we need help with is in calculating the fastest way to avoid battles. In other words, should I menu glitch, stutter (sometimes not possible, easy to see when it is or not possible) or accept+escape a battle. So, I want to know the fastest way through the segment I just posted above. Ideally we will need to optimise the data not just for one segment but for the entire game. Anyone that can give ideas on how to accomplish this?
You can check what filters are currently in use like this (loaded video in screenshot is irrelevant):
Here, you can see I have Haali splitter ("Haali Media Source") in use for this particular file, which happens to be an mkv. If the loaded file was an mp4 file (such as the file we're discussing), you would see "LAV Splitter Source" there instead in my setup. With MPC-HC's internal mp4 splitter, you would see "MPC MP4/MOV Source". I can reproduce your issue, and I'm pretty sure that's it.