I don't think most encoders do, take for example lossless video encoding, only h.264 lossless can make it this small while all other video lossless are still huge in size.
another great codec is msu capture codec: http://compression.ru/video/ls-codec/screen_capture_codec_en.html (to install it in vista, right click and choose "run as administrator")
it's even more effective than h.264 lossless, at least for simple slow moving games, like final fantasy for NES. it's designed for that kind of content and it's often 3 times more effective than h.264 lossless. i think it's only available for windows though.
Cool, nice find! I think it's based on ZMBV which xPi mentioned before.
Hmm I might try this out to see how much of an increase if filesize it would be, but as Bisqwit pointed out, it be more pixelated unless I use something other than nearest neighbor resize. Using a better resizer though, would defiantly increase the bitrate more due to ringing noise introduced.
Are you sure about that? A simple nearest-neighbor upscaling sounds like it would need more bitrate because it introduces tons of hard edges, which are not very mpeg-friendly, while using a filtered upscaling, which smooths the image, sounds a lot more mpeg-friendly.
Hmm I might try this out to see how much of an increase if filesize it would be, but as Bisqwit pointed out, it be more pixelated unless I use something other than nearest neighbor resize. Using a better resizer though, would defiantly increase the bitrate more due to ringing noise introduced.
Are you sure about that? A simple nearest-neighbor upscaling sounds like it would need more bitrate because it introduces tons of hard edges, which are not very mpeg-friendly, while using a filtered upscaling, which smooths the image, sounds a lot more mpeg-friendly.
Hmm. what you say is true, but I think again that is meant only for real life video vs video games since video games already have such hard edges =D. Following my example above where there is 1 sprite moving from left to right, the ringing noise introduced would require more bits because now the static background changes due to the noise, while in nearest-neighbor the background has not changed.
Bottom line, I really don't know but I'll try both out! Which resizer do you think I should try? I know Lanczos adds a ton of ringing noise...
Define "drastically". In my experience it might require something like 20% of bitrate increase, and in some cases not even that.
To put my money where my mouth is (so to speak), I made an actual test: I took the newest published video, ie. the katoken video, up-scaled it to twice the size in both axes (ie. from the original 256x232 to 512x464), allowed myself the about 20% size increase I promised above, and encoded it in h264.
http://kapsi.fi/warp/katoken_test.avi (about 30 MB)
I honestly can't see any significant decrease in quality or significant artifacts (which weren't in the original).
And this was with simple x264 encoding parameters. By fine-tuning these parameters even more I'm pretty certain the file size could be decreased close to the original while maintaining the image quality.
Here is Excitebike in lossless x264 with ogg audio (quality 2) in original resolution and resized to be double vertical and horizontal using nearest neighbor:
http://www.mediafire.com/?sharekey=395c497aee75d1ed111096d429abd360c8926b86791a2455c95965eaa7bc68bc
You will be surprised by the file size difference!
It is nice to see the color bleeding in the red text is gone on the resized version. Maybe the new suggestion is lossless x264 in double res? =D
Warp, I haven't actually downloaded your encode yet, but is there any reason you chose to upscale the lossy original? Why not make a lossless (->RGB32 or RGB24) capture first and work off that?
Warp, I haven't actually downloaded your encode yet, but is there any reason you chose to upscale the lossy original?
Yes; I don't have the emulator nor the rom, and using the avi which I already had in my HD was by far the easiest way of doing this.
I didn't get any advantage for using the avi instead of the raw original material, but I'd say it's the exact opposite. The avi already had some minor artifacts in it, so re-encoding it can only make it worse, not better. Thus if re-encoding the already-slightly-artifacted video preserves the quality, it only makes my point stronger. With the original raw material it might be possible to increase the quality of the final product even further.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Look, I'm not an expert on this subject, but shouldn't you consider different compression codecs/standards?, like lagarith, or YUVsoft's codec?
Also, if you hate the colour compression that badly, can't you just use RGB24 instead of YUY2 or YV12 (or whichever one it is)? why do you have to keep that colour format even when you have to double the resolution. It just seems counter intuitive to me, since weren't YUY2 and YV12 made for a tradeoff between bitrate and artifacts untedectable to the eye and we're talking about lossless compression.
Look, I'm not an expert on this subject, but shouldn't you consider different compression codecs/standards?, like lagarith, or YUVsoft's codec?
Also, if you hate the colour compression that badly, can't you just use RGB24 instead of YUY2 or YV12 (or whichever one it is)? why do you have to keep that colour format even when you have to double the resolution. It just seems counter intuitive to me, since weren't YUY2 and YV12 made for a tradeoff between bitrate and artifacts untedectable to the eye and we're talking about lossless compression.
Lagarith is not an option as that is what I capture in originally and the file is huge =p. It is true, maybe using something like MSU Screen Capture Lossless Codec or ZMBV codec might be a good idea since it would be in the native colorspace, but I think the problem (unsure of this) is that 1. it may only be playable in Windows and 2. it would require the masses to install a less commonly known codec just to play the video.
x264 currently only supports the colorspace of YV12, but maybe in the future it will support other colorspaces. For now, it's stuck at YV12.
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.
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.
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.
Were the samples I posted not good enough?
Nope, you resized both the luma and the chroma with nearest neighbor, resulting in pixelation.
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.
Were the samples I posted not good enough?
Nope, you resized both the luma and the chroma with nearest neighbor, resulting in pixelation.
Hmm, I see. Can you post the Avisynth script when you find it?
the MSU Screen Capture Lossless codec available here
Proprietary codec with industry secrets, and consequently no free-software* decoders exist for it. Unacceptable basis for open video distribution.
Speaking exaggerated, videos encoded with this codec are practically held as hostage by the codec developer: you're subject to their whim if you want to access the videos; because they're the only ones that can supply software that can decode them.
*) As in, anyone can develop a derived product by studying the source code, for example a decoder that runs on the FreeBSD operating system.
the MSU Screen Capture Lossless codec available here
Proprietary codec with industry secrets, and consequently no free-software decoders exist for it. Unacceptable basis for open video distribution.
Oh this was just a test to see how well other codecs can do. As I already stated before, it is not feasible to use them even if they are efficient because again 1. it may only be playable in Windows and 2. it would require the masses to install a less commonly known codec just to play the video.
You just added another reason. 3. Bisqwit said so =p.
It is kind of too bad the MSU Screen Capture Lossless codec isn't widely used. I did a test encode of MMX 1 where the only difference in the Avisynth script is the "ConvertToYV12()" line and the MSU Screen Capture Lossless file was smaller than x264 by 14 MBs! So not only was it in the native colorspace, but it was also more efficient! The x264 encode also took 6 times longer! I am impressed =).
The saturation tweaking compensates for the YV12 conversion darkening and makes the red really look red.
Sample, encoded with Direct264 at CRF18 with Deldup
It does look a lot better than the published SMW encodes, so IMO it's worth it. People have fast connections nowadays, no one cares about the bitrate difference.
I made some test last week and PointResize on sucks on some of my encode(2D psx games): the corner is very poxelized...
BicubicResize have not this problem..
just try:
PointResize is better in this case. We don't want to do any filtering, just simple interpolation. The whole purpose of the scaling is to fit YV12's reduced color resolution.
I made some test last week and PointResize on sucks on some of my encode(2D psx games): the corner is very poxelized...
BicubicResize have not this problem..
just try:
