phædrus
13th February 2007, 05:51
A local station is showing a syndicated show every Sunday afternoon as a letterboxed 4:3 format INSIDE a widescreen 1080i broadcast. It is like a letterboxed letterbox! In short, there are huge black bars on all four sides of the 16:9 image in the middle of the screen.
As near as I can determine, the image itself is very close to 1408x792, therefore I could crop 256 pixels off both the left and right sides, and crop 144 pixels off both the top and bottom and take care of most if not all the black bars.
So a normal way (I think) would be...
Telecide()
Decimate()
Crop(256,144,-256,-144)
LanczosResize(640,360)
Will it cause a problem if I crop before IVTC? Wouldn't the encode run a little faster since the IVTC (Telecide) wouldn't need to act on so many pixels?
e.g.
Crop(256,144,-256,-144)
Telecide()
Decimate()
LanczosResize(640,360)
I can crop after IVTC, but I'm using a slower computer (1.4GHz Pentium 4) and I would like to gain a little time if I can.
---
As an alternative I could do this, perhaps?
AssumeTFF()
SeparateFields()
SelectEven()
Decimate()
#This will give me a field of 1920x540, right?
Crop(256,72,-256,-72)
#I think this crop would properly nix the black bars. Then I could resize.
LanczosResize(640,360)
I'm asking because I have never used this type of script before. It seems to me this would work, and even though I am throwing away half the lines, since the original material does not seem very sharp, and since my final encode will only be 640x360, I don't think it would matter much.
Normally I don't crop because I just can't be bothered with a little black bar, but this is ridiculous.
I hope I haven't made some stupid newbie errors, but these two methods seem right to me. What is your advice? I feel like I'm wading into deep water here. Of course I could just test both these methods, and I probably will, but I thought someone might have a third way (assuming my two ideas will both work) that is better for one reason or another. (Oh, I just read in another thread that I could save processing time by resizing horizontally before IVTC and resize vertical afterwards. Good idea.)
As near as I can determine, the image itself is very close to 1408x792, therefore I could crop 256 pixels off both the left and right sides, and crop 144 pixels off both the top and bottom and take care of most if not all the black bars.
So a normal way (I think) would be...
Telecide()
Decimate()
Crop(256,144,-256,-144)
LanczosResize(640,360)
Will it cause a problem if I crop before IVTC? Wouldn't the encode run a little faster since the IVTC (Telecide) wouldn't need to act on so many pixels?
e.g.
Crop(256,144,-256,-144)
Telecide()
Decimate()
LanczosResize(640,360)
I can crop after IVTC, but I'm using a slower computer (1.4GHz Pentium 4) and I would like to gain a little time if I can.
---
As an alternative I could do this, perhaps?
AssumeTFF()
SeparateFields()
SelectEven()
Decimate()
#This will give me a field of 1920x540, right?
Crop(256,72,-256,-72)
#I think this crop would properly nix the black bars. Then I could resize.
LanczosResize(640,360)
I'm asking because I have never used this type of script before. It seems to me this would work, and even though I am throwing away half the lines, since the original material does not seem very sharp, and since my final encode will only be 640x360, I don't think it would matter much.
Normally I don't crop because I just can't be bothered with a little black bar, but this is ridiculous.
I hope I haven't made some stupid newbie errors, but these two methods seem right to me. What is your advice? I feel like I'm wading into deep water here. Of course I could just test both these methods, and I probably will, but I thought someone might have a third way (assuming my two ideas will both work) that is better for one reason or another. (Oh, I just read in another thread that I could save processing time by resizing horizontally before IVTC and resize vertical afterwards. Good idea.)