NEW Guides and AmvApp BETA
- Jnzk
- Artsy Bastid
- Joined: Tue Jan 28, 2003 5:30 pm
- Location: Finland
Playing with the mp4box -info switch and a 704x480 anamorphic source...
(encoded as is)
AVC/H264 Video - Visual Size 704 x 480 - Profile Main @ Level 5.1
Pixel Aspect Ratio 40:33 - Indicated track size 853 x 480
(added 8 px black borders)
AVC/H264 Video - Visual Size 720 x 480 - Profile Main @ Level 5.1
Pixel Aspect Ratio 32:27 - Indicated track size 853 x 480
According to the AMV Resize Calculator, the latter should be 873 x 480. Or am I just confused?
(encoded as is)
AVC/H264 Video - Visual Size 704 x 480 - Profile Main @ Level 5.1
Pixel Aspect Ratio 40:33 - Indicated track size 853 x 480
(added 8 px black borders)
AVC/H264 Video - Visual Size 720 x 480 - Profile Main @ Level 5.1
Pixel Aspect Ratio 32:27 - Indicated track size 853 x 480
According to the AMV Resize Calculator, the latter should be 873 x 480. Or am I just confused?
- Zero1
- Joined: Fri Jan 02, 2004 12:51 pm
- Location: Sheffield, United Kingdom
- Contact:
What Zarx said (but as I was trying to recall, I thought MP4Box would give you the proper framerates automatically even if you just specify 23.976 for instance).
As for the resizing, yes and no. Depends how anal you want to be, and also your opinion/assumption on how the source was encoded.
See the SARs you specified are correct, they both produce a 16:9 frame shape on playback, be it originally 704x480 or 720x480. However what you need to bear in mind is that the majority of encodes that are 720 wide, have up to 16 pixels of dead space, or rather we can simply say it has an active area of ~704 pixels (samples is actully more accurate, but seeing as it's digitized).
You see where 873 comes from is Target active area size/Actual active area size*Overall frame size=Size that the actual active area should be resized to.
Ok, well that's not the clearest example ever, but lets fill in the values
853.33/704*720=872.73
When the 720 with borders is resized to 872.73, the active image without borders is now 853.33 wide.
Here is a little example.
First Image: 720px (704 active + 16px borders) resized to 873px
Second Image: 704px (all active) resized to 853px
Third Image: 720px (704 active +16px borders) resized to 853px.
Now you will notice that the first and second images are similar, give or take a line or two (due to rounding). Although the first image is stretched more, it's active area of 704px actually becomes in the region of 853px, which is the same as cropping the borders and resizing the full 704px to 853px.
Resizing the full 720px > 853px is a different story. Now the active area is only approximately. The active area would become 834px.
Most people will crop to 704 and set a 40:33 SAR (to get 853). Encoding it as 720 with borders and setting the appropriate SAR to get 873 essentially gives you the same results as just cropping to 704 and resizing to 853 (actually it's not as good because you are wasting bits on coding the borders).
Sometimes the borders are there to assist the correct AR (because MPEG-2 has a very limited set of aspect ratios, so adding borders or letterboxes help get the correct AR even with a limited set), such as excessive borders. This is where you have to use your own judgement and any information about the source.
As for the resizing, yes and no. Depends how anal you want to be, and also your opinion/assumption on how the source was encoded.
See the SARs you specified are correct, they both produce a 16:9 frame shape on playback, be it originally 704x480 or 720x480. However what you need to bear in mind is that the majority of encodes that are 720 wide, have up to 16 pixels of dead space, or rather we can simply say it has an active area of ~704 pixels (samples is actully more accurate, but seeing as it's digitized).
You see where 873 comes from is Target active area size/Actual active area size*Overall frame size=Size that the actual active area should be resized to.
Ok, well that's not the clearest example ever, but lets fill in the values
853.33/704*720=872.73
When the 720 with borders is resized to 872.73, the active image without borders is now 853.33 wide.
Here is a little example.
First Image: 720px (704 active + 16px borders) resized to 873px
Second Image: 704px (all active) resized to 853px
Third Image: 720px (704 active +16px borders) resized to 853px.
Now you will notice that the first and second images are similar, give or take a line or two (due to rounding). Although the first image is stretched more, it's active area of 704px actually becomes in the region of 853px, which is the same as cropping the borders and resizing the full 704px to 853px.
Resizing the full 720px > 853px is a different story. Now the active area is only approximately. The active area would become 834px.
Most people will crop to 704 and set a 40:33 SAR (to get 853). Encoding it as 720 with borders and setting the appropriate SAR to get 873 essentially gives you the same results as just cropping to 704 and resizing to 853 (actually it's not as good because you are wasting bits on coding the borders).
Sometimes the borders are there to assist the correct AR (because MPEG-2 has a very limited set of aspect ratios, so adding borders or letterboxes help get the correct AR even with a limited set), such as excessive borders. This is where you have to use your own judgement and any information about the source.
7-zip // x264 (Sharktooth's builds) // XviD (Koepi's builds) // MP4box (celtic_druid's builds) // Firefox // CCCP
- Tiiscool
- Joined: Sun Nov 14, 2004 8:51 am
- Location: Alstätte, Germany
- Contact:
PAL Guide
Hello,
what do you think about this ?
PAL Interlacing
The original can be found here:
ExotischesInterlacing
Todo:
check my english translation
check the commands, (one or two are wrong) to create the dummy avi
update the commands to solve the problem
Best regards,
Ti
what do you think about this ?
PAL Interlacing
The original can be found here:
ExotischesInterlacing
Todo:
check my english translation
check the commands, (one or two are wrong) to create the dummy avi
update the commands to solve the problem
Best regards,
Ti
- Kumatora
- Joined: Sat Feb 03, 2007 1:26 pm
- Location: Luling, LA
- Zarxrax
- Joined: Sun Apr 01, 2001 6:37 pm
- Contact:
- Tiiscool
- Joined: Sun Nov 14, 2004 8:51 am
- Location: Alstätte, Germany
- Contact:
Dealing with Asprect Ratios
Hello,
maybe there is an error: side
There is a NTSC part in the PAL part. Maybe this is placed wrong ?
Where: Mixing PAL 4:3 and 16:9 Sources -> Making all the Sources 4:3
What:
Output NTSC 4:3 with Square Pixels:
LanczosResize(1024,576)
Crop(128,0,-128,-0)
Best regards,
Ti
maybe there is an error: side
There is a NTSC part in the PAL part. Maybe this is placed wrong ?
Where: Mixing PAL 4:3 and 16:9 Sources -> Making all the Sources 4:3
What:
Output NTSC 4:3 with Square Pixels:
LanczosResize(1024,576)
Crop(128,0,-128,-0)
Best regards,
Ti
- Tiiscool
- Joined: Sun Nov 14, 2004 8:51 am
- Location: Alstätte, Germany
- Contact:
Maybe a typo
Hello,
maybe I found a typo:
here
PAL Graphics: Make images at 1024x576 and resize to 720x567 to have DVD PAR.
Best regards,
Ti
maybe I found a typo:
here
PAL Graphics: Make images at 1024x576 and resize to 720x567 to have DVD PAR.
Best regards,
Ti
- Tiiscool
- Joined: Sun Nov 14, 2004 8:51 am
- Location: Alstätte, Germany
- Contact:
Hello,
maybe there is a line missing:
Making your footage Progressive: I plan to edit the AviSynth files directly (method 2) -> Telecined Footage -> 2-Pass IVTC (Advanced) -> With post processing
MPEG2Source ("C:\yourfolder\blah.d2v")
TFM(cthresh=4, slow=2, clip2=deint, output="C:\yourfolder\something.tfm")
TDecimate(mode=1, output="C:\yourfolder\something.dec")
Crop(0,0,4,2)
I think that deint is missing:
deint = TDeint(mode=2, mtnmode=3, blim=100)
It would be nice to know why there should be made an encoding, when we use the 2Pass Method. Is it to check if the encoding works ? Because I get the files for the second pass, also without the encoding?
Best regards,
Ti
maybe there is a line missing:
Making your footage Progressive: I plan to edit the AviSynth files directly (method 2) -> Telecined Footage -> 2-Pass IVTC (Advanced) -> With post processing
MPEG2Source ("C:\yourfolder\blah.d2v")
TFM(cthresh=4, slow=2, clip2=deint, output="C:\yourfolder\something.tfm")
TDecimate(mode=1, output="C:\yourfolder\something.dec")
Crop(0,0,4,2)
I think that deint is missing:
deint = TDeint(mode=2, mtnmode=3, blim=100)
It would be nice to know why there should be made an encoding, when we use the 2Pass Method. Is it to check if the encoding works ? Because I get the files for the second pass, also without the encoding?
Best regards,
Ti
- Zarxrax
- Joined: Sun Apr 01, 2001 6:37 pm
- Contact:
I think most of these typos are already mentioned earlier in this thread.
You must do the encoding for it to process the entire video. If you just open the avisynth script it will of course create the file, but it cant actually put all of the necessary content into the file until the WHOLE video has been processed, which is why you do the encoding.
You must do the encoding for it to process the entire video. If you just open the avisynth script it will of course create the file, but it cant actually put all of the necessary content into the file until the WHOLE video has been processed, which is why you do the encoding.
- Kumatora
- Joined: Sat Feb 03, 2007 1:26 pm
- Location: Luling, LA
All right. I still don't know if I'll be submitting anything for that. I need to order Vegas.Zarxrax wrote:Probably not until after I finish amv hell 4.Kumatora wrote:When can we expect the final version to be released?
I also need to ask another question. Is it a good idea to put that Nero AAC Encoder? Isn't that now released commercially?