VisualBoyAdvance-M

I have found two annoying problems when trying to record AVI videos. I'm using build 589, which I think is the latest one. My video settings are:

 

Filter: Nearest

OpenGL

• Filter: Nearest

Triple Buffering

 

The first bug is that the color is completely botchered in any videos I record with this version. This seems to be new with VBA-M, as I've NEVER seen it in VBA 1.7.2, 1.7.3, 1.8.0beta3, re-recording19, or re-recording20.

 

I have a few screenshots to show what happens in the AVI videos I try to create. The left is what it SHOULD look like (which is a screenshot from the game), the right screenshot is taken from one frame of the AVI video I tried to make.

 

 

 

As you can see, it doesn't look right AT ALL... It seems to hate reds, oranges, browns, and yellows, which makes them all blue, and it doesn't like blue either, which it turns to orange. And the green turns to a more lime green. The only color that doesn't seem to be affected is purple. And by the way, the problem isn't the game, because I've made many videos from this game on past versions of VBA without this problem. But just to make sure, I tried another game as well (once again, the left is a screenshot from the game, and the right is one frame from another AVI video):

 

 

Yep, same problem.

 

Now, another bug, which has been around since the beginning (however, this problem isn't present in TAS versions, interestingly enough, but it is in all other versions). AVI videos have nasty desynching issues. The biggest problem is that every time there is a loading screen (i.e. a white screen, such as when you exit an area and enter another) when playing a GB or GBC game, the video jumps ahead way too far and gets ahead of the sound. And when a video has tons of these loading screens, the video jumps so far ahead that it may not even be remotely close to the sound. I think this is because the emulator thinks it's lagging when it happens -- notice that when you encounter a loading screen by entering some other part of the game, the speed that the emulator shows drops down to around 80% or so for about a second. Here are two crude diagrams I whipped up to give you an idea of how VBA handles AVI videos:

 

This is what theoretically SHOULD happen when you record and you come across a loading screen:

 

 

However, this is what really happens... the video portion jumps ahead, because VBA thinks it's lag:

 

 

And even without this loading screen issue, the video overall goes slightly faster than the audio -- I'm not sure exactly how much faster, but it's enough to cause the sound to lag behind by at least one second in a video that's at least two minutes long without loading screens.

 

Whew -- this was a long post. But I hope I made my point across. /emoticons/smile@2x.png 2x" width="20" height="20" />

Thank you for the bug reports. [img]<fileStore.core_Emoticons>/emoticons/smile.png[/img]/emoticons/smile@2x.png 2x" width="20" height="20" />

You're welcome... I found some more bugs by the way... should I create a new topic (since it has nothing to do with AVI recording) for each one, or continue posting them in this topic?

 

Also, I realized that the problem with the first bug seems to be caused by mixing up red and blue values.

Yes. Be sure to put the topic/s in the appropriate forum. Thank you. [img]<fileStore.core_Emoticons>/emoticons/smile.png[/img]/emoticons/smile@2x.png 2x" width="20" height="20" />

The AVI desync bug already startled me months ago, but I did not yet manage to fix it.

However, Nach said he wanted to do something about it back then (use ZSNES recording code), IIRC, but nothing has happened so far. I was thinking about using DirectShow or ffmpeg or something like that to do the recording in any format, but I have no experience with that yet.

 

 

The color bug seems like a simple swap of the Red and Blue bytes in every color value, just look how the 100% red gets 100% blue and vice versa, the intermediate colors are changed accordingly.

 

 

IMO, the video recording system needs a complete overhaul.

The AVI desync bug already startled me months ago, but I did not yet manage to fix it.
However, Nach said he wanted to do something about it back then (use ZSNES recording code), IIRC, but nothing has happened so far. I was thinking about using DirectShow or ffmpeg or something like that to do the recording in any format, but I have no experience with that yet.

 

Yah, Nach knows his stuff about AVI encoding and things related. Speaking personally, I haven't dealt with AVI encoding APIs before like VFW or using memcoder. Maybe when the Qt4 GUI is more mature, we can do something proper about it then. Plus, then Nach can easily lend a hand, as he deals with Linux mostly, AFAIK.

I suggest using the Nestopia recording method.

 

instead of recording actual footage of the game, it records the actions of the gameplay.

 

after you stop recording, it then converts the gameplay into an avi, of which you can choose from different codecs

I suggest using the Nestopia recording method.

 

instead of recording actual footage of the game, it records the actions of the gameplay.

 

after you stop recording, it then converts the gameplay into an avi, of which you can choose from different codecs

 

I remember when recording the actual footage of the game (i.e. when you choose "Start movie recording...") that was glitchy too, particularly with GB and GBC games. Sometimes, whenever there is a loading screen, the movie would just instantly stop recording by itself without even telling you, which is very aggravating when playing it back and realizing that it stops in the middle of it. Of course, THIS bug, like the video/audio desync bug, was also fixed in the TAS version.

 

There are actually many things I liked about the TAS version, but the only reason why I don't use it is because the sound quality, which is based off of 1.7.2, is vastly inferior to VBA-M.

With VBAM build 878, the video/audio syncing seems to be better than before, but there are still some issues with it.

 

• It seems that the audio is initially skewed approximately 150 milliseconds (0.15 seconds) ahead of the video. I'm not sure what the exact offset is, but whenever I use VirtualDub (v1.8.8, not that it should matter) to skew the audio of any video by 150 ms, it lines up without any noticeable desyncing.

 

• Like many other previous versions of VBA, it also seems that the video's framerate is slightly fast, fast enough to cause a noticeable enough video/audio desync. How fast? Well, when I used VirtualDub to adjust the frame rate from 60fps to 59.85fps (go to Video -> Frame Rate, click "Change frame rate to (fps)", and enter 59.85), there was no longer a desync. Again, this estimate of 59.85 is probably very slightly off, but I didn't notice any more desyncing in 2-3 minute videos with this adjusted framerate. Therefore, before fixing any video, the framerate seems to be 60/59.85 of what it should be, or a little more than 1.0025%. (Another possibility is that the sound may be too slow, as opposed to the video being too fast, but I doubt it, because AVI videos SOUND right when I play them.)

 

• While the GB/GBC "loading screen desync" bug has mostly been fixed, it still happens in some occasions (thankfully, nowhere near as many). I haven't tested this thoroughly yet, and I only tested two games so far with recording AVIs from VBAM 878, so I can only mention one case so far. In Donkey Kong Land, whenever the game loads a map screen, there is a case of a "loading screen desync" -- the video jumps ahead of the audio, and the AVI just cuts out most of the loading screen, which causes the desync. If you make an AVI of loading any map in DKL, you'll see that the loading screen is unusually short. I haven't yet seen any other cases of this in DKL, though. I've also made a few AVIs of Donkey Kong Land 2 from VBAM 878, and have yet to see any cases of "loading screen desyncs" in this game. I will report any other cases of "loading screen desyncs" if I find them in VBAM 878.

Blaziken, use Audio synching instead of vsynching.