Good day to you all.
First and foremost, let it be noted that I am completely new to the process of encoding. I only started to learn it yesterday (29th August 2013).
Essentially, I have no idea what I am doing and require some assistance.
So as to demonstrate that I have not attempted to help myself, here are some key passages of the Encoder Guidelines that I have read:
... our runs are intended to appear as though they could be played on the original hardware ... Thus, one core guideline for our encodes is to appear, as closely as possible, as though the run was played on the original hardware.
Quality: The video should look and sound as close to the pre-encoding input (i.e. raw emulator output) as possible.
This is what I am attempting to do. Please note that I am not looking to start my own tool - assisted speedruns. I am looking to replicate the aforementioned effect for my Let's Plays. They will be uploaded onto YouTube.
It should also be noted that I am using VirtualDub for this purpose (it is my understanding that this is all I will need; please correct me if I am wrong).
With reference to the Encoding Guide: http://tasvideos.org/EncodingGuide.html
I have followed steps 1 and 3 without trouble. Again, since I am not creating TASs, I have skipped steps 2 and 4. My difficulties lie with step 5: http://tasvideos.org/EncodingGuide/Encoding.html
From this point, please take into consideration the following:
- I am attempting to encode an .avi recording from FCEUX (version 2.2.1).
- I am looking to encode this video to 1080p HD, if possible (720p, if not).
- I am using the built - in .avi recording feature of the FCEUX emulator.
- I have modified FCEUX as specifically recommended by the Encoding Guide (this includes using the Lagarith Lossless Codec, and its own appropriate configurations).
- I am using x264 (64 - bit) with VirtualDub (64 - bit).
The few tutorials which on YouTube which deal with encoding on VirtualDub with x264 are made on the assumption that you're working with a video which has been rendered already. So I took a small gameplay from Mega Man 4 and rendered that.
I used Movie Studio Platinum 12.0, with the default "Video for Windows" (.avi) ---> HD 720p - 60p YUV template.
Afterwards, I put the rendered video into VirtualDub. Then I go to Video ---> Compression. I select the "x264vfw - H.264/MPEG-4 AVC Codec".
Then I click "Configure".
At the bottom where it says "Use command line", I copypaste:
x264 --sar <PAR> --crf 20 --keyint <keyint> --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me umh --merange 64 --subme 10 --trellis 2 --partitions all --input-range pc --range pc --rc-lookahead 250 --no-dct-decimate --tcfile-in times.txt -o video.mp4 in.avi
... as shown in the "Encoding" portion of the Encoding guide. I enter it exactly like that, without changing anything (which I'm fairly certain is the root of my problem).
I then set the ratefactor to 20 (again, as recommended), enable the "Normal recompress" setting and then attempt to save as .avi.
It is here that I get an error (-100) regarding corrupt data.
My questions are these:
1. What am I doing wrong throughout this entire process?
2. Should I not use VirtualDub?
3. Is there an easier method to obtain the results I desire?
Any help would be greatly appreciated. Assume that my computer is sufficiently powerful to handle all but the most intense encoding processes.
This is what I am attempting to do. Please note that I am not looking to start my own tool - assisted speedruns. I am looking to replicate the aforementioned effect for my Let's Plays. They will be uploaded onto YouTube.
From this point, please take into consideration the following:
- I am attempting to encode an .avi recording from FCEUX (version 2.2.1).
- I am looking to encode this video to 1080p HD, if possible (720p, if not).
- I am using the built - in .avi recording feature of the FCEUX emulator.
- I have modified FCEUX as specifically recommended by the Encoding Guide (this includes using the Lagarith Lossless Codec, and its own appropriate configurations).
- I am using x264 (64 - bit) with VirtualDub (64 - bit).
To get maximal quality on Youtube, you should use point scaling by even factor so that width is greater than 1920 or height is greater than 1080.
For NES, which is 256x224, the smallest factor that works is 6 (1536x1344). However, due to how x264 works, using 8 (2048x1796) results in smaller filesize.
Also, lowering the CRF value produces better quality at expense of larger file size.
Regarding audio. Use Vorbis at high quality settings (at least 7) or uncompressed PCM. Beware that Youtube has had bugs in handling FLAC (specifically, parts of audio would go missing).
And if you want good quality, stay away from normal video editors. Those do who knows what to the video (and resaving the video after editing can lose a lot of quality).
... Of course "quality" here is relative. You can't get very good quality on Youtube. And also perennial problem is that youtube supports maximum of 30fps, and many games have effects that have frequencies above 15Hz and thus are not representable without higher framerate (by Nyquist sampling theorem).
For NES, which is 256x224, the smallest factor that works is 6 (1536x1344). However, due to how x264 works, using 8 (2048x1796) results in smaller filesize.
Also, lowering the CRF value produces better quality at expense of larger file size.
Regarding audio. Use Vorbis at high quality settings (at least 7) or uncompressed PCM. Beware that Youtube has had bugs in handling FLAC (specifically, parts of audio would go missing).
And if you want good quality, stay away from normal video editors. Those do who knows what to the video (and resaving the video after editing can lose a lot of quality).
... Of course "quality" here is relative. You can't get very good quality on Youtube. And also perennial problem is that youtube supports maximum of 30fps, and many games have effects that have frequencies above 15Hz and thus are not representable without higher framerate (by Nyquist sampling theorem).
Alright. I guess my question here would be, how would I convert a 256x224 video to 2048x1796 using VirtualDub?
Again, I am a complete newbie at this. In fact, I do not understand much of the terminology you have used (such as "point scaling".
At least I know that truly good quality isn't possible on YouTube. What I am aiming for, however, is akin to this:
http://www.youtube.com/watch?v=R0EoQ23CR7k
... when set to the "1080p" HD resolution.
In fact, I see that you encoded that TAS yourself.
Alright. I guess my question here would be, how would I convert a 256x224 video to 2048x1796 using VirtualDub?
Again, I am a complete newbie at this. In fact, I do not understand much of the terminology you have used (such as "point scaling".
Alright. I guess my question here would be, how would I convert a 256x224 video to 2048x1796 using VirtualDub?
Again, I am a complete newbie at this. In fact, I do not understand much of the terminology you have used (such as "point scaling".
Thank you.
Regarding my use of the command line feature and the part I quoted, do I use it, and if so how would I have to change it to ensure that I do not get an error?
It should also be noted that I am using VirtualDub for this purpose (it is my understanding that this is all I will need; please correct me if I am wrong). [...]
- I am looking to encode this video to 1080p HD, if possible (720p, if not). [...]
- I am using x264 (64-bit) with VirtualDub (64-bit).
Note that for advanced video effects Avisynth is a popular tool; for that it'd probably best to use a 32-bit toolchain. VirtualDub can handle the resizing though; you just set "Video -> Full Processing Mode" and add a resize filter.
inavojo wrote:
At the bottom where it says "Use command line", I copypaste:
x264 --sar <PAR> --crf 20 --keyint <keyint> --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me umh --merange 64 --subme 10 --trellis 2 --partitions all --input-range pc --range pc --rc-lookahead 250 --no-dct-decimate --tcfile-in times.txt -o video.mp4 in.avi
... as shown in the "Encoding" portion of the Encoding guide. I enter it exactly like that, without changing anything (which I'm fairly certain is the root of my problem).
That pasted text is a command-line to be used in a console window (like that of cmd.exe), and you need to use actual parameters for "<PAR>" etc. (open cmd.exe, navigate to where x264 is and use "x264 --fullhelp |more" to see all options).
If you're using VirtualDub then you can select the CRF and SAR values through that; also remove the "-o video.mp4 in.avi" part because files are handled by VirtualDub. You probably don't need the "x264" at the beginning either.
It should also be noted that I am using VirtualDub for this purpose (it is my understanding that this is all I will need; please correct me if I am wrong). [...]
- I am looking to encode this video to 1080p HD, if possible (720p, if not). [...]
- I am using x264 (64-bit) with VirtualDub (64-bit).
Note that for advanced video effects Avisynth is a popular tool; for that it'd probably best to use a 32-bit toolchain. VirtualDub can handle the resizing though; you just set "Video -> Full Processing Mode" and add a resize filter.
inavojo wrote:
At the bottom where it says "Use command line", I copypaste:
x264 --sar <PAR> --crf 20 --keyint <keyint> --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me umh --merange 64 --subme 10 --trellis 2 --partitions all --input-range pc --range pc --rc-lookahead 250 --no-dct-decimate --tcfile-in times.txt -o video.mp4 in.avi
... as shown in the "Encoding" portion of the Encoding guide. I enter it exactly like that, without changing anything (which I'm fairly certain is the root of my problem).
That pasted text is a command-line to be used in a console window (like that of cmd.exe), and you need to use actual parameters for "<PAR>" etc. (open cmd.exe, navigate to where x264 is and use "x264 --fullhelp |more" to see all options).
If you're using VirtualDub then you can select the CRF and SAR values through that; also remove the "-o video.mp4 in.avi" part because files are handled by VirtualDub. You probably don't need the "x264" at the beginning either.
Ah, I should say that I used 7:6 as the value for the parameters (since I'm dealing with the NES).
Do I need to change the "--keyint <keyint>" part to anything?
Also is it possible to get the same results without having to go through all of this with the command line stuff?
Replace <keyint> with a number; it's described on that page.
The command line is actually the most flexible option; you can write batch files if you don't always want to type it out.
encode.bat:
@echo off
x264 --sar 7:6 --crf 20 --keyint 600 --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me umh --merange 64 --subme 10 --trellis 2 --partitions all --input-range pc --range pc --rc-lookahead 250 --no-dct-decimate --tcfile-in times.txt -o video.mp4 %1
Now you can execute it with "encode dump.avi" from the command line or drag'n'drop dump.avi onto the batch file in Explorer.
Replace <keyint> with a number; it's described on that page.
The command line is actually the most flexible option; you can write batch files if you don't always want to type it out.
encode.bat:
@echo off
x264 --sar 7:6 --crf 20 --keyint 600 --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me umh --merange 64 --subme 10 --trellis 2 --partitions all --input-range pc --range pc --rc-lookahead 250 --no-dct-decimate --tcfile-in times.txt -o video.mp4 %1
Now you can execute it with "encode dump.avi" from the command line or drag'n'drop dump.avi onto the batch file in Explorer.
So, what you're saying is, is that I should copypaste what you put into VirtualDub's command line? In that case it didn't work (I excluded "-o video.mp4 %1" as suggested).
I apologize for all these questions, and also if I'm being annoying by asking them. Once again I only started learning about encoding yesterday.
In VirtualDub you can just configure the dialog like this:
(Note that the "VirtualDub hack" checkbox is required for VirtualDubMod; I haven't tested it with the regular VirtualDub. If you use x264vfw in other applications, remove that check.)
Use the "yt:stretch=4:3" youtube tag instead of SAR
YouTube is reencoding, send it lossless
--qp 0
YouTube expects tv709 for HD content
--range tv --colorprim bt709 --transfer bt709 --colormatrix bt709
You could use a .bat file something like this.
@ECHO OFF & ECHO YouTube Encoder for 256x224p60 =^> 2048x1792p30
IF NOT %~x1==.avi ECHO drag+drop .avi & PAUSE & GOTO :EOF
set PATH=C:\mf\NGcode\lib
set "flags=--qp 0 --keyint infinite --range tv"
set "rec=--colorprim bt709 --transfer bt709 --colormatrix bt709"
set "vf=--video-filter resize:2048,1792,,,,point/select_every:2,0"
x264_8 "%~1" -o "v.mkv" %flags% %rec% %vf%
mkvmerge -o "%~n1_.mkv" "v.mkv" -D "%~1"
pause
Thank you all for helping me with the encoding processes. I have experimented with VirtualDub and YouTube, and achieved the results I wanted, visual quality - wise.
Now I'm faced with a new problem.
I'm using VirtualDubMod in an attempt to add commentary to the video. I'm using the "Stream" feature. I add the audio commentary which was recording using Audacity.
I set both audio tracks to "Full processing mode".
Then, I render.
However, after the rendering, I only hear the system audio. If I highlight the volume audio for the commentary track, I only hear that track after rendering. It would appear that VirtualDubMod only allows you to render one at a time.
Is there any way around this, that won't compromise the visual quality? I'm looking to add the commentary audio to the remainder of the video, and to have both clearly audible.
This is what I would do: Watch the video (muted or with headphones) while recording my voice with Audacity or another audio editor; edit the audio; combine gameplay audio and voice in the audio editor to a single audio file; compress file (e.g. with lame), mux compressed audio into encoded video.
inavojo wrote:
Is there any way around this, that won't compromise the visual quality?
I think I've started to get the hang of the encoding process for FCEUX when using VirtualDub. Of course I want to move onto other consoles as well.
So, given the command line I was so generously given (seriously, thanks for that), I'm looking to achieve similar results with snes9x and the VisualBoyAdvance.
I've read that the appropriate dimensions are:
SNES - 256x240 OR 256x224;
VBA - 240x160.
And for the sample aspect ratio:
SNES - 5:4
VBA - ??? (The page I'm looking at doesn't specify).
So, if I keep everything else the same (including the dimensions of 2048x1796), will the video's quality be similar to what the NES looks like?
I've read that the appropriate dimensions are:
SNES - 256x240 OR 256x224;
VBA - 240x160.
And for the sample aspect ratio:
SNES - 5:4
VBA - ??? (The page I'm looking at doesn't specify).
The GBA uses a dot matrix display with square dots, so that 240x160 is already the aspect ratio (3:2 after reducing the numbers).
The SNES, like any other console hooked up to the TV, depends on the characteristics of the TV. It may output 256×224 pixels, but how those are displayed is another matter. (In fact, raw emulator output is too narrow because artists accounted for the stretching!)
A classic SD TV signal contains 525 lines per frame. The first 262.5 lines are the first "field" and contain the even-numbered lines of the frame. The remaining 262.5 lines are the second field, drawing the odd-numbered lines of the frame. By transmitting half a line in the first field, the second field's lines end up being drawn interlaced (vertically shifted) between the lines of the first field. (And the second field's half-line shifts it back to the first field's positions.) The fields are drawn 60000/1001 times per second (b/w TV was exactly 60 fields per second, but color TV needs a little bit more time), and the result is a full frame of 525 lines at 30000/1001 (ca. 29.97003) frames per second. There are no discrete pixels in a line; all you have is an analog voltage (=brightness) curve for each R/G/B electron gun. There's always a little bit of "smearing" (blurring) at the edges.
Most consoles twist this signal a bit. The frequency can be different (SNES' is in fact slightly higher than 60) and most importantly, the normal mode is to omit any half-lines. The result is that there's no vertical shifting; each field is drawn over the previous one, resulting in ~60 frames per second with faint black scanlines where the interlaced lines would've shown up. The number of pixels per line simply means that the console changes the signal that many times per line. You can displays 256 "pixels" per line, all of them of equal size... or 257, 258, 259 etc. with each of them also of equal "pixel" size because the TV is using much smaller phosphor cells. The final aspect ratio is always 4:3 because that's the ratio of the screen's width and height.
The NTSC-encoding unit of the SNES can change the signal 512 times per line; it's just that the video unit can't create "transparencies" (color math) in those video modes, so most games use the 256-pixels-per line modes. (This can even be toggled per line: Secret of Mana 2 uses hi-res mode for text boxes). (Some games like Kirby's Dreamland 3 or Jurassic Park use alternating vertical lines in this mode to create fake transparency - they use the fact that an SD TV won't display pixels as discrete units.) The standard number of lines per SNES frame is 224, or 239 if the game enables overscan mode (useful for PAL TVs). The SNES can also go back to interlace mode; in that case the number of lines is doubled (448 or 478); see RPM Racing for an example (it looks good for static screens and bad in motion). Just to be sure you should always record BizHawk/SNES9x video in hi-res mode.
So for best results the 512x448 emulator output height should be padded to the fully visible NTSC raster height (~483 lines), then it should be stretched horizontally to a 4:3 ratio, and then you can remove the excess black lines. (Or you can just be lazy and bilinear-stretch 512×448 to 1440×1080.)
(Btw. there's even a way to get a 4:3 resolution with "nearest neighbor" scaling: x=7*256 and y=6*224; unfortunately this resolution (1792×1344) can't be displayed by most PC monitors yet.)
inavojo wrote:
So, if I keep everything else the same (including the dimensions of 2048x1796), will the video's quality be similar to what the NES looks like?
Well, imo any video clip that has at least 1080 lines will probably be fine.
Seems like x264vfw is too old (?) so it doesn't know about the --input-range option. You could try updating it, but it probably won't help...
Just use the following: encode.rar
Extract (WinRAR/7-Zip/...) and use the batch file. Edit it to change the parameters.
Seems like x264vfw is too old (?) so it doesn't know about the --input-range option. You could try updating it, but it probably won't help...
Just use the following: encode.rar
Extract (WinRAR/7-Zip/...) and use the batch file. Edit it to change the parameters.
I tried using that, but when I drag and drop the file into the command prompt window, nothing happens.
I am more concerned about the fact that something I used with great success before (from the date on which your screenshot was posted to yesterday) no longer works at all. How can that be? x264 wasnt too old up until then.
I tried using that, but when I drag and drop the file into the command prompt window, nothing happens.
Drag'n'drop it onto the file encode.bat.
This did not work, either.
I think I will continue looking for a solution to this new problem. I just can't grasp how a program which was working just fine a week ago is completely non - functional now.
I tried using that, but when I drag and drop the file into the command prompt window, nothing happens.
Drag'n'drop it onto the file encode.bat.
This did not work, either.
Error message?
Yes.
I've also downloaded xVid and ffdshow codecs to use with VirtualDub, but I have no idea how to go about using those to achieve the same outcomes x264vfw did.
I just wish there was another straightforward method of doing what VDub did.
(Note that the "VirtualDub hack" checkbox is required for VirtualDubMod; I haven't tested it with the regular VirtualDub. If you use x264vfw in other applications, remove that check.)
