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.
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.
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
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...
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.
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.
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.
No. Lossless compression is never bitrate efficient. CRF18 will look almost as good, and it's way smaller.
I'm not sure I agree. Lets take a simple example. Lets say we have 5 frames where it is completely static and have absolutely ZERO difference between them. In the lossy encode, since the encoded reference frame is lossy, there will be differences between the reference frame and the current frame in which then bits are needed to store this difference. Now normally in real life video, this will NEVER happen, but in something like video games, this happens often.
Now lets take a more complex example. Lets say in the 5 frames a sprite is moving from left to right. In the lossy encode, not only would it have bits for the motion of the sprite, it will also have bits to store the difference in the static background because (again) the reference frame is lossy and will be different than the current frame. In the lossless encode though, only the motion and nothing else of the spite is stored. In this example most of the bits are in the frist reference frame and the rest is just motion data.
Dwedit wrote:
"Lossless" X264 isn't lossless. If it was lossless, there would be under 25 colors in the optimized palette for that frame. If there are any chroma subsampling features, make sure they are disabled.
Also, zoom in on that goomba and see how crappy it looks.
As I pointed in an earlier post and Johannes re-explained, you are correct it isn't really lossless because the color is off, but this is not because x264 isn't lossy, but due to the colorspace conversion. Converting from RGB to YV12 already saves some space since color is stored in 12 bit instead of 24 bit.
it seems as if flac did not expect the source audio to be so simple and perfectly clean like the output of an emulator.
maybe it only deals with one block of audio samples at a time.
such repetitive input would then make repetitive output, which general compressors exploit.
this might be something flac can deal with
what if flac's creators decided not to do this for speed and statistical reasons?
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. I think audio just has a long way to go.
That might be due to color palette used. NES only had what, 48-something simultaneous colors onscreen? Tile-based graphics layout also helps a lot with motion estimation.
Have you tried Genesis and GBx titles yet?
That might be part of it, but I notice a lot of bits being used for fades also in SNES Zelda:LttP. I have tried GBC like I posted a video of Pokemon Yellow and it seem to work even better. I have not tried Genesis yet but like you speculate, I think it would work also.
Ok, I haven't posted here in a while, but I have to second that. Does anyone know if this has been brought to the attention of those developing FLAC? Of course, I'm guessing FLAC+7z can't be that effective with all source material, but that particular example is certainly impressive!
I'd like to see some examples of lossless x264 encodes. Hopefully hosted somewhere other than MegaShare, since it seems to be down, or I can't get to it.
I've been thinking that 2D TASes would be the ideal candidate for a custom lossless codec for quite a while now. Looks like it's actually becoming a reality.
Here is Rockman 2 with audio stolen from the submitted video:
http://www.mediafire.com/?sharekey=395c497aee75d1ed111096d429abd360e04e75f6e8ebb871
I stole the audio so that the only difference between this video and the submitted one is the video (plus the missing intro and subtitle :P). The file is smaller than the submitted video and I really doubt the missing stuff would add on much extra.
The encoding settings I used for this video is a little bit different than what I posted before:
program --qp 0 --keyint 601 --min-keyint 0 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid --weightb --direct auto --nf --subme 9 --trellis 2 --partitions all --8x8dct --me tesa --merange 64 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"
The only difference is the "--merange 64" which shaved off a few MBs at the cost of 4x longer encode (lol). I got this from ShinyDoofy (Thanks!).
Even with this parameter though, SNES lossess encodes don't seem possible. My encode of SNES Zelda: LttP was still huge.
I do, should I get rid of the lossless FLAC audio?
Are you using the lossless setting from an orginal capture videos or directly from this site? Maybe it would be better for the sound if your try some "hard" test.
It's from an original capture. I'm not sure what you mean by a "hard" test.
BadPotato wrote:
Aktanusa wrote:
- YouTube does not currently support lossless x264. Their decoder seem to be outdated.
Does .FLV format support lossless setting? If that so, I would to see how fast a videos could be loaded on some flash player!
Since FLV is just a container, I would think it does support it. The real question is more like if Adobe's Flash Player can play lossless H.264. Though of course if you use something like MPC's FLV splitter, then ffdshow can decode it fine.
find out what compression you get after putting flac in a zip file.
24/04/2009 10:37 PM 44,523,464 gia-pkmnyellow.wav
24/04/2009 10:37 PM 10,570,987 gia-pkmnyellow.flac
26/04/2009 12:37 AM 1,932,260 gia-pkmnyellow.flac.7z
26/04/2009 01:36 AM 2,410,809 gia-pkmnyellow.flac.zip
Yea, I know wav compression got a bit to go, might be something to do with seeking that makes it hard to compress... who knows
Yes, it is Rockman 2. Still, you used the American ROM, which is not how it's supposed to be ;)
Other than that, have you actually watched the published encode of said submission? I for one don't see any real difference (yeah, the subtitles create some artifacts, whatever) between those two. I guess the sound might be a different issue: again, I don't hear any difference at all. Maybe somebody with better trained ears can comment on that.
And just another overall notice: Those encodes sure might be great for quality junkies, but they might get themselves the emulator and ROM themselves if they strive for superb visual and acoustic perfection. For actual publication, those encodes clearly violate the premise of small filesize. I don't mean to crush your work by that, I'm just saying. If you want to help out by encoding unpublished runs for the masses, then be my guest (adelikat might have a different opinion on that...).
That's the thing, I didn't use the American ROM. I used a translated ROM from Rockman 2 to add english ;).
The point of this topic was, I can make it lossless and it is SMALLER than the submission. I repeat SMALLER. The only reason why it is huge now is becuase of the audio. If you want I can post the file where it is lossless and with the same audio as the submission. It will be SMALLER.
Double Dragon II with FLAC audio:
http://www.MegaShare.com/813560
It seems people are having trouble, so I will upload to MediaFire, but before I do, should I get rid of the lossless FLAC audio?
Yeah... no, thanks.
Besides: Rockman 2 != Mega Man 2
Is it because the file is too big? I thought there may be complaints on that, so I can reupload w/o the huge lossless audio.
This is a video of this http://tasvideos.org/2162S.html which is Rockman 2. I could of sworn MM2 is just the renamed of Japanese version of Rockman 2 + adding an easy mode.
Pokemon Yellow with FLAC audio (the file is mostly audio!)
http://www.MegaShare.com/811134
Note: If it doesn't decode correctly you need to update to a newer version of ffdshow (Windows only)
vba-rr encoded 15154 frames of gia-pokemonyellow, which I then encoded to ffdshow h264 lossless, ZMBV codec from dosbox, and used 7-Zip at max settings on the .wav
h.264 Lossless YV12: 2.4MB
ZMBV 16-bit RGB: 991KB
uncompressed audio: 42MB
wav in a .7z: 857KB
to get ZMBV to accept 24-bit video, make VirtualDub change the Colour Depth to 16-bit RGB (555) or 32-bit RGB.
my 7-Zip 7z settings: first set Compression level to Ultra then change Word size to 273
using 7-Zip compresses the ZMBV even further:
16-bit ZMBV: 991K
32-bit ZMBV: 1487K
16-bit ZMBV.7z: 450K
32-bit ZMBV.7z: 794K
I wish that slider thing in ZMBV codec config would do something...
Using the settings I posted in the previous post, I get a file size of 848 KB (video only) for Pokemon Yellow =). Of course since x264 is in YV12 colorspace, it can't compare to the RGB version of ZMBV.
Edit: Well I found out the that VBA doesn't like recording AVIs in turbo speed as frames get dropped. So I reencoded Pokemon Yellow again this time w/o the missing frames and the file size jumped to 1.07 MB
By comparison, most of the 10:30 minute NES videos I encode, upscaled to 320x240 (still lossless), are about 50MB.
When I did lossless for Double Dragon 2, the size I got (video only) was 12.7 MB. Maybe it's the settings I use? Again I can post the file if you would like.
Look closer. Bolded the important thing in my comparison.
Then again, mine have audio included too and it probably isn't encoded very well...
Yep when I resize to 320x240 using Lanczos4Resize (there is a ton of ringing), the file size skyrocketed. Why are you resizing? It adds ringing artifacts (depending on the resizer) and you can make the DAR 4:3 easily with just a flag in the MKV container. Also if you have the lossless source (minus the colorspace conversion which isn't lossless) you can resize if you need to later. I don't see a point to the resize.
moozooh wrote:
Aktanusa wrote:
When I did lossless for Double Dragon 2, the size I got (video only) was 12.7 MB. Maybe it's the settings I use? Again I can post the file if you would like.
Actually, your commandline would be more interesting to see.
I redid my Double Dragon 2 video with a more sensible keyframe interval and got a file size of 13.5 MB. Here is my commandline as given by MeGUI (close enough):
program --qp 0 --keyint 601 --min-keyint 0 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid --weightb --direct auto --nf --subme 9 --trellis 2 --partitions all --8x8dct --me tesa --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"
Mind you b-frames aren't really used in lossless mode as they don't make sense. Those b-frame settings are actually ignored by x264. Also I'm using build 1139 of x264 which is quite recent.
I've noticed for SNES Zelda:LttP that the fades are eating up a lot of bits causing my file to be big. So lossless encoding "may" work for SNES too as long as there are not many fades.
Double Dragon 2: size: 19 MB, length: 10:33
By comparison, most of the 10:30 minute NES videos I encode, upscaled to 320x240 (still lossless), are about 50MB.
I really don't think using lossless x264 for "shorter" (under an hour? 30m?) movies is a bad idea, given the comparisons.
When I did lossless for Double Dragon 2, the size I got (video only) was 12.7 MB. Maybe it's the settings I use? Again I can post the file if you would like.
Nach wrote:
You can still get visually lossless without using lossless mode though. Some of my encodes aside from the intro logo are virtually indistinguishable from lossless mode.
The point I was making is that lossless mode actually create smaller files than lossy when lossy is encoded to the point that it looks visually lossless.
My observation maybe only applies to NES games. I just tried SNES Zelda and got a bigger encode than the posted video.
I'm not sure if someone has suggested this before, but I think encoding the TAS Videos to lossless x264 is quite possible. Since video games are using constant sprites, the changes between frames are minimal and the amount of bits needed to capture motion is quite small. For example, my lossless encode of the latest Rockman 2 is only 33 MBs (video only and somewhat a cheat since keyframe interval was set to 99999) (great job by Timo Taipaleenmäki btw). The posted video in turn is 52 MB with audio.
The reason why lossless is so much smaller is because lossy adds artifacts in which require more bits to capture the differences between frames. Since lossless is, well, lossless, the differences between frames is smaller since it is just a constant sprite moving around.
So what do you guys think?
Notes:
- In order to play lossess x264, you need a newer version of ffdshow (after Jan, 2009)
- YouTube does not currently support lossless x264. Their decoder seem to be outdated.
PS: I can host the Rockman 2 encode somewhere if you guys want
