<p>A small bit on terminology :- SD and HD refers to resolution - in the basic sense of the word, not dimensions. A given video can be wide or tall or square while being SD or HD. It's the legacy of television broadcast standards that SD content is 4:3 and HD 16:9 but display aspect ratio and visual definition aren't connected. That nitpick aside..</p>

<p>For 4:3 to 16:9 and back.</p>

<pre><code>ffmpeg -i input43.mp4 -vf "scale=iw*sar:ih,setsar=1,pad=ih*16/9:ih:(ow-iw)/2:0" out43in169.mp4

ffmpeg -i out43in169.mp4 -vf "crop=ih*4/3:ih" backto43.mp4
</code></pre>

<p>For 16:9 to 4:3 and back.</p>

<pre><code>ffmpeg -i input169.mp4 -vf "scale=iw*sar:ih,setsar=1,pad=iw:iw*3/4:0:(oh-ih)/2" out169in43.mp4

ffmpeg -i out169in43.mp4 -vf "crop=iw:iw*9/16" backto169.mp4
</code></pre>

<p>The crop filter automatically crops from the center of the input frame so it's not necessary to specify the x and y offsets. Audio is transcoded, always. Add <code>-c:a copy</code> to avoid that.</p>

CC BY-SA 4.0
2018-12-22T14:59:36.787Z
Thanks. Video has to be encoded anyways, right? We can not use `-c:v copy`?
angel_30
CC BY-SA 4.0
2018-12-22T15:01:08.297Z
Btw, does ffmpeg use multi-threading by default? I'm thinking how we can make it run faster. How about running on GPU?!
angel_30
CC BY-SA 4.0
2018-12-22T15:25:38.713Z
FFmpeg does processing in multiple threads where possible.
Gyan
CC BY-SA 4.0
2018-12-22T15:25:51.837Z
`-c:v copy` is not possible here.
Gyan
CC BY-SA 4.0
2019-12-19T14:59:01.080Z
this is ok for 1 shot encoding when you eyeball control your input, in any batch stuff you should cropdetect first (https://www.nab.org/documents/resources/paperTandberg.pdf) and use logic for correct cropping/scaling the area of interest depending on your i/o dar, it can be quite pain in the butt in fact to automate it in a bulletproof way...
Boris Ka
CC BY-SA 4.0
2018-12-22T05:12:00.483Z
2018-12-22T05:12:00.483Z
Gyan
<p>I'm trying to use FFMpeg to adapt 4:3 (SD) to 16:9 (HD) and reverse function. </p>

<ol>
<li>When SD is converted to HD, I need to add pillarboxes around the content.</li>
<li>When HD is converted to SD, I need to add textboxes.</li>
<li>Reverse of 1, I need to remove the pillarbox to convert to SD.</li>
<li>Reverse of 2, I need to remove the textbox to convert to HD.</li>
</ol>

<p>For 1, I already found a solution:</p>

<pre><code>ffmpeg -i input43.mp4 -vf "scale=640x480,setsar=1,pad=854:480:107:0" out43HD.mp4
</code></pre>

<p>But what are the commands to do 2, 3, and 4?</p>

<video><ffmpeg><video-editor><conversion><aspect>
4:3 - 16:9 Aspect Ratio Conversion with Pillarbox and Textbox
angel_30
# 4:3 - 16:9 Aspect Ratio Conversion with Pillarbox and Textbox

(Asked by: username_0 on 2018-12-21)

I'm trying to use FFMpeg to adapt 4:3 (SD) to 16:9 (HD) and reverse function. 

When SD is converted to HD, I need to add pillarboxes around the content.
When HD is converted to SD, I need to add textboxes.
Reverse of 1, I need to remove the pillarbox to convert to SD.
Reverse of 2, I need to remove the textbox to convert to HD.

For 1, I already found a solution:
ffmpeg -i input43.mp4 -vf "scale=640x480,setsar=1,pad=854:480:107:0" out43HD.mp4

But what are the commands to do 2, 3, and 4?

**Tags:** video, ffmpeg, video-editor, conversion, aspect


---

## 1 answers

### Answer by username_1 on 2018-12-22. Score: 2 | Accepted answer

A small bit on terminology :- SD and HD refers to resolution - in the basic sense of the word, not dimensions. A given video can be wide or tall or square while being SD or HD. It's the legacy of television broadcast standards that SD content is 4:3 and HD 16:9 but display aspect ratio and visual definition aren't connected. That nitpick aside..
For 4:3 to 16:9 and back.
ffmpeg -i input43.mp4 -vf "scale=iw*sar:ih,setsar=1,pad=ih*16/9:ih:(ow-iw)/2:0" out43in169.mp4

ffmpeg -i out43in169.mp4 -vf "crop=ih*4/3:ih" backto43.mp4

For 16:9 to 4:3 and back.
ffmpeg -i input169.mp4 -vf "scale=iw*sar:ih,setsar=1,pad=iw:iw*3/4:0:(oh-ih)/2" out169in43.mp4

ffmpeg -i out169in43.mp4 -vf "crop=iw:iw*9/16" backto169.mp4

The crop filter automatically crops from the center of the input frame so it's not necessary to specify the x and y offsets. Audio is transcoded, always. Add -c:a copy to avoid that.

> **Comments:**
> **username_0**: Thanks. Video has to be encoded anyways, right? We can not use `-c:v copy`?  
> **username_0**: Btw, does ffmpeg use multi-threading by default? I'm thinking how we can make it run faster. How about running on GPU?!  
> **username_1**: FFmpeg does processing in multiple threads where possible.  
> **username_1**: `-c:v copy` is not possible here.  
> **username_2**: this is ok for 1 shot encoding when you eyeball control your input, in any batch stuff you should cropdetect first (https://www.nab.org/documents/resources/paperTandberg.pdf) and use logic for correct cropping/scaling the area of interest depending on your i/o dar, it can be quite pain in the butt in fact to automate it in a bulletproof way...  

---

