The video's dimensions must not exceed 800x600. This is so video files keep a decent filesize and do not increase the beatmap's size by too much.

Explaining better.

The rule cover up only a single aspect ratio: the 4:3 (means that width/height proportion is 4:3, and is used by old CRT TVs and older monitor ), and the max resolution is 800X600.
Differently, new PCs and TVs have another aspect ratio, 16:9 to be more similiar to cinema's widescreen, and the resolution limit of those type of videos was 854X480 as an "agreement" within the community.

And still the rules didn't cover the usable formats ("container" more correctly) and the fact they shouldn't have the audio on.

1. Video's dimensions must not exceed 800x600(4:3) or 854X480(16:9). This is so video files keep a decent filesize and do not increase the beatmap's size by too much.
   
2. The extension of the video should be "avi" or "flv" and it shouldn't have an Audio Track, as the beatmap audio arleady provide that, so the video load on the Computer is decreased.

Oh... I mean you're talkin' about the size in Megabytes... sorry.

Explained better now >.<.
Guess not all know about video formats, resolution and so...

IMO:
Max resolution: 800x600, 800x450 for 16:9 widescreen (widescreen is implied rule, no need to mention it).
Video should not have an audio track.
Always keep aspect ratio constant, don't stretch it.
Osu! only accepts avi and flv containers. Do not change the extension to force osu to read it (yes people have done this, and afaik libavcodec will read a lot of containers, just not very well since I think it's an old version or a very specified version that somehow passes the LGPL).
Maximum video size is the max beatmap size with video (no need to mention this), but try to keep it around 10 MB max. (10 MB limit can be a recommendation, since longer videos might use the whole 24 MB beatmap size)


Reasoning:
video size is not affected much by resolution. In fact, the larger the resolution, the better the image quality so long as you're not downsampling by playing the video at a lower resolution. Limiting it to 800 vertical lines and 600 horizontal lines makes the rule simple and easy to follow, and lets you almost always resample from a larger source. 848x480 is not a true 16:9 resolution and IMO should be avoided, but an argument could be made either way. What if I wanted to make an 848x636 video with black bars making it 16:9 to offset the video properly so it would display in taiko? It would be a special case, and would certainly be accepted, but would be yet another exception to the rule. Keep it simple folks. 48 more lines is negligible.

Osu does not support widescreen well, so 16:9 should be the smallest aspect ratio (no 2.32:1) but we haven't had a problem with this so there's no reason to mention it now. If osu supported widescreen, I might support a larger resolution for widescreen, but that's a big "might".

Aspect ratio is a big problem in TVs now and is somehow ignored by many people (I can't stand it). I've found most people prefer to keep aspect ratio, and those who stretch the aspect ratio don't actually care either way.

there are many (like 20) aspect ratios, but the most used are still 16:9 and 4:3. I don't remember the cinema's one...

Anyway, the 480p (854x480) is much like a standard used within many fansubs and should be more famous than 800x450, as so I think it's better to say it...

Anyway, resolution do affect video size depending on bitrate, the difference between a 2Mbps 720p and 480p is larger than the difference between an 0,5 Mbps 720p and 480p and so.

The suggested codecs should be:
-.avi : Xvid(Larger filesize, less quality, less impact on performance), x264 (h264/avc)(smaller filesize, higher quality, small impact on performance), sony h264/avc (if you have vegas) (same as x264)
-.flv : was called FLV8? (smaller filesize, lower quality, less impact?) and FLV9 ( yet better call it x264(video)/AAC(audio) ) (same as x264)

but that's pretty much not needed.

Anyway, why they didn't update the draft when people on the MAT/BAT discussion ended talking about it?

ziin wrote:

What if I wanted to make an 848x636 video with black bars making it 16:9 to offset the video properly so it would display in taiko?

also, no reason to suggest any codecs. xvid and h.264 are givens, and h.264 is the only one I'll ever use.

Maximum pixelcount: 480,000. Don't use an aspect ratio wider than 16x9 or taller than 4x3.
Bitrate: Let's discuss.

I have 3 ideas:
we set one max bitrate a la the 192 kbps rule for the same reasons (keep filesize down). 1 Mbps is more than enough for anyone.
we set two max bitrates for h.263 and h.264, with h.263 being higher than h.264.
we set no max bitrate and let the max beatmap size do its job.

the Beatmap filesize limit arleady limit the bitrate, so it's not worth setting a bitrate limit

(just like ziin said)

I agree with leaving the max size to limit the bitrate.

too with low bitrates stressing the graphic card too be seen decently

What about the calibrate from .mpg or .avi? must be mpg or avi?

osu support only avi and flv contaners as now (as far I know, not mpg).
Say it's preferible you use x264 as codec and a bitrate from 0,4 to 1.6 Mbps
Anyway how about a song-lenght dependant size?
a bit higher limit in size for full sizes songs will be better (like "28 or 32 Mb"). A full size sog video bitrate is max 550 Kbps at like 18 Mb of weight, and it produce some artifacts that are deletable with like 700-900 Kbps of decoding.

The size is still contained, while the video quality is good. How's that?

So something like this?

HakuNoKaemi wrote:

osu support only avi and flv contaners as now (as far I know, not mpg).

Go to "Songs" and search for this formats.

".avi .mpg .flv .wmv"

And watch out the results.

Just fyi, osu will play .mp4 on mine as well, but only if you change the extension.

Can someone with a bad computer volunteer for a test? I'd like to see what effect (if any) different codecs and containers have.

Or maybe I'll just underclock my computer significantly...

1024x576(16:9)is unrankable?

Ibuki Suika wrote:

1024x576(16:9)is unrankable?

as mm201 said, max of 480,000 pixels, yours is 589,824 so yeah, unrankable.

Sakura Hana wrote:

Ibuki Suika wrote:

1024x576(16:9)is unrankable?

as mm201 said, max of 480,000 pixels, yours is 589,824 so yeah, unrankable.

http://osu.ppy.sh/s/37749

I think use the 1024x576 size can controlled the quality&file siezin a good range(for tvsize map

ziin wrote:

Just fyi, osu will play .mp4 on mine as well, but only if you change the extension.

Can someone with a bad computer volunteer for a test? I'd like to see what effect (if any) different codecs and containers have.

Or maybe I'll just underclock my computer significantly...

Fwiw, my 2006 rig lags pretty bad on h.264 videos. I think this has more to do with it being single-core than any processing requirement, since the videos play fine on their own. Disabling additional cores should be the first thing you do to benchmark low-spec performance.
You could also provide me with a bunch of maps and I'll test them.

Yeah, pretty much h.264 have as a requirement a "multi-core" like Win Vista and 7

I'll admit, i'm running on a single-core Pentium M right now (with no videocard on this thing). Some of the newer maps with video actually lags me to death compared to the old ones (even in .flv format). Not sure what's up with the compression or type of formatting used, but it could be trouble for those with low-end specs if not set correctly.

My biggest problem with videos is that some people use some unbearably low quality videos (xvid codec did this for me, if I didn't increase the filesize a fair bit). If the quality is that bad, I rather turn off the video than play with that awful thing.

Since I do enjoy high quality videos, I want to make sure h.264 is allowed. (Simplest solution to get decent quality videos with moderate file size imo)

Well, i'm sure there's a way to get nice quality videos that balances it's beauty and performance without going overkill trying to get it within "HD" specs.

Probably the easiest way to solve this is find a solution that fits the necessary criteria and not a postulate. I think everyone in the thread will be happy if that is done(anyone want to suggest a solution)

a moderate file size isn't possible to get with decent quality and load.
May I make you remember why the "Antialiasing" was created ?
Yeah, antialiasing correct the problem of not using extragreat filesizes, and make the RAM load lesser by Overkilling the CPU and the Video Card:
-One method render an enlargered model by 2, 3, 4 or more times and the make it return to a smaller size for better approximation
-Another method, rendered the object more time to get a better image quality...

You can't get a decent quality with a small filesizes without overkilling your (low-end) pc...
But still, i didn't know so many BATs had a Low-end (really) PC, as the x264 do simply need a Dual Core with about 1.2-1.6 GHz of CPU (2.4-3.2)

And btw, even a smartphone have those specs as now

HakuNoKaemi wrote:

And btw, even a smartphone have those specs as now

In other news, Qualcomm is trying to push for H.265, even more efficient and lag inducing codec.... meant to give a reason to upgrade your phone....
http://reviews.cnet.com/8301-13970_7-57 ... 265-video/

I wonder how this will do in osu! when we start encoding with it... at least file size will be 40-45% smaller or that much higher quality.

hevc won't be supported by osu for a while, if ever. Osu uses libavcodec, which is an AVC decoder (among other things). I find it unlikely that libavcodec will support the new codec at release, or even within a year from release.

Not to mention, a properly configured xvid is fine for osu's needs.

If it weren't for bandwidth and file storage concerns, we would be using mpg2.

blissfulyoshi wrote:

HakuNoKaemi wrote:

And btw, even a smartphone have those specs as now

In other news, Qualcomm is trying to push for H.265, even more efficient and lag inducing codec.... meant to give a reason to upgrade your phone....
http://reviews.cnet.com/8301-13970_7-57 ... 265-video/

I wonder how this will do in osu! when we start encoding with it... at least file size will be 40-45% smaller or that much higher quality.

Thank for the good news u.u.
What I see is the same quality with 44-48% less bitrate...
Anyway, most smartphones as now do have at least an 1.2 Ghz Dual Core (or even a 1.6 Ghz Quad Core) and phones do need smaller resolution anyway ( higher resolution -> much more quality, bit larger filesize and much higher specs requirement ), (as they can't you usually can't see ultralittle pixels... )