Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
x264 is by far the best video encoder in terms of quality:bitrate. The double resolution before converting to YV12 method + encoding with x264 is currently the best way to encode RGB quality in terms of quality:bitrate. I'll find a way to do what Dark Shikari suggested with Avisynth and post a sample.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
Warp wrote:
Johannes wrote:
However, doubling the resolution will drastically increase the bitrate needed for the video to look good, and with the site's nature of extremely low bitrates at the cost of quality, I don't see it being beneficial.
Define "drastically". In my experience it might require something like 20% of bitrate increase, and in some cases not even that. (In fact, there are types of video which improve in visual quality with a higher resolution while using the exact same bitrate).
Doubling the video resolution certainly does not require doubling the bitrate to retain the same quality. That's just an odd misconception many people have.
I remember moozooh explained this to you really well. Why do you keep insisting?
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
H.264 is not a codec, it's a video standard. QP has nothing to do with H.264 in general, it's an x264 parameter. The "lowering of color resolution" has nothing to do with H.264 or x264 either, it's the colorspace conversion that causes it - x264 only accepts YV12. The High Profile of the H.264 standard supports some alternate colorspaces, but it's not implemented in x264 yet. Please read up.
And yes, while YV12 looks completely fine for your ordinary film, it does look bad for old, low resolution video games with distinct colors, like NES/SNES. Here's a comparison I made, comparing RGB to YV12:
According to x264 dev Dark Shikari, YV12 can look as good as RGB:
You can encode RGB video currently by doubling the resolution and converting to YV12. The proper way to do this is to pass the chroma planes unmodified, to avoid the issue of resizing the planes twice (upscale, then downscale). This will create video without any chroma bleeding like YV12 creates.
However, doubling the resolution will drastically increase the bitrate needed for the video to look good, and with the site's nature of extremely low bitrates at the cost of quality, I don't see it being beneficial.
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
Lord Tom wrote:
Is anyone working on this now? This (amazingly) is the last remaining game that I played extensively which has not yet been done. If no one is doing it, I might give it a try after my current projects finish up, probably late summer.
I watched some of the youtube footage for what's been done so far and it's quite impressive, though I was shocked that some of them were apparently done without re-records?!
They were done by Jimmy Thai, former FZX champion. That's why he didn't need re-records. (Though he obsoleted a few of them by using re-records)
This game isn't easy to TAS. I tried RR a while ago, and got stuck trying to replicate my first lap's DTD speed in lap 2, and haven't played since. I don't think I'll have the patience or motivation to complete a run myself, so if you have what it takes to make a well optimised run, go ahead. I'll support you all I can.
If anyone wants to see my RR attempt: http://sm64.org/johannes/RR.rar
Experienced Forum User, Published Author, Former player
Joined: 12/1/2007
Posts: 425
ShinyDoofy wrote:
I'm actually capturing it right now so that more people can see this greatness before it's judged. Won't be of any good or even publishable quality, but watchable.
Use CRF at 20-23 with settings like subme, ref, etc. maxed in roozhou's x264 cli build with deldup + MKV output. For resizing, use Spline36Resize(640,480) through avisynth. For audio, use OggEnc with Q5. Then mux them together and post the resulting file here for viewing pleasure. Later you can make one with crappy video and audio quality to fit TASVideos' file size limit. *wonders why I wasted my time writing this text you'll most likely ignore*