38 個の投稿 / 0 new
最終投稿
#1 2016-02-24 08:50

[English] Basic guide to preparing videos for upload

This guide assumes the reader already knows how to use MMD software and has three purposes:

  • To show new encoders/uploaders how to prepare a video so it streams correctly.
  • To show any beginner encoder the path to higher picture quality
  • To show how to encode a video with a reasonable file size/quality ratio.

I will be showing how to make use of Handbrake. Download the latest version from here.

Step 1: When you are satisfied with your video and are ready to render
Choose your resolution by going to View -> screen size. Suggested is 1920x1080.
Determine how many frames the video requires to reach the complete ending. Then go to file -> render to AVI, choose a name and click save.
Please note that any fps or resolution values will work just fine. Increasing/decreasing the FPS or resolution will also change the file sizes of both the raw video and the end result.
Standard values for fps: 24, 30, or 60. For this guide, we will choose 30.
Standard values for resolution: 1280x720 or 1920x1080. An alternate resolution can be chosen, such as 1024×576, 1152×648, 1366×768, or 1600×900. If your final video result is too large in file size, then consider dropping down to the next resolution.
Consider choosing AVI Raw as video compressor. This will require considerable disk space, but generally results in a higher quality end result.

Step 2: Open Handbrake and click on the Source button near the top-left corner. Navigate to and load your newly rendered video.
Choose your output destination.
Under Output Settings, make sure Container is set to MP4 and check the box for Web Optimized.

Step 3: Navigate to the Video tab and apply settings.
Choose Constant Quality, and set the CRF value. This value has a direct influence on both quality and file size. READ MORE HERE
For this guide, we will use a value of 16, but up to 23 can be used for decent quality. This has a direct effect on the final file size and quality.
Check the box for Use Advanced Tab Instead.
For smaller file sizes, select Avg Bitrate and enable 2-pass. 720p bitrate should be around 2500-3000, and 1080p should be around 3500-4000.

Step 4: Navigate to the Audio tab and apply settings.
Change codec to AAC (avcodec).
Change Mixdown to Stereo.
Choose a Bitrate. I suggest 128 or 160. This affects both the audio quality and the final size of the file.

Step 5: Navigate to the Advanced tab and apply settings.
Use the image to get a baseline to start with on changing these values. Please understand that encoding is a highly complex subject, and no two videos have the same settings for best results. Even for this example, these settings were not tested and/or changed to search for best results. Doing so is a process that can take days to find the absolute best settings, and may only end up being marginally better than what these settings already provide.
In the text box at the bottom of the tab, make sure to change the level to 4.2 by clicking in the box and adjusting manually.
(OPTIONAL) In my screenshot, you will see that I added a "threads=1:" to the start of my settings. This tells the encoder to use only one CPU core for this task. Why do that? Because it results in a very slight increase in quality at the expense of time.
If you want to play with these values, I HIGHLY suggest taking the time to research and find out what they actually do. This is a good place to start.

Step 6: When satisfied with current settings, click the Start button to begin encoding.
This process may take a long time, depending on your CPU. Please understand that proper encoding requires time. Trying to make it go fast results in lower quality.
When the process is complete, review your video to check the picture quality. When satisfied, you are ready to upload.

Final Notes

  • Final file size will vary. Adding more effects and shaders will result in increased file sizes.
  • While we do allow files up to 300MB in size, it still remains true that the larger the video, the more taxing it is on our servers. Please do not try and make every video as close to the limit as possible. Preferred sizes are below 200MB.
  • If you insist on having huge files, please consider posting lower quality versions for streaming, with links to download from an external file host.
  • If preparing video for download instead of streaming, consider changing the level to 5.2 instead of 4.2 for a slight increase in quality.

FAQ
To be added

2016-03-13 08:17

Reserved For potential translation.

2016-03-17 22:51

Great guide. This is very close to what I've been doing with my videos.

2016-05-11 15:24

1080p videos require 2.25 times as high of a bitrate as 720p videos do to look equally good, because the number of pixels increases exponentially, not linearly, as the height of the video increases (because the width increases as well). If you get a 720p video look decent while being under 70MB, that same video has to be roughly 160MB in 1080p to look decent.

Which is why I recommend just sticking with 720p (or even lower than that sometimes) videos when you need to make your video look good while working with a very restricted size limit. You can hardly tell the difference in resolution anyway unless your monitor is like a 40" TV or something, but you can totally tell the difference in encoding quality.

2016-05-11 21:08

I agree, 720p is the way to go.
As far as bitrate requirements, it's not always what it seems. I set some guidelines, but they don't have to be followed as a hard requirement. Those values are what I've found to work very well for my tests, and nothing more. What is really going to determine the bitrate requirement will be the amounts of motion and effects.

For 720p, sometimes I was able to use 2000 bitrate and it still looked crisp, for a file that ends up less than 50MB.

2016-06-20 15:11

AFAIK most of the time , motion speed & scene complexity of the media take great part of the compression vs quality. let's take the example to the extreme for easy explanation. comparing a fast camera motion with high complexity movie against slow camera motion with low complexity movie. the former will always need more bit rate compared to the latter to keep on par with the quality. a fair case would be the file size of action packed movie and drama movie.
given that most of the clip i saw here have Master Yoda like camera motions , force compressing them to lower bit rate will greatly reduce the quality. though i'm aware that most modern music clips tends to have fast camera movements , a constant fast motion camera has less desirable outcome for a motion picture. one from the file size and quality, others are the impact on the story itself, well at least on cinematic theory wise :D

for a detailed action packed 720p motion pictures i'd say 7500 is more than enough with correct command line encoding script. cheers :)

2016-06-20 16:41

I feel like you get to pick any two of the following in order to get a ~3 min video under 300mb:

a) High quality compression
b) 1080p
c) 60fps

Frankly, of those, I find that 60fps makes the least visual difference. If you're animating high-speed action sequences, 60fps might be important (probably not, great wuxia movies are still filmed at <30fps), but there's absolutely no reason to use crappy compression and 60 fps, you're going to lose that action anyways. (Likewise, there's really no reason to use 1080p and crappy compression, you might as well use 720 with good quality, you're going to end up with a better picture.)

If you're trying to make longer videos, or you've got bandwidth issues, then maybe you'd have to drop two of those.

2016-06-20 19:18

imo fps is not highly affecting for compression. a 60 fps drama can still get very low size because it can still use low ref frame and high GoP to get higher quality. a 30 fps action packed also can get smooth movement with correct effect [motion blur]
for cinema standard it's 24fps iirc . not noticeable on cinema and crt [using interlace] but it will be on lcd pc :) . and yes i do agree that most case here are crappy compression. [that's why i love previous version of the site more with low res version to view before deciding to download .. or not :) but this is just my own issue]

2016-06-20 20:16

Whether the monitor's LCD or not doesn't matter at all. LCD is showing you 60hz regardless of the video. If you've overclocked your monitor, it'll still show you 120hz regardless of the frame rate of the input. Those demos at www.blurbusters.com don't depend at all on the framerate of a recording, they're issues that arise solely from your LCD refresh rate.

If you're not seeing significant changes in size with framerate changes, it's probably because you're not adjusting the bitrate. Image quality, framerate, and bitrate all go hand-in-hand. If you increase the framerate without increasing the bit-rate, you'll get the same size of video, but with lower image quality.

Unfortunately, nothing is free. Doubling the framerate without impacting image quality is almost as expensive as moving from 720p to 1080p. In both of these situations, of course, the exact cost is going to depend on your compression and the nature of your video.

Frame rate is a lot more important for games than it is for rendered video. There are a couple of reasons for that. The biggest is latency. If you're getting 30fps, that's at least 17ms of extra latency over 60fps. Usually it's more because of frame buffering, when a lot of games triple buffer and driver coders are prone to trying to improve brute framerate at the cost of latency since framerate's the easier number to put in a hardware review. And a lot of games have poor main flow that leads to additional problems with latency. By the time you've added in input latency, you can easily be looking at 50-100ms of latency, even before you add in network latency. That's a lot of latency. Shaving off 17ms is important, even assuming you're not looking at 3x that from buffering.

I'm not saying that 60fps doesn't matter. People can learn to see it (mostly, they don't at first). But everybody can see 720p->1080p, and if you can't, it's most likely because your monitor isn't big enough, not because of the video or your eyes. There are a large number of details that only become apparent at higher resolutions. (Of course, with the frequently cartoony style of MMD, those kind of details aren't always present. Still, try out something like Alternative Full .fx at both resolutions, and you'll see what I'm talking about.)

But I don't mean to speak for everyone, just myself. I encourage everybody to record their videos at the settings that they themselves find most beautiful.

2016-06-20 23:29

Again, I will just mention that my values provided in the guide are based off my own tests. This does not mean they are absolute. There WILL be cases where my suggested bitrates are simply not enough.
The main point is the fact that we get so many BLOATED files with bitrates 2 or 3 times higher than they need to be.

(Conversions and multiple qualities will be making a comeback, but it will take a long time)

2016-06-21 01:49

Sorry, guilty. In fact, I'd have to rescind what I wrote-- you can have it all.

What I don't like is that I have to use one program to join my three or four avi's, another program to attach the .wav, and then a third program to get good compression, each time checking the video to make sure that the programs didn't do anything awful to the video. Creating a video ends up taking an hour, with me having to check the computer every five minutes. I'd probably be less lazy about bitrate if Handbrake could join, attach audio, and compress all in one go. Have any good workflow advice?

2016-06-21 01:55

Well.. sorry but no - not for your workflow there. All I do is render and then compress. I don't make anything that would need multiple avi files and then combine a music file afterwards.

But Handbrake is not the only option either. Some more advanced programs are capable of doing everything you mentioned. But I do not know of any that are (legally) free. Any decent program will allow you to adjust all the same or even more settings than what handbrake allows.

2016-06-21 04:33
2016-06-22 12:55

ffmpeg is free and super good for any simple stuff like joining avis, attaching audio and encoding. It's versatile, fast and reliable.

Usually I just render the avis from MMD losslessly (using the Lagarith codec) and join and post-process them and add music in After Effects. Then I do the final encode with Media Encoder because I'm lazy, even though it's not quite as good as ffmpeg for encoding. Obviously this is not of much use to you if you don't have After Effects and don't want to get it.

2016-06-23 03:01

Thanks Pr0n. I appreciate the help. I'm playing around with some of the suggestions in the rendering thread, hopeful about the lossless codec possibility that might make the whole issue moot.

2016-06-23 03:22

You're welcome. The only downside to using AviUtl is that it does not support 60 FPS movies. but 30 FPS is better for streaming sites like this one anyways.

2016-08-15 08:03

I ended up getting consistently good results running 32 bit MMD with Lagarith compression. No problems with it cutting out, no apparent loss of quality, and Handbrake is recompressing in a fraction of the time it took to handle raw avi. One of these days, I'll do a speed test on 32bit vs 64 bit, might make sense to animate and prepare in one version and render in the other.

2016-10-21 22:08

crf

2016-12-07 01:13

I simply parasited on YouTube's video processing:
1. In MMD, render as 1080x1920 30 fps.
2. Open the resulting AVI file with Windows Live Movie Maker 2012.
3. Upload the video from inside Windows Live Movie Maker 2012 to YouTube, as a private 1080p video.
4. Wait for YouTube's video processing to be completed, so other resolutions than 360p will exist.
5. Download your own private YouTube video with a video grabber, (just like anyone would download someone else's public YouTube video). The video grabber will find about a dozen versions of your private upload. Select the 1080p mp4 version for download.
6. Upload your YouTube download to Iwara.
7. Delete your private video from YouTube.

Uploads from inside Windows Live Movie Maker 2012 will result in 192 kbit/s AAC 44.1 kHz audio at YouTube. Direct uploads from a folder on your HD will result in mere 126 kbit/s AAC 44.1 kHz audio at YouTube. YouTube will toss out direct uploads of multi-gigabyte AVI files: "processing aborted". Windows Live Movie Maker 2012 can open huge size AVI files without any problems.

The free version of Windows Live Movie Maker 2012 tops at 1080p30fps on the upload side, even though it opens 1440p60fps AVI files without problems, (so you need to pay real money to Microsoft for a better version if you want 60fps uploads).

Typical file sizes: 1. Movie Maker opens your 4 GB AVI file. 2. Movie Maker uploads a 700 MB mp4 file to YouTube. 3. You download a 200 MB mp4 file from YouTube, and upload it to Iwara.

2016-12-07 18:32
Quote:
I simply parasited on YouTube's video processing:
1. In MMD, render as 1080x1920 30 fps.
2. Open the resulting AVI file with Windows Live Movie Maker 2012.
3. Upload the video from inside Windows Live Movie Maker 2012 to YouTube, as a private 1080p video.
4. Wait for YouTube's video processing to be completed, so other resolutions than 360p will exist.
5. Download your own private YouTube video with a video grabber, (just like anyone would download someone else's public YouTube video). The video grabber will find about a dozen versions of your private upload. Select the 1080p mp4 version for download.
6. Upload your YouTube download to Iwara.
7. Delete your private video from YouTube.

Uploads from inside Windows Live Movie Maker 2012 will result in 192 kbit/s AAC 44.1 kHz audio at YouTube. Direct uploads from a folder on your HD will result in mere 126 kbit/s AAC 44.1 kHz audio at YouTube. YouTube will toss out direct uploads of multi-gigabyte AVI files: "processing aborted". Windows Live Movie Maker 2012 can open huge size AVI files without any problems.

The free version of Windows Live Movie Maker 2012 tops at 1080p30fps on the upload side, even though it opens 1440p60fps AVI files without problems, (so you need to pay real money to Microsoft for a better version if you want 60fps uploads).

Typical file sizes: 1. Movie Maker opens your 4 GB AVI file. 2. Movie Maker uploads a 700 MB mp4 file to YouTube. 3. You download a 200 MB mp4 file from YouTube, and upload it to Iwara.

Sorry to be blunt, but this is awful. You lose a lot of quality if you use Movie Maker for anything. Just use ffmpeg for re-encoding if you have to.

2016-12-07 19:34

colossal resource waste

2017-03-17 17:31

wow ty so much to all ^_^

2017-03-18 14:00

AVCx264 is better and much smaller compression than Hx265 :3 i am useing the freeware "AVIdemux" to save my files for mp4, in that program you can turn a 2 gb file into 300 mb allmost without loss of quality ;D

the way Admin introduce file compression was for beginners, its fine :)

2017-03-18 14:06

This isn't a guide to get the best possible compression. It's meant for preparing files for the best streaming compatibility I was aware of upon writing it.
I'm not even sure if AVCx254 is streamable in most browsers or not. But regardless, uploading something in that format will trigger our encoder to re-process it again anyway.

2017-03-18 15:09

AVCx264 is fine for mp4 and firefox with any kind of flashplayer. i belive its just the new version to H.265. since my windows movie maker use H.265 and its kind of old program and create giant waste files of gigabyte dimensions, and if you make a small H.265 file it will have a low bitrate :I

2017-03-18 16:38
Quote:
AVCx264 is fine for mp4 and firefox with any kind of flashplayer. i belive its just the new version to H.265. since my windows movie maker use H.265 and its kind of old program and create giant waste files of gigabyte dimensions, and if you make a small H.265 file it will have a low bitrate :I

Let me clarify a couple of things here.

First of all, bitrate just literally means how large the file will be relative to its duration, i.e. how many kilobits it takes per second. If you make a small any file, it will have a low bitrate by definition.

x264 is a free library for encoding into H.264; H.264 is also known as AVC. H.264 and H.265 are video compression standards — H.265 is newer and better. However, precisely because it is newer, tools for encoding into it have not been in development for as long, and thusly, aren't as good. Still, with x265 (you might be able to guess that it's a free library for encoding into H.265, and you would be correct) and correctly configured encoding settings, you can already get very slightly better results than x264 at high bitrates and very much better results than x264 at low bitrates. Here's a bunch of comparisons from 2016 if you're interested: http://wp.xin.at/archives/3465/comment-page-1 (as the writer points out though, x265 takes a lot longer to encode and older hardware might not be compatible with H.265 video, so it's not as straightforward as concluding that x265 is just better)

However, Windows Movie Maker's encoding tool is nowhere near as good as x265, let alone x264, and it doesn't really even allow for any kind of customization. Hence, you will get shit quality at high bitrates if you use WMM, so don't use it. But that doesn't mean H.265 is bad, it just means WMM is bad.

2017-03-18 16:55

thank you for the insight. thats again me, speaking of trial and error experiences i have made without knowing actual facts :I

2017-03-18 21:13

I have been using XMedia Recode, which is a free program and it works pretty well. I will try Handbrake also to see how it compares.

2017-09-21 17:32

Is there no support for 4k? when i try to upload in 4k 60 fps I just get a error message.

2017-09-22 00:14

#29 for now maximum resolution is HD1080p . 4K UHD currently not supported

~旦_(^O^ )

2017-11-10 22:04

So given that we're on new servers, are there any changes to the optimal settings for compression? I've noticed that nowadays videos take upwards of an hour or even two after they are listed on the videos list before the servers actually finish processing them. I was wondering if there was anything I could do on my end while compressing to help shorten that.

ページ