Video recording tips needed

Good day to all members of the community.

I recently stumbled upon this site regarding Nestopia and other NES emulators.

I started making gaming videos for Youtube in 2013. And it gave me an idea to play some great NES games with Nestopia.

However, after trying out with recording and such I stumbled upon some tiny problems regarding Fraps/Dxtory and Nestopia.
I'm using Nestopia 1.40 version. I tried out other emulators but they didn't impress me that much.

I've tried many methods but I still can't solve the problem:
No matter what resolution I use, I always get black bars at the top and the bottom of the screen, or in other case the screen feels like it was zoomed in.

At what resolution should I emulate for Youtube, and is it better looking to stretch the video to full screen or to leave the game "centered" with black bars on left part of the screen and right part of the screen.
Also, what filter do you recommend? Standard, NTSC, ScaleX, Hqx or 2xSaI?

Available resolutions:


I will greatly appreciate any suggestion.

Many thanks in advance.


[Subject Fairy was here --MOD]

Why would you use FRAPS when many emulators can output a video file directly? (FCEUX is quite good for this, for example. Nestopia will let you record a run and then export to AVI.)

As for how to display things on YouTube, you should note that 60fps is not possible, so it is a good idea to blend or interlace down to 30fps. A lot of games have an on/off flicker effect that will cause a sprite to disappear entirely if you simply discard every second frame.

Scaling is a matter of taste. It's a good idea to upscale to 720p or 1080p before uploading, as it will increase the quality a lot. Myself, I usually scale 3x (nearest neighbour) and then pad with a black border out to 1280x720, but you should use whatever scaling method looks nice to you.

Thanks for the reply. I actually didn't know that Nestopia is capable of "recording" on its own. I know that 60fps is still not available on Youtube (technically it is with HTML5) so I know that I must go with 30fps.

I'll wait for other replies as well.

Interlacing is evil. Avoid it whenever possible.

Youtube specifically recommends against adding empty borders. If you must pad to a specific size, at least fill the borders with something.

If you're planning on recording another audio source simultaneously (e.g. Let's Play), you'll probably need to stick with Fraps, since emulators aren't usually geared towards that sort of thing.

Nah, not a fan of Let's Plays.

I recommend this method (it can be done with at least FCEUX, Nestopia and Nintendulator). Controller recordings like this are very lightweight, and you can then do the actual video rendering "offline". A controller recording is completely lossless. In addition this allows you to experiment with different emulation options (like filters) after the fact, as well as trying different video codecs without being tied to a single one.

As for additional audio, it's trivial to record the audio with any audio recording program on the side, and then combine it with the audio from the NES footage later.

It is a blight on humanity, but I would still rather see an interlaced image than have megaman disappear when he takes damage. I would usually prefer blend to interlacing, but there are still cases where I think there is reason to use it (e.g. if you are trying to show something that requires seeing the information in both frames simultaneously, rather than have them blended which destroys the information about frame-separation).


Why? What's better about one static border than another? This suggestion seems pointless. I know there is an admonition not to do something foolish like letterbox a widescreen image and upload it as 4:3, but 16:9 is now the standard aspect ratio, and in my experience YouTube behaves better (especially when cropping previews) with a video padded to 16:9 than one left at 4:3.


It would be better to just record yourself with an audio program like Audacity while you're doing it. The result will be better than FRAPS, since you'll now have two audio signals that you can separately edit and mix. You have to synchronize them, of course, but this is generally very easy to do.

By the way, try to come up with a better thread title next time (you should be able to change it by editing the first post). Also, I feel like this was posted to the wrong subforum. "NESemdev" is meant for discussing emulator development, although the forum description ("Discuss emulation of the Nintendo Entertainment System and Famicom") can be misleading...

Can converting a controller recording to an AVI be done with any emulators designed for X11/Linux? I tried doing it in FCEUX in Wine, and it didn't work. I can retry it and describe the exact symptoms later. Or is about $100 for a copy of Windows 8.1 to run in a VM the recommended way?

For a better explanation: scaling up works around video encoders blurring the heck out of the image (which is especially bad when you have low resolutions), and let's say that YouTube's reencoding process is notorious for its low quality.


It matters a lot if you're watching fullscreen in a different resolution ratio (16:10 is still common around, and monitor manufacturers are trying to push for 2.39:1 now, and don't forget non-PC devices like tablets). If you pad the video and the screen isn't 16:9, you'll basically end up with a video that doesn't fill the entire screen. If you leave it at the original resolution YouTube will adjust the padding accordingly.

Also there's the fact that padding increases the size of the video and thereby the time it takes to stream =P (although not sure how bad is this)

And by the way, re: Nestopia exporting AVI: if you need a good lossless codec which offers good compression, go with Lagarith. I used that to make this (don't blame me for the scaling/etc. -- that's Youtube's fault, not mine). For audio, LAME (using LAME ACM) works quite well, just make sure you pick CBR (to ensure your A/V doesn't get out of sync over time). I prefer to export raw A/V in Nestopia to disk, then use VirtualDub to export the compressed version, but that's me.

Some people browse YouTube on systems that use overscan. For these, it's actually better to pad the 192- or 224-line emulator output to fill the 240-line nominal NTSC field.

The following filter chain should give clear results with correct pixel aspect ratio on platforms that produce NTSC video at TMS9918 dot clock (ColecoVision, SG-1000, SMS, NES, Genesis 256px, Super NES) on YouTube:

1. Export AVI from your emulator at 256x224 or 256x240 pixels.
2. Scale by a factor of 2 with nearest neighbor/point sampling. Width will become 512 pixels, and pixel edges will be sharp.
3. Pad to 560x480 with the background color, to simulate the border that the PPUs add on the sides.
   For Genesis and PlayStation games that output 320 pixels at 5/4 of TMS9918 dot clock, you'll want to pad to 700x480 instead.
4. Scale to 640x480 with linear interpolation.

Thanks for the tip about Lagarith! I had been using uncompressed video when I needed that kind of thing and it becomes a real hard drive access grind. This looks good! (Edit: Hey, cool, YouTube even recognizes it directly! I can use it for my final renders too!)

By the way, choosing constant or variable bitrate for audio, while it does matter a lot for synch when seeking AVIs, when you upload to youtube the audio will be re-encoded anyway so it shouldn't actually make a difference. Still, you should probably choose constant. Most of the time I just use uncompressed audio, since it's usually only a fraction of the video size anyway.

As far as my suggestion to pad, yes, it's true that there are playing environments that are not 16:9, and in this case, unnecessary padding can reduce usable screen space for the player, so if this is a concern, don't do that. Checking how YouTube's thumbnails works, it appears to crop the bottom and top off a 4:3 video frame to make a 16:9 preview image.

As for whether padding increases the video size, no, not generally. The effect is negligible. Non-moving parts of the video should compress to almost zero size with most video codecs. It shouldn't usually make an appreciable difference whether the unmoving area is black or detailed.

It is definitely recommended to upscale your video to 720p or 1080p before uploading. If you leave the video at a 240/480p size, YouTube players will upscale it with linear resampling, which usually looks pretty bad on video games. By choosing a custom upscaling process, you can make something that looks much nicer for most people, and people that want to watch a reduced bandwidth video at 240/480p will still be able to do so. Also, YouTube will encode the audio at higher bitrates to match the resolution used, so it will improve audio quality as well.

Overscan sucks, eh? I'm really glad my nVidia control panel lets me compensate for overscan on the TV I have connected to my PC.

tepples: I don't know about Linux.


The DOSBox codec (ZMBV) is another decent option. I haven't tried Lagarith myself so can't compare.


YMMV, YouTube probably needs to convert the video on their side to get something viewable in browsers. Might be better to do the encoding to the final format yourself (although I'm not sure what codec would best be used for that). Although, I guess YouTube needs to encode the same video in multiple different formats so lossless could be best...

Well yeah but that's more justifiable and makes perfect sense (it's there in the actual video signal), the problem is adding padding that normally would never be there in the first place (i.e. expanding 4:3 to 16:9).


Yep, YouTube will always reencode the video no matter what, even if it's one of the native formats (you could get the right format and right resolution, but are you sure it's the adequate bitrate as well?), and there are many formats all of which have to be available (all of MP4, FMV and WebM, in several resolutions each).

The problem I've seen is that they attempt to detect padding like that, and the player will crop it when you put the video in fullscreen mode. This becomes a problem if that extra padding isn't actually empty for the entire duration of the video, and you might not notice since the video is only cropped if the padding wouldn't fit on the screen. (For example, a 4:3 video padded to 16:9 would look fine fullscreen on a 16:9 monitor, but get cropped fullscreen on a 4:3 monitor.)

At one point, they mentioned this in the FAQ, but I couldn't find it when I looked a few minutes ago.

With a video I made recently, I discovered an unfortunate problem with Lagarith and YouTube. With Lagarith, YouTube will incorrectly treat any solid-colour frame as a "null-frame" and instead show a repeat of the previous frame. This will replace things like a fade-out with a pause on the darkest frame, for example.

You can work around this by using an imperceptibly-different-from-black colour in the picture, maybe in a border or something, or just using a detailed border instead of a solid colour.

Example 1. https://www.youtube.com/watch?v=74FgOr5y6D4
Example 2. https://www.youtube.com/watch?v=PoadqP7Dec8
Example 3. https://www.youtube.com/watch?v=X96wOqrccRo

Question quickly becomes: is this a problem with the encoder process (i.e. design flaw in Lagarith), or in the decoder/re-encoder process (i.e. Youtube)?

Other lossless codecs I've used in the past but can't remember how they behave:

* http://www.compression.ru/video/ls-codec/index_en.html
* http://www.yuvsoft.com/2d-technologies/ ... deo-codec/
* CamStudio's lossless codec, which used to be available somewhere for download/install but I can't find it now :( Edit: I found this but the note about keyframe behaviour sounds pretty ridiculous (if every frame is a keyframe, then there's really no point to using the codec over, say, raw RGB).

Of course there is, so long as each keyframe is losslessly compressed. It'd be like sending a PNG sequence.

The phrase "...and the file size of the output will be too large" I read to mean "won't use any compression". It could simply indicate "injects excessive amount of keyframes compared to source material", but who knows. Love it when software authors are vague.

More like an animated GIF, if GIF supported the required color depth. This is how Fusion's codec works, every frame is compressed, and any pixels that are unchanged from the last frame are stored as gaps (enough of them will compress better). In practice that compression is very bad anyway, but then again the compression it's using is RLE, out of all things, you could probably use a better algorithm first.

It's a problem with YouTube's decoder. VLC and the official lagarith codec play back the videos just fine, it's only when I upload to YouTube I get the solid-frame = null-frame problem.

We should try to figure out sometime how/where to report transcoding problems to Google/Youtube. I swear, the bigger the company the harder it becomes to get in contact with a human being that can actually relay the problem to real engineers. Gruh...

I've submitted a report to YouTube in two different ways so far. I dunno, it's easy for me to work around with a 1-pixel border of colour $010101.

Re-encoding to another format before uploading will effectively work around this problem. For example, MPEG-4/H.264 AVC using x264.

As far as I know, Youtube only supports 8-bit 4:2:0 YCbCr for H.264, but that includes the lossless compression mode. Since YouTube already converts everything to 8-bit 4:2:0 YCbCr, you won't lose any quality by doing the conversion yourself. The compression ratio is a lot better, too, so the files you upload will be a lot smaller for exactly the same quality. (Even comparing the two fairly by forcing both to use RGB, Lagarith is significantly larger since it's keyframe-only.)

Of course, x264 is probably going to be slower than Lagarith when it comes to compression, but it has a selectable speed parameter. Depending on your internet connection, compressing the video to a smaller file may be worth the time spent. You'll probably also need to re-merge the audio with the video, unless someone got around to adding that feature directly to x264 (or you use one of the many frontends that can do that stuff for you automatically - for some reason, it never occurs to me that people don't like using command-line utilities).

Upscaling your video to 480p before uploading, as I described above, will help work around the 4:2:0 limit.