What have you guys found works well for recording NES videos?
Which emulator do you use when recording video. Which codec/or other packages have you fond to work well?
So far I've been using Nestopia and the built in recording to record a raw, and then recompressing externally, but its tedious. I'm thinking frapps might be a good option?
Advice for recording video from emulator.
Moderator: Moderators
I used Nintendulator. Compression should be done externally to get better results and quality anyway. Also, imagine you recorded something long using compression while recording, and later you see that the quality is not as good as you wanted, or too high (file is too large). Having uncompressed recording you can easily fix it.
Another way to have ability to tweak compression settings is emulators that are able to record user input - record it first, then play it while recording AVI.
I found that you can get much better quality if the picture is upscaled, at least twice - compression artifacts are very noticeable on 1:1 scale, even with high bitrate.
Regarding external recording tools, in my practice they worked really bad for CPU-intensive apps - low framerate with huge frameskips, etc.
Another way to have ability to tweak compression settings is emulators that are able to record user input - record it first, then play it while recording AVI.
I found that you can get much better quality if the picture is upscaled, at least twice - compression artifacts are very noticeable on 1:1 scale, even with high bitrate.
Regarding external recording tools, in my practice they worked really bad for CPU-intensive apps - low framerate with huge frameskips, etc.
FCEUX can make AVI files, you just pick the video codec.
For a good set of video codecs, get FFDShow Tryouts, the Beta version. Don't get anything newer (No SVN builds) from any codec packs, they are missing the video encoders, the beta version seems to be the only complete build of ffdshow which includes all the encoders.
FFDshow lets you use Xvid and H.264, and that's pretty much what you'll need.
Only problem is that FCEUX doesn't compress audio, you always get PCM. You need another tool to compress that part.
You can also use CamStudio or some other lossless codec, then re-encode it later.
For a good set of video codecs, get FFDShow Tryouts, the Beta version. Don't get anything newer (No SVN builds) from any codec packs, they are missing the video encoders, the beta version seems to be the only complete build of ffdshow which includes all the encoders.
FFDshow lets you use Xvid and H.264, and that's pretty much what you'll need.
Only problem is that FCEUX doesn't compress audio, you always get PCM. You need another tool to compress that part.
You can also use CamStudio or some other lossless codec, then re-encode it later.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
I second this. Capture with a lossless codec so that you have a good master to work with. If you're uploading the video to a place that will re-encode it (YouTube or any other video sites), try a few different codecs and resolutions to see what works better.Dwedit wrote:You can also use CamStudio or some other lossless codec, then re-encode it later.
For capturing via an emulator: SCFH DSF for the video bits, and StereoMix or What-U-Hear (depends on what audio drivers/chip you're using) for recording the audio. Most Realtek audio chips as well as Creative Labs products offer these features (though getting them enabled in Windows 7 is sometimes a pain; look on Google, Microsoft's UI isn't intuitive for enabling the StereoMix stuff).
Regarding audio recording: I DO NOT recommend things like Virtual Audio Cable because the latency induced by this software is atrocious (read the page and you'll understand). Instead just use your audio drivers to capture the audio that goes out your speakers (no need for a physical loopback cable -- that's a pain in the ass anyway and highly error-prone).
For encoding, I use XviD for video, and LAME ACM for audio.
The reason I use XviD rather than a custom video codec: if you plan on releasing these videos using that codec, people are going to have to download the codec and install it (which folks like me will refuse to do based on the premise that I don't want to deal with even more bullshit installed on my PC), and deal with the 32-bit vs. 64-bit ordeal (some codecs only come in one flavour, while people's OSes vary). Youtube's decompressor back-end (in case you ever upload the videos to Youtube) also understand XviD, while it probably won't understand some custom weird codec.
The reason I use LAME ACM for audio: the stock MP3 codec in Windows XP doesn't provide a lot of granularity.
I do the encoding in VirtualDub.
One thing to keep in mind: if you record your audio source at, say, 44kHz 16-bit, keep that sampling rate and bit depth in your final result. Do not re-encode to 22kHz or other things; stick with the original settings. Also only use CBR for the audio bits (if you use MP3), do not use VBR. I cannot stress these two points enough. The end result otherwise will be a video that gradually over time loses audio/video synchronisation. You won't see it in the first few minutes, but if you plan on uploading a 30 minute video, I can assure you that you'll run into this problem. And I KNOW everyone has seen such videos and how fucking annoying they are (nobody these days "proofreads" their work!). VirtualDub has some features/bits in it to try and minimise this, but they don't solve the problem. Doing what I describe in this paragraph absolutely solves it. Audio doesn't make up the majority of an encoded video/audio file anyway, so don't mess about with it.
Regarding audio recording: I DO NOT recommend things like Virtual Audio Cable because the latency induced by this software is atrocious (read the page and you'll understand). Instead just use your audio drivers to capture the audio that goes out your speakers (no need for a physical loopback cable -- that's a pain in the ass anyway and highly error-prone).
For encoding, I use XviD for video, and LAME ACM for audio.
The reason I use XviD rather than a custom video codec: if you plan on releasing these videos using that codec, people are going to have to download the codec and install it (which folks like me will refuse to do based on the premise that I don't want to deal with even more bullshit installed on my PC), and deal with the 32-bit vs. 64-bit ordeal (some codecs only come in one flavour, while people's OSes vary). Youtube's decompressor back-end (in case you ever upload the videos to Youtube) also understand XviD, while it probably won't understand some custom weird codec.
The reason I use LAME ACM for audio: the stock MP3 codec in Windows XP doesn't provide a lot of granularity.
I do the encoding in VirtualDub.
One thing to keep in mind: if you record your audio source at, say, 44kHz 16-bit, keep that sampling rate and bit depth in your final result. Do not re-encode to 22kHz or other things; stick with the original settings. Also only use CBR for the audio bits (if you use MP3), do not use VBR. I cannot stress these two points enough. The end result otherwise will be a video that gradually over time loses audio/video synchronisation. You won't see it in the first few minutes, but if you plan on uploading a 30 minute video, I can assure you that you'll run into this problem. And I KNOW everyone has seen such videos and how fucking annoying they are (nobody these days "proofreads" their work!). VirtualDub has some features/bits in it to try and minimise this, but they don't solve the problem. Doing what I describe in this paragraph absolutely solves it. Audio doesn't make up the majority of an encoded video/audio file anyway, so don't mess about with it.
I believe that using the emulator's export function is always better than using a generic screen capture program over the emulator window... The reason being that an emulator is guaranteed to write all video frames to the output file, while the screen capture program is likely to drop frames (capturing at 60fps isn't easy).
I have no problem with that, except some emulators use weird codecs (depends on the emulator) or choose to do whatever they want (custom format, etc.).tokumaru wrote:I believe that using the emulator's export function is always better than using a generic screen capture program over the emulator window... The reason being that an emulator is guaranteed to write all video frames to the output file, while the screen capture program is likely to drop frames (capturing at 60fps isn't easy).
SCFH DSF can capture a screen region at such a high speed that 60fps is not a problem. I'm talking on a Core 2 Quad Q9550 being able to capture around 1400-1600 fps from a 512x448 region window @ 32-bit. Surprised? :-)
I recommend folks use libtepples. ;Dtepples wrote:Which cross-platform library do you recommend that emulator authors use to write a commonly used audio and video format?koitsu wrote:I have no problem with that, except some emulators use weird codecs (depends on the emulator) or choose to do whatever they want (custom format, etc.).
But that's sort of my point -- I'd rather the emulator not bother with such things and leave it up to utilities like SCFH DSF or other software to capture the screen region. I fully agree that having the recording features within the emulator would be more effective, but I imagine most emulator authors have enough on their minds just with emulation and GUI/OS ordeals, last thing they need are reports of their video/audio recording features not working. Too many eggs in one basket!
Don't all emulators allow you to select the video codec though? If you use something lossless for the initial capture you are free to post-process the video as much as you want later.
Unless you want to capture the filtered (NTSC or whatever) output of the emulator, which I'm not sure can be exported.
Unless you want to capture the filtered (NTSC or whatever) output of the emulator, which I'm not sure can be exported.
Yes, but I've found a lot of Windows-based emulators' AVI exporters don't work so well with my preferred lossless codecs (CamStudio and Huffyuv). They might throw up some incomprehensible error message, or they might crash and ask me to send the details to Microsoft (where free software can't retrieve them, but that's a discussion for another day).tokumaru wrote:Don't all emulators allow you to select the video codec though?
I see the DOSBox lossless codec (ZMBV) hasn't been mentioned yet here. For more info, see here: http://nesdev.com/bbs/viewtopic.php?t=7058.
I've also tested out the "MSU Lossless Video Codec". It was extremely slow to encode video, you can't play in realtime. H.264 was faster to encode.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
I have successfully used this codec. It's great for clean images, like old DOS and NES games.thefox wrote:I see the DOSBox lossless codec (ZMBV) hasn't been mentioned yet here. For more info, see here: http://nesdev.com/bbs/viewtopic.php?t=7058.