2007-07-19, 17:16 | Link #81 | |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
Quote:
|
|
2007-07-19, 23:30 | Link #82 |
King of Hosers
Join Date: Dec 2005
Age: 41
|
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.
|
2007-07-20, 21:27 | Link #84 |
Retired
Fansubber
|
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.
__________________
|
2007-07-21, 16:10 | Link #85 |
King of Hosers
Join Date: Dec 2005
Age: 41
|
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?
Code:
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 |
2007-07-22, 04:51 | Link #86 |
Part 8
IT Support
|
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.
|
2007-07-23, 03:12 | Link #87 |
King of Hosers
Join Date: Dec 2005
Age: 41
|
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. |
2007-07-24, 21:20 | Link #89 | |||
Junior Member
Join Date: Jul 2007
|
Quote:
Quote:
Quote:
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 Last edited by peter the llama; 2007-07-24 at 21:36. Reason: trellis shouldn't be used with dct_decimate or crf mode |
|||
2007-07-24, 23:28 | Link #91 | |
Yuuki Aoi
Join Date: Jul 2004
|
Quote:
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.
__________________
|
|
2007-07-25, 00:24 | Link #92 | |
Junior Member
Join Date: Jul 2007
|
Quote:
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. |
|
2007-07-25, 03:08 | Link #93 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
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)
__________________
|
2007-07-25, 23:29 | Link #95 | ||
Junior Member
Join Date: Jul 2007
|
Quote:
Quote:
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. |
||
2007-07-26, 00:16 | Link #96 | |
Hi
Fansubber
|
Quote:
in short, difference between this and this which is answered in your first sentence |
|
2007-07-26, 02:04 | Link #97 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
|
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.)
__________________
|
2007-07-26, 04:02 | Link #98 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
__________________
|
|
2007-07-26, 21:40 | Link #99 | ||
Junior Member
Join Date: Jul 2007
|
Quote:
Quote:
But you say someone's upscaling somewhere? Grrrr. (j/k). |
||
|
|