Avisynth Help thread

[MoonLight-]

DVD resolution is 480x704, but when watching it appears like 848x480 res
and same goes to mkv-dvdrip..

How do I do that?

[Medalist]

Originally Posted by MoonLight-

DVD resolution is 480x704, but when watching it appears like 848x480 res
and same goes to mkv-dvdrip..

How do I do that?

I'm sure hope you mean 704x480

And the actual NTSC scan on this resolution is actually 848x480 or something like that, I'm not a major encoder though so I don't know how to explain it exactly, I'd be quite interested to know specifically myself.

It's the same, just ignore it x.x

[TheFluff]

Originally Posted by MoonLight-

DVD resolution is 480x704, but when watching it appears like 848x480 res
and same goes to mkv-dvdrip..

How do I do that?

Originally Posted by Medalist

I'm sure hope you mean 704x480

And the actual NTSC scan on this resolution is actually 848x480 or something like that, I'm not a major encoder though so I don't know how to explain it exactly, I'd be quite interested to know specifically myself.

It's the same, just ignore it x.x

NTSC resolution is 720x480. This is usually cropped to 704x480 for somewhat obscure reasons.

Now, a picture with the resolution 704x480 has an aspect ratio of 3:2 (or 1.5:1), which isn't very common anywhere (4:3 and 16:9 are the by far most common aspect ratios for video). However, NTSC does not have square pixels, and the image is not supposed to be displayed at 3:2. As explained in the page previously linked, NTSC has an x:y PAR (Pixel Aspect Ratio) of 10:11 (to be completely exact it's actually 4320:4739 but seriously who cares), or 1:1.1, which means that to properly display a 704x480 NTSC image on a monitor with square pixels (i.e. PAR 1:1; pretty much all computer monitors have square pixels) it needs to be stretched by 10% in the vertical direction to make the aspect ratio correct. That is to say, it's should be displayed at 704x528, which coincidentally happens to be 4:3. How convenient.

Additionally, NTSC images may also be 16:9, in which case they should be stretched horizontally instead, to a resolution of 853x480 (usually rounded down to 852, since most renderers require a mod2 image).

This stretching can either be done at encoding time (i.e. you stretch the image with a resizing filter and encode it at 704x528 or 848x480 (rounded down to 848 for mod16 reasons)) or at playback time (i.e. you encode the image as 704x480 and set a flag either in the video bitstream or in the container that tells the player to display the image at the given resolution). The latter is usually preferable since the original image is 704x480 anyway and upscaling it before encoding wastes space. Also, if you assume that most people watch in fullscreen or at least in a player window bigger than the original resolution, resizing at playback time lets you get away with one resizing of the image, while resizing at encoding time makes the image get resized twice (once at encoding time and once at playback time).

Further reading:
http://www.hometheaterhifi.com/volum...vember-99.html
http://www.widescreen.org/aspect_ratios.shtml
http://en.wikipedia.org/wiki/Aspect_ratio_(image)
http://en.wikipedia.org/wiki/Anamorphic_widescreen
http://lipas.uwasa.fi/~f76998/video/conversion/




tl;dr:

[comatose]

Very informative.

But just one question. Is the video you're muxing something*480?
If so, why not set the aspect ratio to 16/9 instead of setting the display width/height to 852x480? That way, you can achieve perfect 16:9 (I don't know if it happens in practice, but hey...)

[TheFluff]

Originally Posted by comatose

But just one question. Is the video you're muxing something*480?
If so, why not set the aspect ratio to 16/9 instead of setting the display width/height to 852x480? That way, you can achieve perfect 16:9 (I don't know if it happens in practice, but hey...)

The renderer will still round to closest mod2 image size. I usually set the display resolution explicitly because then you can at least be sure your softsubs render right (if you only set the AR the player might decide to downscale vertically instead of upscaling horizontally, which can affect subtitle size). It also gives you more freedom to compensate for extra cropping or oddball aspect ratios.

[comatose]

Meh. Crappy renderers.
Also, I was under the impression that only the width is ever modified. I've never seen a player resize the height, hardware or software.
I guess if you say that then you probably have, though.

[TheFluff]

Originally Posted by comatose

Meh. Crappy renderers.
Also, I was under the impression that only the width is ever modified. I've never seen a player resize the height, hardware or software.

MPlayer (or at least some of its renderers) occasionally decides to resize in the vertical direction, but on the other hand it doesn't care about the display resolution (actually most players don't but don't tell anyone about that, it'd ruin my reasons for having an odd habit); 704x528, 640x480 and AR 4:3 all render the same.

[comatose]

Ugh. Yeah. I've noticed it was used as a ratio and not as a resolution once, but it didn't really bother me so I didn't test it :X

[MoonLight-]

Thnaks TheFluff and comatose for helping

just wandering..
How do you encode .ts file exactly ? ;o

starting with .avs and everything :P


thanks in advance !

[jfs]

Uh, "encode .ts file", do you mean use whatever as input and produce a TS as output, or use a TS as input and produce whatever as output?
Trust me, you don't want to produce transport streams, it's a format designed for heavy fault tolerance in digital broadcast systems, so it doesn't matter if the signal drops out for several seconds at a time. This means it has a huge overhead; if you mux the same elementary streams as TS and as MP4 you will see that the TS file is significantly larger.

If you want to use a TS as a source, what I prefer is using a program such as ProjectX (there's also another one I can't remember the name of) to demux the transport stream into elementary streams which can then be handled by regular tools, eg. parse an M2V file with DGIndex and then source it into Avisynth with DGDecode.

[TheFluff]

Originally Posted by jfs

If you want to use a TS as a source, what I prefer is using a program such as ProjectX (there's also another one I can't remember the name of) to demux the transport stream into elementary streams which can then be handled by regular tools, eg. parse an M2V file with DGIndex and then source it into Avisynth with DGDecode.

DGIndex can read transport streams directly these days. Which means encoding a TS is pretty much like encoding a DVD:
1) acquire TS
2) create .d2v with DGIndex, and note coding type (interlaced/progressive) and presence of hybrid material
3) write Avisynth script with suitable field matching/deinterlacing/decimating filters depending on state of source video as detected in 2) (alternative: pull source through YMC and do stuff in YATTA)
4) determine suitable cropping and resizing settings and add to Avisynth script
5) add suitable filtering
6) encode to lossless
7) encode lossless with x264
8) mux to MKV
9) release

[Yumi`]

Or eac3to instead of DGIndex for avc video (and all kinds of very useful HD disc audio conversion/extraction). Or xport and dgavcindex/graphedit, but those are less handy imo.

[comatose]

DGAVCIndex works great and lets you keep the convenient DGIndex-style workflow
Buuuut I guess if you're dealing with Blu-ray you gotta do what you gotta do >_>

TheFluff: YMC?

[MoonLight-]

using DGIndex to create d2v file is easier for me.

6) encode to lossless
7) encode lossless with x264

I don't get this.. why should I encode to lossless b4 encoding lossless with x264,
why not x264 directly ?

if that very necessary, think 250GB will be enough? <_<

[Daiz]

Usually you encode to lossless if you intend to do any filtering, as then you only have to run the filters once, not multiple times (like if you were doing 2-pass encode with x264, you'd have to run your filters twice while doing heavy encoding, slowing the process down).

And regarding the lossless format, I would suggest lossless H.264 with no CABAC (--qp 0 --no-cabac) as it compresses very well for a lossless format and also gives the fastest decoding speeds, especially if you have CoreAVC.

[TheFluff]

Originally Posted by comatose

TheFluff: YMC?

Yatta Metrics Collector

As for lossless sizes, 250 GB is definitely enough. With ffvhuff at fastest settings (worst compression) 25 minutes of anime at NTSC resolution takes 4-5 GB at most; at 720p you're looking at 12-15 GB for the same length.

[MoonLight-]

thanks again..

1st stage encoding to lossless:
I use lagarith to create lossless file

and LanczosResize, TDeint, TDecimate and toon with default setting
*everything goes ok till now*


then, 2nd stage encoding with x264

i use DeVeed, levels and MSmooth!
bitrate: 3700

but.. unfortunately I face some issue *block* :\
like this screen.. everything was ok till I add "ConvertToYV12()"





my .ts source is [justanotherdouche]_Gundam_00_S2_Teaser
+ DeNoise and DeBlock didn't help that much

[Dark Shikari]

gradfun2db()

[Nagato]

with low bitrates the blocks will be revived like zombies anyway.
Use gradfun2db() @ postprocessing instead.

[max2k]

I dont think it is blocking. I would say it ist colorbending through over smoothing. So like Dark Shikari sayd use Gradefun() preencoding to get some Grain in the encode, or dont denoise that strong. If u plan to do a xvid encode u have to use some other "Noiser", and encode with more bitrate then the 1pass would sugest to keep it...