Method (7) (Anri-chan HQ encoding) works, but it takes longer than I'd like for a simple timing test.
Avidemux 2.5.4 mp4#
mp4 in Avidemux: 60 FPS, but there is somewhat bad bobbing when I frame advance, making it hard to work with. (8) Encoding the video at HQ in Anri-chan with D4 (half resolution, but the game is almost certainly D1) and then opening the resulting. (7) Encoding the video at HQ in Anri-chan and then opening the resulting. (6) Encoding the video at MQ in Anri-chan and then opening the resulting. vob directly in VLC 2.0.1: frame-by-frame playing sometimes works and sometimes doesn't, and when it works it seems like 30 FPS. vob (DVD file) directly in Avidemux 2.5.4: plays in 30 FPS. (3) Using Anri-chan's trim frame ranges step to analyze the recording in VirtualDub: plays in 30 FPS. (2) Using Anri-chan's field order test step to analyze the recording in VirtualDub: plays in 60 FPS, but there's severe bobbing as I frame advance, making it hard to work with. (1) Playing it on my DVD recorder: frame advance only does 30 FPS, and with no milliseconds on the time display during frame advance, it's quite hard to time things. Again, I want 60 FPS, as well as a relative lack of bobbing for my sanity, but I don't need high resolution. I now want to analyze my DVD recordings in a program such as VirtualDub or Avidemux - something that has frame advance and timestamps for each frame. I've made some test recordings on DVD, since my computer and/or capture card don't seem to be good enough for recording 60 FPS (tried it with XSplit local recording, seems to drop frames like crazy). I'd like to do my measurements from a 60 FPS recording for maximum accuracy. I want to test the speed of various kinds of movement, durations of various attacks, attack hitlag, and stuff like that. filesize) tradeoff of their encode.I want to do some timing measurements in a 60 FPS game that I can't play on emulator (Kirby's Return to Dream Land for Wii I highly doubt my computer can handle Dolphin). I think with that one, they're just making sure that mis-informed people don't disable b-frames and worsen the rate-distortion (quality vs. (which is probably 16, since that's what x264 allows.) x264's default setting of 3 b frames is apparently good. I'm sure their decoder can handle the max consecutive B frames h.264 allows. They're going to xcode the whole video anyway, so using a 1/2 second GOP size is just going to hurt compression. Except the GOP of half the framerate, which makes no sense anyway, and is a horrible idea. The encoding guidelines, are all stuff that's on by default in avidemux.
There aren't any settings that will make youtube use your encode untouched for even one of its standard resolutions, instead of doing a transcode. (CRF 18 is usually visually transparent, you could go CRF 16 to be on the safe side.) It doesn't matter too much what you use for youtube, as long as you use enough bitrate for it to look good. I made a test encode, and the important settings default to on, which is good.
It's pretty essential to have something with a slider for slow to fast presets. I honestly can't recommend avidemux (2.5.4 in Ubuntu 14.04) as a frontend for x264. It doesn't even have a checkbox for more recent (but essential) options like mb-tree, or psycho-visual optimizations (AQ and psy-rd). It's been years since x264 added presets from ultrafast to veryslow, but avidemux still makes you manually choose all the cpu-time vs. Avidemux's dialog box for x264 settings is pretty bad.
0 kommentar(er)
