So... I'm moving to x264...

[DryFire]

Originally Posted by Potatochobit

No, they are not all just straight forward installs, one of the programs installed the old vobsub and overwrote CCCP. subtitles stopped displaying and I had to reinstall it. also one of the programs, not sure which, installed VdubMod as default and that caused problems for the mpeg2 version.

You don't need to install vobsub again if want to use textsub in avisynth, just drop a copy of the dll into your avisynth autoloading folder or load it via loadplugin().

[Nicholi]

Well in the area we are talking about, GUIs specifically for a CLI application...if you have used one you have used them all. They all work pretty much the same way, "show me path to CLI". Done. No need to install anything really. And most GUIs are usually just in a compressed archive, so no installation to be done. Otherwise you can always extract the files from the installer, without installing anything.

[SirCanealot]

H.264 is batty.......

I'm gonna get a Core 2 duo in the next month or two... then it will be less batty......

[Fatsobob]

I dabbel in x264 encoding.....Private Trackers mostly right now. It takes me FOREVER to encode, so I know I couldn't be a group encoder. An hour and a half movie takes 1 hour for 1 pass and something like 10-12 hours for the second. I guess thats what I get for having an old athlon 64 3200+ to encode on.

[Nicholi]

Sounds more like whack "warez scene" recommended settings to me. 1st pass speed should be mostly identical to 2nd pass, or you have basically botched your stats file. You aren't doing something like this are you?

 Pass 1:
 x264.exe --pass 1 --bitrate x --threads auto --thread-input --bframes 3 --me dia --ref 1 --subme 1 --no-dct-decimate --partitions none --progress --no-psnr --no-ssim --output NUL
 
 Pass 2:
 x264.exe --pass 2 --bitrate x --threads auto --bframes 3 --b-pyramid --bime --weightb --b-rdo --me umh --ref 5 --mixed-refs --subme 7 --trellis 1 --8x8dct --no-fast-pskip --progress --no-psnr --no-ssim --output x.mkv

Recommended settings from our almighty warez encoder brethren. Truly their intelligence knows no bounds.

[checkers]

Actually nicholi, encode a few test clips with a full or 'turbo' single pass stats file and revel in the rather small difference. Options like # bframes, scenecut, etc that affect frame type decisions should be kept the same, the others are reasonable resiliant.

[Nicholi]

I'll choose my long wait time over scene speed any day .

Anyways if we go about reveling in differences, I always keep hearing pengvado say how 1pass in x264 roxors boxors. Why even bother with 2 if we are going to be speed whores n_n.

[Starks]

*self-deleted*

[peter the llama]

Originally Posted by Starks

I may not be the best encoder out there, but I know when its time to embrace the future.

I want to dump Xvid (and possibly VirtualDubMod) and learn how to use x264 and MeGUI.

Good call: H.264 compresses anime MUCH better than MPEG4 ASP (xvid) can. The in-loop deblocking filter and multiple reference frames esp. are very effective on animated content. With no film grain and lots of solid colour areas, you can often get away with very low bitrates.

So, what kinds of barebone settings should I be running in MeGUI for anime?

Lots of reference frames helps more on anime than in live action. If a character walks in front of something, it will usually look _exactly_ the same half a second later when it's revealed again, and in some animated content you have repetitive mouth or other movements. 1/2 second = ~12 frames.

Also, what filesize should I aim for if I have 1024x576 raw?

Would someone please tell me why everyone always scales video before encoding, instead of keeping it anamorphic and letting the player scale it on playback? What kind of player imposes this stupid requirement, and why not just let people with some bogus hardware transcode or something.

Maybe some hardware players suck and couldn't read an aspect ratio from an AVI (maybe only mplayer does that), but Matroska supports aspect ratio info in a standard way, so any MKV player should handle non-square pixels. H.264 itself includes a PAR (pixel aspect ratio) in the bitstream, with no container support required. I _HATE_ all the low quality rips out there that lose vertical resolution by scaling to 1:1 pixels at 640x272 or something. 1024x576 at least doesn't lose resolution, but upscaling makes the codec use more bits to encode the same actual information. Always minimize the amount of transformations you put your video through.

Actually, I don't know about the MP4 container, and I've heard that e.g. apple tv doesn't support h.264 PAR != 1:1. Is that why people still aren't making anamorphic rips? A comment in http://www.linuxjournal.com/article/9005 says that MP4 can have an aspect ratio set for the whole picture, and if quicktime doesn't show it right you can manually set the display size.

As for filesize, it totally depends on the content. I usually aim for a quantizer of 18-20 with live action, because any higher and you start to notice artifacts if you watch SD content on a nice 22" widescreen monitor and sit close to the screen for full effect. I usually encode some of the source at crf=18, pass=1, to see what kind of bitrate that gives me. If I like it, I can do a pass=3 at a similar bitrate with the same settings (I use mencoder on GNU/Linux and write shell scripts to encode stuff, since none of the tools I've found can do a decent h.264 encode and get the audio in sync in a mkv... Don't know if megui is good about putting the passlog file somewhere you can use it to do just a second pass). So yeah, encode a 1 min clip at a few different quality levels (crf=18, crf=20, ...) and see what the bitrate vs. quality tradeoff looks like. It's not easy to pick a clip that's representative of what the whole movie will do, though, since dark scenes or lots of action make a huge difference to required bitrate. And stuff with more texture will only look good at lower QP.

That said, anime looks good at higher QP than live action. esp. simple shading, with blocks of solid colour. With higher QP on live action, you lose things like skin texture from a closeup of a face. If you don't have detailed textures or film grain, QP=25 still looks good. e.g. I'm currently transcoding some Family Guy episodes from 1000kbit xvid (576x432) to h.264. At QP=25, the only thing I've noticed so far are that some lines are slightly stair-stepped (probably encoded as just solid 8x8 or 4x4 blocks, without a lot of detail in the blocks). I'm hoping to fix that by giving I frames more bitrate, since the artifact is only noticeable because it stays on screen as a reference picture for so long. It's ok to have very minor artifacts in moving mouths, etc. Family Guy is a classic case of easy-to-compress animation. There are large blocks of solid colour, static backgrounds that just pan if they move at all, and long periods where the only part of the picture changing is someones mouth. At crf=25, season 4 ep. 01 compresses to 411kbit/s. That's with everything cranked, IIRC:
crf=25, subq=7, me=umh,
frameref=10, mixed_refs, direct_pred=auto, maybe even me_range=32 or something
bframes=5, b_pyramid, weight_b, brdo, bime,
8x8dct, partitions=all (i.e. include p4x4, which defaults to not included)
keyint=500 (fewer I frames: esp. good with static backgrounds)

trellis=2 is a waste of time. partitions=all, instead of the default (all but p4x4) is not always useful for live action, but I don't know about anime. It's recommended only at low rez, according the the mplayer man page.

I'd suggest as a base something like:
bframes=5, b_pyramid, weight_b,
me=umh, subq>=6, (major speed impact, but very important)
8x8dct, turbo=1 (only does anything when pass=1)
frameref >= 4, (major speed impact, but also fairly large quality gain)
everything else at defaults (dct_decimate, chroma_me, fast_pskip, direct_pred=spatial)

That's kind of a basic good quality setting. Higher quality would be
brdo, bime
me_range=32 (depending on the anime, if things move in steps > 16 pixels, then I think this will help. It can make it a lot slower, though.)
frameref=9-12
mixed_refs, maybe partitions=all
trellis=1, no_dct_decimate (only in 2pass. apparently trellis isn't a good idea with dct_decimate, or in crf mode.)
direct_pred=auto (usually goes 99% spatial on live action, maybe bigger impact on anime)
keyint=500 (trade off seek accuracy for fewer bits spent on I frames)

I sometimes use qcomp=0.7, to get more constant QP and less constant bitrate, since I don't like having any sections that look bad. This might not be sensible, since quantizer and quality aren't at all the same thing.

I also use nr=100 or nr=200 on sources with film grain, but it tends to lose fine texture detail. Probably not an issue with anime from PAL DVDs, unless it's a terrible MPEG encode like some of the copies of Castle of Cagliostro floating around...

BTW, 1000kbit/s is probably a good bitrate for DVD rez live action with settings cranked up. A lot of animated stuff will look fine at lower bitrate. Look at the SSIM and/or PSNR numbers, and see how that varies with bitrate/QP for the source you're encoding.

Hope this helps. BTW, the main reason I replied was to express my shock and horror at people upscaling before encoding. Please someone tell me why! Have people never seen e.g. http://handbrake.m0k.org/trac/wiki/AnamorphicGuide

[Starks]

I've never quite understood the use of anamorphic resolutions for anime... Shouldn't we be aiming for square pixels?

[Kaoru Chujo]

Originally Posted by Potatochobit

...kaoru, making a bad h264 video is kind of pointless. you will just have to be content with the xvid version ;0;

As long as there is an xvid version... Anyway, the Byousoku x264 encode I saw seemed really nice to me, so I don't think it was much dumbed down. Maybe it varies from raw to raw whether a good encode can be made with parameters that are playable on older machines.

Anyway, until I get a better machine I'll keep getting xvid -- and just trying the odd x264 in hopes they will work. On this little laptop, the upscaled xvid videos are even more of a problem.

[peter the llama]

Originally Posted by Starks

I've never quite understood the use of anamorphic resolutions for anime... Shouldn't we be aiming for square pixels?

No, you should be aiming to keep as much information as possible from the source, in as low a bitrate as possible. Upscaling dilutes the information from the source among more pixels. Downscaling obviously loses information. The scaling process itself is also lossy, since it can't be reversed exactly. (scaling up and down repeatedly would blur things).

I'm using "information" in the information-theory sense, as in Shannon information. If computer science isn't your cup of tea, the explanation works just as well if I said "detail" instead of "information".

Yes, square pixels are needed eventually to display correctly (assuming a display with square pixels[1]). The question is whether the upscaling happens before or after compressing with x264. If you do it before x264 has to compress more pixels. If you do it after (anamorphic), it's actually the player doing it. Also, then there's only one video scaling process, right from 720x576 to e.g. 1680x1050. Scaling is a lossy process, but that's negligible compared to the advantage of compressing only 7/10 the amount of pixels. (also think of the speed gain; it probably takes ~7/10 the time to compress compared to upscaling.)

[1] Computer monitors almost always have square pixels. Exceptions I can think of: With some vid cards, you can run a 720x480 vid mode displaying on a 4:3 NTSC TV. I have a widescreen LCD, and when you use the analog input is always stretches to full width. So a 1280x1024 vid mode stretched to a 16:10 screen means that image pixels aren't square. This is more relevant for games or other 3D thing, which is the only time you'd want to use a non-native resolution.

[TheFluff]

why are you talking so much about anamorphicness with regards to tv raws? maybe if we made our own caps it would be relevant, but with the current raw situation it definitely isn't (I can count the number of times I've actually seen a japanese anamorphic tv raw on the fingers of one hand)

[edogawaconan]

does non 1:1 PAR actually have more information than 1:1 PAR? (eg using PAR 40:33 hardly encoded to video versus MKV's AR setting with square pixel video)

[peter the llama]

Originally Posted by TheFluff

why are you talking so much about anamorphicness with regards to tv raws? maybe if we made our own caps it would be relevant, but with the current raw situation it definitely isn't (I can count the number of times I've actually seen a japanese anamorphic tv raw on the fingers of one hand)

Err, I assumed we were talking about PAL DVDs as a source. I assumed that because they upscale to 1024x576. Sorry if my rant was way off target, and the sources you're working with have square pixels. I don't really know much about sources other than DVDs...

Originally Posted by edogawaconan

does non 1:1 PAR actually have more information than 1:1 PAR? (eg using PAR 40:33 hardly encoded to video versus MKV's AR setting with square pixel video)

No. A 640x480 image (for example) has 640 pixels of horizontal resolution, and 480 pixels of vertical resolution, regardless of the aspect ratio it is to be displayed at. But I don't think that's what you were trying to ask...

uhh, let me try explaining again. Say your source is a PAL DVD, 720x576, widescreen format (i.e. should be shown at 16:9). On a 1680x1050 monitor, a DVD player would scale the video up to 1680x945 (945 = 1680*9/16, since horizontal resolution is the limiting factor). So the picture is scaled up enough that each source pixel is spread over significantly more than 1 screen pixel. You can think about resolution in terms of dots per inch (DPI), which is more useful for comparing in a size-independent way. Widescreen PAL DVDs have much more vertical resolution than horizontal resolution. i.e. more DPI in the vertical direction. 1680/720 = 2.33..., 945/576 = 1.64. Source pixels are stretched a lot more in the horizontal than the vertical direction.

When you zoom in on a digital photo, you start seeing the invidivual pixels. This starts happening in the horizontal direction a lot sooner than in the vertical direction. The source has more vertical resolution than horizontal resolution (in the DPI sense, not image size sense). BTW, this effect is not so dramatic with NTSC DVDs, because 720x480 is closer to 16:9 already, so the pixels aren't so far from square. Or with fullscreen PAL, because it's closer to 4:3.

So to try to answer your question, a PAL DVD has 720 pixels of horizontal resolution, and 576 pixels of vertical resolution (the letterboxing for aspect ratios > 16:9 means less vertical pixels, but the same DPI). That's how much information your source has. Unless you can go back to the source the DVD was mastered from, and sample it with square pixels, you can't get any more information from the source, no matter what you do.[1] Re-sampling the master the DVD was made from at 1024x576 would give you an image with 1024 pixels of horizontal information. Upscaling from 720x576 would give you an image with 720 pixels of horizontal information spread across 1024 pixels. Video codecs can't do anything about this, and essentially have to deal with what looks like more information.[2]

So a 720x576 video has the same amount of information as a 1024x576 video created by upscaling it, but the 1024x576 video takes more bits and cpu time for x264 to encode.

If you were downscaling to hit a lower bitrate without having nasty artifacts, then you get to decide whether you want to throw away more DPI, to bring the horizontal and vertical DPI closer (or equal, if you do the normal thing and go all the way to square pixels). When downscaling, it does make some sense to go down to square pixels, since IIRC the human visual system is if anything more tuned in to horizontal things. (humans evolved on flat savannah land scanning the horizon for predators...)

Just be aware that scaling down to 640x360 square pixels doesn't just lose 640/720 amount of information. You're throwing away a huge amount of vertical information. 360/576 = 5/8, so you're keeping 8/9ths of the horizontal resolution, but only 5/8ths of the vertical. Of course, if you were going to keep more information, you should maybe keep more of the horizontal, since there was less of it to start with (lower DPI). That goes until you're keeping all of the horizontal information (720x?, where ? is something less than 576. again, forget about letterboxing and cropping.), and you're just throwing away some vertical resolution to get the rez low enough.

Never ever upscale either horizontal or vertical before encoding, unless you are forced to because you're targeting a player that can't handle anamorphic video.

I hope that answers your question.

[1] You might make it look better by denoising it or whatever, but that's throwing away information. I'm assuming for the sake of argument that every pixel of the source is actually valuable information that you're trying to preserve. In reality, what you feed your encoder is the source you're really interested in + noise (compression artifacts, grain, and other noise). This doesn't change whether you should scale or not.

[2] You could say that it is more information, since the scaler you use has to blend pixels together and stuff. It's not information about the original source, though.

[edogawaconan]

Originally Posted by peter the llama

No. A 640x480 image (for example) has 640 pixels of horizontal resolution, and 480 pixels of vertical resolution, regardless of the aspect ratio it is to be displayed at. But I don't think that's what you were trying to ask...

no, that is what I'm asking.
in short, difference between this

and this


which is answered in your first sentence

[jfs]

And FYI, 1024x576 is a quite popular resolution for Japanese TV cappers to release their raws at, despite it not being a "natural" scaling for any broadcast resolution. (I have also seen 1024x768 raws for 4:3 shows.) I believe that most of the time, 1024x576 raws are AD upscales, ie. upscaled from 480 lines, and most cappers who have access to 720 or more lines stay at the original line count. (Except perhaps some with 1080i access, not sure there.)

[TheFluff]

Originally Posted by peter the llama

Err, I assumed we were talking about PAL DVDs as a source. I assumed that because they upscale to 1024x576. Sorry if my rant was way off target, and the sources you're working with have square pixels. I don't really know much about sources other than DVDs...

anyone using PAL DVD's as source for any anime rip other than a very high-budget properly mastered movie should die in a fire

[peter the llama]

Originally Posted by TheFluff

anyone using PAL DVD's as source for any anime rip other than a very high-budget properly mastered movie should die in a fire

Oh, because they're usually converted from hard telecined NTSC... like the copy of Castle of Cagliostro I've seen. Right. Too bad that's the rule, not the exception. Most of my experience is with 24fps movies, where the PAL DVD is usually the best source. (sped up by 25/24, but much more vertical resolution than the NTSC DVD. Of course, most releases throw it all away by scaling to square pixels at <= 720 pixels wide.)

Originally Posted by jfs

And FYI, 1024x576 is a quite popular resolution for Japanese TV cappers to release their raws at

Thanks, now I have some idea how fansubbed anime releases happen.
But you say someone's upscaling somewhere? Grrrr. (j/k).

[sea89]

Is it possible to use VirtualDubMod with MeGUI to encode? I'm having problems cutting clips from a dvd source with MeGUI. VirtualDubMod mod works but I can only get it to work with ffdshow which either looks bad or is too big.