2008-08-30, 22:06 | Link #142 | |
Infie
Fansubber
Join Date: Jul 2006
Location: Texas
|
Quote:
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 |
|
2008-08-30, 23:23 | Link #143 | ||
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
Quote:
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:
__________________
|
||
2008-08-31, 03:18 | Link #144 |
Senior Member
Join Date: Dec 2007
|
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...) |
2008-08-31, 04:02 | Link #145 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
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.
__________________
|
2008-08-31, 10:04 | Link #147 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
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.
__________________
|
2008-09-08, 04:34 | Link #150 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
|
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.
__________________
|
2008-09-08, 05:38 | Link #151 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
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
__________________
|
|
2008-09-08, 11:53 | Link #154 | |
Lucid Light
Join Date: May 2008
|
using DGIndex to create d2v file is easier for me.
Quote:
why not x264 directly ? if that very necessary, think 250GB will be enough? <_< |
|
2008-09-08, 12:17 | Link #155 |
Pioneer in Fansub 2.0
Join Date: Aug 2007
|
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.
__________________
|
2008-09-08, 12:57 | Link #156 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
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.
__________________
|
2008-09-09, 00:06 | Link #157 |
Lucid Light
Join Date: May 2008
|
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 |
2008-09-09, 03:21 | Link #160 |
Member
Join Date: Jul 2007
|
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...
|
|
|