Joined: 8/3/2004
Posts: 100
Location: Michigan, United States
moozooh wrote:
What the hell. Seriously, what the hell. o_0
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.
Compressed streams aren't even supposed to be compressible. There must be a mistake somewhere, because ZIP compressing FLAC 4 to 1 is pretty ridiculous by itself.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
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.
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?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
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.
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?
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.
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.
Er, what about the examples being posted in this thread of lossless encodes that are smaller than the official, lossy encodes? As noted, it only works for certain games, but if it produces better quality at a smaller filesize, I see little reason to complain.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
"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.
These "news" are from about four years ago. It's been known since the start that H.264 lowers the color resolution even with qp=0. Then again, it's not the only codec to do so.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
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.
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.
I doubled the resolution with my encodes of Star Control II for precisely this reason.
However, doubling the resolution makes the partitions as well as motion detection less efficient, causing more bitrate to be required, so it's a tradeoff. Also, it causes the fullscreen video to look more pixelated than it normally does.
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.
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?
Actually if you double the size you should need 4 times the original bitrate.
That's exactly as silly as saying that if you repeat every character in a text file four times, the resulting file will compress to four times the size compared to compressing the original.
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.
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.
According to x264 dev Dark Shikari, YV12 can look as good as RGB:
