Hello,
I have recorded a movie for Mupen64 Re-Recording and would like to do a video encode. I have tried following the directions on the articles page, but I have read somewhere on the forum that they are out of date and no longer reflect standard practice. The movie itself is long -- just a few minutes over 5 hours. Since Mupen dies after recording video files above a few GB, I had to use the AviSplit version (which itself had a few bugs with file naming that I had to correct by rewriting and recompiling). After the recording, I joined these files using mencoder and doing a copy of the video and audio. I now have a giant file (iirc it's around 84 GB) of the entire sequence.
What is the best way to transcode this video to a manageable size? Following the article resulted in a movie with desynced sound. I also haven't seen any forum posts that specifically addressed this problem. I'm looking to have a final encoding with a resolution of 1280x960, although I could settle for smaller if such a beast is impossible to create with a quality bitrate. I don't mind if the final encode is up to 10GB in size. Is using something like MeGUI a viable option?
Just to clarify: this video is not a TAS and I am not seeking a video publication. I hope that won't prevent someone from providing assistance.
Thanks for any help!
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Do you have VirtualDub and ffdshow installed?
If so, I suggest reencoding the video using that, it hasn't failed me yet.
I usually encode into lossless H.264, but since this is a 64 game, it might do you well to process it using a lossy version, I'd suggest doing two passes with a bitrate of 1000... but, that will take forever, perhaps a single pass of 1500?
I haven't encoded any Nintendo 64 games in my time, my hidden dirty secret.
What format is the RAW in? Meaning what video codec and what audio codec? MeGUI is viable, except the things in it is a bit outdated. It really should be AviSynth + x264, IMO. AviSynth allows you to join clips together, so you really didn't need to combine the files into 1 huge file. The audio desync, I'm assuming it isn't in the RAW file?
PS: If you go on IRC, I can help you better there.
I don't have the video files with me at the moment, but I recorded using the settings described in the article: ffdshow with H.264 lossless video and sound settings which I completely forget. I have AviSynth, VirtualDub, ffdshow, mencoder, etc. installed and will install whatever it takes to get this done (I'm doing the encoding on a dedicated computer whose fate doesn't concern me).
It is not easy to tell whether or not the sound desync happens in the RAW file since my drives are not capable of handling the bitrate; but as far as I can tell the desync isn't there. I'm guessing that it has something to do with the muxing stage in the article, but I could be completely making things up since this is new territory for me.
I'll be able to be on IRC later tonight, perhaps around 00:00 UTC (7:00 PM ET).
Drag the video into AvsP (an AviSynth script editor) and add a new line with the text "info.Crop(0, 0, 400, 300)" in it. Press F5; it should display the topleft corner of the video with some info on it. Check if the audio length differs greatly from the video length, or if the video has an unusual FPS.
To see audio issues the AviSynth plugin AudioGraph may be useful; use "ConvertToYUY2.AudioGraph(1)", scroll to the end of the video and see if the waveforms match the actions in the video.
To fix issues use the "TimeStretch" function. Use the "rate" parameter slightly above or below 100. Testing in realtime might be difficult though if your system can't handle playback...
N64 games should be fine at 640x480. Record to a lossless format for editing. For lossless RGB use the CamStudio codec (fast) or the ZMBV codec (small files, doesn't like 24-bit sources). For lossless YV12 use FFDShow's HuffYUV ("HFYU", "YV12", "Median", "adaptive tables" checked) or the original Huffyuv codec. (Emulators output in RGB.)
For downsizing try the GaussResize function (upscaling should be fine with BilinearResize). Test a few values for p.
For the final encode I'd use x264 with a constant ratefactor (not constant quantizer). A value of 16 should look almost like the original; larger values compress more. For audio you can use the lame codec in VirtualDubMod, or extract the audio into a WAV file + encode it on the command line + merge video and audio with MKVMerge GUI.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
creaothceann wrote:
A value of 16 should look almost like the original; larger values compress more.
Most publications on the site these days use a rate factor of 20, if you want a basis for comparison.
creaothceann wrote:
For audio you can use the lame codec in VirtualDubMod, or extract the audio into a WAV file + encode it on the command line + merge video and audio with MKVMerge GUI.
I would recommend the latter method (partly because there are better audio codecs than MP3 these days in terms of quality and file size).
Meh. This is old, but anyway.
In my experience, bitrate 2-pass compresses way better than constant rate factor. Hit the right bitrate and it will be way smaller than the same quality as constant rate factor. This is using MeGUI's profiles, so there shouldn't be any problems, I hope. And no, MeGUI isn't outdated, nor is it bad. It is a very good encoding tool. Remember that it only loads .avs files, so any avisynth that you think is needed can be added to the .avs file loaded into MeGUI.
For audio, I would just recommend BeHappy. BeHappy and Nero's AAC tool is what I use to encode. Terrific quality at low bitrates and no messing with extraction or command-line tools. It's a snap, and it's fast.
You guys are all very late. I already helped him and he's done now.. lol
EEssentia: While 2-pass does distribute the bits better, it's quality is only slightly better than CRF. The main problem is guessing the bitrate. Unless you wanna reencode the file 10 times just to find the bitrate you "like", CRF is a lot faster. There is a middle road though. That is encode in CRF first just to find what bitrate, and then encode it again in 2-pass. It's basically like 3-pass.
Also MeGUI is nice and newbie friendly, except last time I checked, the x264 MeGUI updates to is really outdated.
Most publications on the site these days use a rate factor of 20, if you want a basis for comparison.
I see. :)
EEssentia wrote:
In my experience, bitrate 2-pass compresses way better than constant rate factor. Hit the right bitrate and it will be way smaller than the same quality as constant rate factor.
Yeah, but trying out many 2-pass settings for a 5-hour video might be something for a Zen master. :) Maybe with a short representative selection...
EEssentia wrote:
You guys are all very late. I already helped him and he's done now.. lol
Yeah, I figured!
EEssentia: While 2-pass does distribute the bits better, it's quality is only slightly better than CRF. The main problem is guessing the bitrate. Unless you wanna reencode the file 10 times just to find the bitrate you "like", CRF is a lot faster. There is a middle road though. That is encode in CRF first just to find what bitrate, and then encode it again in 2-pass. It's basically like 3-pass.
The problem is indeed the bitrate, but you can get the same quality with substantially less bitrate with 2-pass bitrate, so that is why I would recommend it over constant rate factor. It may be in the range of 2-3 times more efficient.
Also MeGUI is nice and newbie friendly, except last time I checked, the x264 MeGUI updates to is really outdated.
Thankfully, you can replace those with up-to-date ones fresh from x264.nl ;)
The problem is indeed the bitrate, but you can get the same quality with substantially less bitrate with 2-pass bitrate, so that is why I would recommend it over constant rate factor. It may be in the range of 2-3 times more efficient.
This is wrong though, it may be only 1% more efficient. Nowhere near 2-3 times.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Aktan wrote:
EEssentia wrote:
The problem is indeed the bitrate, but you can get the same quality with substantially less bitrate with 2-pass bitrate, so that is why I would recommend it over constant rate factor. It may be in the range of 2-3 times more efficient.
This is wrong though, it may be only 1% more efficient. Nowhere near 2-3 times.
(emphasis mine)
"May be" is a poor argument here. The results vary considerably depending on exactly what it is that you're encoding.
An approach that I have taken in the past is to use --crf 20 on a sample segment to get an approximate target bit rate, and then experiment with bit rates in that vicinity. This can be overly time-consuming if --crf 20 is "good enough"; I usually only go through with it if --crf 20 gives particularly poor results on the bit rate front (as happens occasionally with runs for recent platforms and/or some Genesis runs).
In most cases, I have found --crf 20 yields bit rates comparable to what we consider to be "good visual quality" for publication purposes. There are exceptions, but for the type of work we do on the site the difference is usually closer to Aktan's quoted estimate than anywhere near 2-3 times off the mark.
EDIT: By the way, with the level of knowledge of encoding some of the people here are demonstrating, I'd encourage giving encoding some of the runs in the queue a try. A little practical knowledge in what the site needs from encodes goes a long way in these sorts of discussions, and we can always use more encoders!
"May be" is a poor argument here. The results vary considerably depending on exactly what it is that you're encoding.
An approach that I have taken in the past is to use --crf 20 on a sample segment to get an approximate target bit rate, and then experiment with bit rates in that vicinity. This can be overly time-consuming if --crf 20 is "good enough"; I usually only go through with it if --crf 20 gives particularly poor results on the bit rate front (as happens occasionally with runs for recent platforms and/or some Genesis runs).
In most cases, I have found --crf 20 yields bit rates comparable to what we consider to be "good visual quality" for publication purposes. There are exceptions, but for the type of work we do on the site the difference is usually closer to Aktan's quoted estimate than anywhere near 2-3 times off the mark.
EDIT: By the way, with the level of knowledge of encoding some of the people here are demonstrating, I'd encourage giving encoding some of the runs in the queue a try. A little practical knowledge in what the site needs from encodes goes a long way in these sorts of discussions, and we can always use more encoders!
I'm not talking about what CRF setting is good or what bitrate setting is good. I'm talking about how well CRF and 2-pass distribute bits. If you compare CRF and 2-pass at the same bitrate, does 2-pass look better? Both CRF and 2-pass have different ways of distributing bits, and I'm saying that both does a very good job with 2-pass being 1% better.
I'm not sure if we're implying the same thing!
In my experience, CRF consumes way too much bitrate in hitting a desired "quality" factor. I may need to experiment with this feature, but my results so far have shown that I have been able to hit much lower size with 2-pass bitrate instead (with same visual quality, basically) of CRF (which I used before).
But anyway, this is not a fact. This is merely my experience. Others may vary. Not enough expert in that area to bust a myth, if there is one.
I'm not sure if we're implying the same thing!
In my experience, CRF consumes way too much bitrate in hitting a desired "quality" factor. I may need to experiment with this feature, but my results so far have shown that I have been able to hit much lower size with 2-pass bitrate instead (with same visual quality, basically) of CRF (which I used before).
Ever think that maybe you just set a CRF way too high? The only way to test, is find a bitrate, and have both hit that bitrate, then compare. If 2-pass is indeed better, the CRF at the same bitrate should look terrible. If both looks pretty much the same, it just means you've been setting a way too high CRF.
I don't remember now, but I do believe the possibility must have occured to me...
But I might just try it out again in the future.
There is another thing, though. It seems that CRF might also vary greatly depending on the source, and that just kindof seems to defeat the purpose of it. Except that it's faster since it's 1-pass.
I don't remember now, but I do believe the possibility must have occured to me...
But I might just try it out again in the future.
There is another thing, though. It seems that CRF might also vary greatly depending on the source, and that just kindof seems to defeat the purpose of it. Except that it's faster since it's 1-pass.
Not at all, sources do vary greatly in terms of how compressible it is. Take a clip which is just still motion, vs a clip with all fast motion. Which do you think needs more bits? Btw, just to clarify, "CRF way too high" really means a CRF value way too small, but I think you got what I meant.
