Captures of streamkillers
category: general [glöplog]
Hi,
Does anyone sit on an archive of high-quality captures of hard-to-encode demos (aka streamkillers)? I'd guess stuff like Through the cracks, Michigan, or basically any Satori demo. Presumably in 720p or higher H.264 (capped.tv appears to be mostly lower resolutions), and then encoded in high enough bitrate to make it largely transparent.
The motivation is simple; I'd like to see how badly my stream setup handles streamkillers, and testing off YouTube videos sort of doesn't cut it when they're already pre-compressed to death. Of course, no stream will survive stuff like this quality-wise, but I've seen a worrying tendency of encoders to also get problems with CPU, and that's a no-no that I'd like to explore and possibly see if I can work around.
Does anyone sit on an archive of high-quality captures of hard-to-encode demos (aka streamkillers)? I'd guess stuff like Through the cracks, Michigan, or basically any Satori demo. Presumably in 720p or higher H.264 (capped.tv appears to be mostly lower resolutions), and then encoded in high enough bitrate to make it largely transparent.
The motivation is simple; I'd like to see how badly my stream setup handles streamkillers, and testing off YouTube videos sort of doesn't cut it when they're already pre-compressed to death. Of course, no stream will survive stuff like this quality-wise, but I've seen a worrying tendency of encoders to also get problems with CPU, and that's a no-no that I'd like to explore and possibly see if I can work around.
those mfx noise demos are nice test
http://www.pouet.net/prod.php?which=52988
has video on 720p available, dont quite remember if it was of any decent quality or also had a lot of compression artifacts
has video on 720p available, dont quite remember if it was of any decent quality or also had a lot of compression artifacts
psenough: That's a great capture, thanks.
Strangely enough it's in 24 fps, but perhaps the demo is in 24 fps, too? (It has all the hallmarks of a great streamkiller, though. The poor capture is in like ~35 Mbit/sec _average_.)
Here is a list of captures I did a few years ago, all are either 720p or 1080p as far as I remember. While I havn't checked preciesly if anything meets your criteria, you can have a look and download anything that might help you, if there is anything :)
Ok, so after re-antiquating myself with that list some of the older intros and demos are clearly not going to be 720p, but the majority of the more recent productions are, the file size is a dead give away. I probably should have labelled each one properly, but on my local hdd I can see the meta data I just didn't think to add it at the time.
keito: At least ASD's “Butterfly Effect” seems to be relatively well-suited, at least as a mid-level one. I didn't actually know it had so much fine detail before seeing your capture :-) I'll need to have a look through the others to see if I can find something obviously bad.
I find it curious that many of the streamkillers manage to do so without a huge amount of movement in the picture. And judging from the mfx and Still examples, the chroma channel can even be completely blank.
I find it curious that many of the streamkillers manage to do so without a huge amount of movement in the picture. And judging from the mfx and Still examples, the chroma channel can even be completely blank.
One thing really missing: Blinking. Tends to upset encoders a lot.
migracija/kosmoplovci has a lot of blinking and looks crappy on youtube because of it.
capped.tv has links to a few video captures.
capped.tv has links to a few video captures.
Textmode stuff, perhaps?
The textmode demos I saw on YouTube were quite easy, actually. I'd guess it's partially due to the tendency of using solid (or 2x2 checkered) blocks a lot, which compresses really well in H.264.
I have a few captures here: ftp://retronn.de/videos/
Especially in subfolder /DVI_Capture are newer ones.
FLT Uncovering Static has a few scenes that compress badly.
Especially in subfolder /DVI_Capture are newer ones.
FLT Uncovering Static has a few scenes that compress badly.
Quote:
capture is here, let me know which one you need re-encoded to continue in your research...basically any Satori demo
Anyone played much with h.26x Constant Quality modes, seen how much the bitrate jumps up? Maybe it'd be good to archive at CQ and transcode/stream at whatever bandwidth is available...
zden: I think your captures are good already, no re-encodes needed. Monstra Kosa is my canonical streamkiller, but at 640x480 (I think that's the demo's only resolution, right?) it's not challenging enough for 720p. Metamorf II looks like a good candidate, and the capture is great.
Sesse: I see, perfect... I think you asked me for MK.raw.video in the past and I failed to deliver (yes 640x480 only), so maybe MK-II in 1080p one day :)
On this note, Kvasigen - Textmode in a Bottle still needs a quality capture. Any takers?
Most surprising result so far: The motion blur scene of Nexus 8 causes the encoder's CPU usage to go up quite significantly.
Apart from that, the conclusion is that dynamic quality changing is sorely needed. Unless you've got a really fast machine (say, 16 cores), there's just no single x264 setting that will both give you a good stream for typical content and avoid dropping frames when the really hard content comes.
Apart from that, the conclusion is that dynamic quality changing is sorely needed. Unless you've got a really fast machine (say, 16 cores), there's just no single x264 setting that will both give you a good stream for typical content and avoid dropping frames when the really hard content comes.
Darn it, I had a few but it's on my video machine which is not available right now.
http://www.pouet.net/prod.php?which=30272 This was something I used quite a lot since it has big moving parts that alternate between frames.
Generally demos are a HUGE killer for streams and I tend to use a minimum of 4-5Mbit for client-side when going with 720p60.
Preferably you might even want to drop the resolution in some cases to gain a more stable picture with 75% downscaling.
Something you should also take in to account especially with low-resolution/older content is that you scale it properly and take chroma subsampling in to account. If the pixels are offset then it will further halve color resolution from what you already might have on a video or input from a capture card as cards generally do 4:2:2 at most unless it's an expensive one.
Poor scaling is usually a big issue when streaming older systems, a simpler 50fps amiga prod might actually look relatively worse than something complex and cinematic.
So say.. you have 320x240 content, you will want to upscale/pixeldouble it to your 1280x720 viewport properly and avoid odd scaling multipliers.
What end goals and specs are you generally going for? Streaming programs and the encoder/compositor can alternate performance outcome a ton.
1080p60 is heavy as fuck but if you keep scenes simple then it will generally work with a powerful CPU.
If you want to simply stream from point to point and you have bandwidth to spare then you can just drop a bunch of the compression optimizations which eat a ton of CPU.
Also remember that colorspace conversions can eat quite a bit of performance too with some programs.
For general use when streaming directly to viewers, I wouldn't go beyond 720p60. 1080p60 is heavy and requires a decent connection for smooth playback.
Even if the source is 1080p, it will generally look nice enough when downscaled to 720p.
One nastier workaround I've heard being used is to apply some slight de-noise and such on the source to reduce the unique pixels a tiny bit, makes sense as I assume you can remove a lot of stuff that compresses poorly but is invisible to the human eye. I wouldn't use this on modern stuff but I can imagine something like say ... C64 stuff with less signal noise compressing better. This would naturally have to happen at some point in the chain, potentially increasing CPU use unless you can just pass stuff through a GPU shader or something.
http://www.pouet.net/prod.php?which=30272 This was something I used quite a lot since it has big moving parts that alternate between frames.
Generally demos are a HUGE killer for streams and I tend to use a minimum of 4-5Mbit for client-side when going with 720p60.
Preferably you might even want to drop the resolution in some cases to gain a more stable picture with 75% downscaling.
Something you should also take in to account especially with low-resolution/older content is that you scale it properly and take chroma subsampling in to account. If the pixels are offset then it will further halve color resolution from what you already might have on a video or input from a capture card as cards generally do 4:2:2 at most unless it's an expensive one.
Poor scaling is usually a big issue when streaming older systems, a simpler 50fps amiga prod might actually look relatively worse than something complex and cinematic.
So say.. you have 320x240 content, you will want to upscale/pixeldouble it to your 1280x720 viewport properly and avoid odd scaling multipliers.
What end goals and specs are you generally going for? Streaming programs and the encoder/compositor can alternate performance outcome a ton.
1080p60 is heavy as fuck but if you keep scenes simple then it will generally work with a powerful CPU.
If you want to simply stream from point to point and you have bandwidth to spare then you can just drop a bunch of the compression optimizations which eat a ton of CPU.
Also remember that colorspace conversions can eat quite a bit of performance too with some programs.
For general use when streaming directly to viewers, I wouldn't go beyond 720p60. 1080p60 is heavy and requires a decent connection for smooth playback.
Even if the source is 1080p, it will generally look nice enough when downscaled to 720p.
One nastier workaround I've heard being used is to apply some slight de-noise and such on the source to reduce the unique pixels a tiny bit, makes sense as I assume you can remove a lot of stuff that compresses poorly but is invisible to the human eye. I wouldn't use this on modern stuff but I can imagine something like say ... C64 stuff with less signal noise compressing better. This would naturally have to happen at some point in the chain, potentially increasing CPU use unless you can just pass stuff through a GPU shader or something.
It will be 720p60; I run 4.5 Mbit/sec + audio. Normally I would use 6 Mbit/sec for 720p60 (broadcast TV is usually 12–15), but there just isn't the bandwidth available from the hall to the reflector.
The entire projector chain is 1080p (oldschool content is upscaled through a Framemeister), so there will be downscaling. Downscaling, colorspace conversion, mixing and similar things are handled on the GPU, which leaves a bit over 3.5 cores for x264 to chug on.
I agree that with this amount of bandwidth and CPU power, you want 720p60 rather than 1080p60. If I had twice the cores and bandwidth, I'd do 1080p, but with 720p as a medium-quality option. I think dropping down to 540p is maybe on the conservative side, though; at least with a fast quadcore, 4.5 Mbit/sec isn't typically so bad.
The entire projector chain is 1080p (oldschool content is upscaled through a Framemeister), so there will be downscaling. Downscaling, colorspace conversion, mixing and similar things are handled on the GPU, which leaves a bit over 3.5 cores for x264 to chug on.
I agree that with this amount of bandwidth and CPU power, you want 720p60 rather than 1080p60. If I had twice the cores and bandwidth, I'd do 1080p, but with 720p as a medium-quality option. I think dropping down to 540p is maybe on the conservative side, though; at least with a fast quadcore, 4.5 Mbit/sec isn't typically so bad.
Quote:
On this note, Kvasigen - Textmode in a Bottle still needs a quality capture. Any takers?
Not so sure about that :)
jmph: It has an “get AVI” button… :-P
oasiz: Do you have a good capture of STS-01? The one linked from the prod is a pretty low-bitrate in letterboxes 800x600.
I'm also still missing good captures of Michigan and Through the Cracks. But I'm getting fairly confident that it's possible to get x264 speedcontrol into a shape where I can use it.
I'm also still missing good captures of Michigan and Through the Cracks. But I'm getting fairly confident that it's possible to get x264 speedcontrol into a shape where I can use it.