So I've some Hi8 and Video8 recordings with my Canon UC-X20Hi which I can digitize with my crappy Dazzle.
However, while the Dazzle got 640x480 which is "true" 4:3 (I suppose?) used for NTSC, it only got 720x576 for PAL. So I'm wondering, should I digitize it with 720x576 and then stretch it to 768x576 (which is actual 4:3, AFAIK) or what? Im not too clever on the subject but I think it's something with square pixels? Can someone elaborate and perhaps learn me the best way to go about getting a good result with pal videotapes.
+ Reply to Thread
Results 1 to 13 of 13
Analog PAL is 576 discreet scan lines but on the horizontal axis is a continuous waveform. It can be sample with as few or as many pixels as you want. It is customary to sample with 720. That is generally considered enough to capture all the detail of the highest quality analog PAL sources, without being excessive. PAL DVDs, for example, use a 720x576 frame. 720x576 is a 5:4 aspect ratio so the image is adjusted at playback to give a 4:3 picture.
Whether you want to resize to square pixels depends on what you are making. DVDs don't support 768x576 so you should leave the video 720x576. If you want to upload to Youtube or some other video sharing network you might want to use square pixels.
Please don't use Dazzle as your guide to understanding video! 640x480 NTSC, geez.
Last edited by Cornucopia; 22nd Apr 2014 at 09:57.
This depends from sampling clock - for 13.5MHz sampling clock there is 720 pixels max, for 14.75MHz there is 768 pixels max.
BTW 768 is for square pixel (pixel aspect for 4:3 screen is 1:1), remember there is always Source Aspect Ratio, Pixel Aspect Ratio and Display Aspect Ratio.
And just to throw another cog in the wheel, analogue tv transmissions are 625 lines (NTSC 525 lines)
@themaster1, those figures by themselves do not add anything useful to this discussion. In fact, they muddle it up even further.
One of the primary rules of video, which all here should know by now is:
Display Aspect Ratio = Pixel Aspect Ratio * Storage Aspect Ratio
As pandy and jagabo were mentioning, 768 is just the Square Pixel EQUIVALENT to 720's native non-square pixels.
Solving that same equation using square (1:1) PAR: 1.333333 = 1 * (? / 576) = 1.3333333 * 576 = ? ..... 768.
Last edited by Cornucopia; 2nd May 2014 at 12:12.
In the DVD and digital broadcast world, high quality "PAL" is 720x576, or 704x576 (i.e. with the parts that's not actually used in the analogue world removed - the extra 8 pixels either side were just included in the standard as a tolerance). On quality compromised digital broadcasts it can be 544x576, 480x576, 352x576, and even 352x288 - just like 720vs704, some pixels are sometimes left off either side, making the horizontal pixel count even smaller (e.g. 528x576).
All of these resolutions can represent a 4x3 picture or x 16x9 picture.
768x576 is only ever used when manipulating "PAL" video in systems that only understand square pixels. It's basically true to say that real "PAL" video never actually has square pixels.
Capture at 720x576. Crop to 704x576 if you want.
Question is a bit incorrect - PAL line length (visible part) is in fact equal 52.3us and it can have unlimited number of pixels (this depend only from sampling speed), for typical PAL B/G video signal bandwidth from practical perspective can't be bigger than 5.2MHz assuming fancy DSP involved - standard define bandwidth as 5MHz. Thus real resolution for PAL is (for 13.5MHz sampling) close to approx. 544 pixels.
For 13.5MHz maximum bandwidth is 6.75MHz, 1 pixel period is 1/13.5MHz=(approx) 74.074ns, if line period is equal to 52.3 us i.e. 52300ns then maximum number of pixels can be 52300/74.074=706.05, now for 5.2MHz PAL B/G standard bandwidth number of pixels is equal (5.2MHz/6.75MHz)*706.05=543.92 pixel.
This bandwidth limitation is usually common for non digital (analog RF broadcast) sources.
Last edited by pandy; 2nd May 2014 at 10:26.
I started encoding all my PAL videos to 768x576 mostly because I thought maybe NNEDI3_resize16 might do a better job dealing with the warping caused by removing anamorphic than the WDTV would.
I don't know if it's relevant to the WDTV Live Streaming I have or not but I read somewhere that WDTV Lives use spline resizing, I also read that it de-interlaces by discarding fields, I've watched house, which is pretty much progressive and I can tell it's being de-interlaced when I watch the original MakeMKV rip. NNEDI3_Resize16 is better than spline, I wouldn't bother upsizing live action DVDs all the way to 1080p, but at least I can try to make the edges a little better and considering removing anamorphic stretches more horizontal than vertical (ie warping) I figure if I'm going to do anything then that's it.
By the way, I used to be rather strict about not resizing progressive material, but I encoded an episode of Life on Mars (ep.4 I think) and there were dream sequences in the episode that needed a much greater crop on the bottom edge then the rest of the episode. I had a choice between leaving the black bars there, cropping the entire episode to match or resizing those sequences. I chose to resize, and when I watched the episode I really couldn't see any difference between those sequences and the rest of the encode. I know in theory that every resize warps the picture further away from the original, but the fact is, if you don't notice then it's not an issue. And if I can resize a video partway using a superior resizer, knowing that it will be subjected to an inferior resizer which will leave greater artefacts somewhere down the track I don't see what the problem is.
-edit- I truly doubt anything I encode is EVER going to be watched on a CRT. I believe in the principals of copy protection if not the details.