<p>Quality-wise, it's better to use the original MOVs, but if the MP4-based stacking looks ok, that's the final arbiter.</p>

<pre><code>ffmpeg -i left.mov -i centre.mov -i right.mov 
-filter_complex "[0:v:0][1:v:0][2:v:0]hstack=inputs=3"
-c:v libx264 -tune film -crf 16 -b:a 256k triple.mp4
</code></pre>

<p>When using the originals, it doesn't matter whether you do it in one step or two. For streamlining purposes, I would do it in two - then the two encodes aren't competing for memory or CPU.</p>

<ol>
<li><p>The <code>stack</code> filters are somewhat more efficient. They require all inputs to have the same size in the dimension normal to the join direction i.e. same height for hstack. Overlay is a generic filter, so it doesn't. Also, stack filters will freeze on the first and last frame of inputs which start late or finish early.</p></li>
<li><p>In digital files, audio and video are independent i.e. they exist within the same file and are synced via timestamps but logically they are distinct entities. ffmpeg relies on -map options to select streams for inclusion in the output. In the absence of any -map option, it picks one audio - the "best" - from among all the inputs. See <a href="https://ffmpeg.org/ffmpeg.html#Stream-selection" rel="nofollow noreferrer">https://ffmpeg.org/ffmpeg.html#Stream-selection</a></p></li>
<li><p><code>[1:v:0]</code> ... "<em>means 'second input, first video track only'?</em>"  --> Yes.</p></li>
<li><p>Looks fine. The suitability of the <code>tune</code> value depends on the material.</p></li>
</ol>

CC BY-SA 3.0
2018-01-11T08:44:50.193Z
Great, thanks! I've just done this in two steps, making .mp4 files and then using `hstack` on them to make a triple-width .mp4. I'm surprised to see the file size is _smaller_ for the triple-width file than any individual .mp4 file! Bitrate Viewer shows me the triple-width file has significantly lower bitrate (avg 12Mbps instead of 18Mbps) despite having three times the width. Is it re-encoding using some defaults and I need to use some arguments to control the quality level of that re-encoding?
Rory
CC BY-SA 3.0
2018-01-11T09:14:34.330Z
Just to be clear: did you use MP4 or MOVs as source for the stacking?
Gyan
CC BY-SA 3.0
2018-01-11T09:16:22.737Z
I used the .mp4s. Will do it with the .mov files instead.
Rory
CC BY-SA 3.0
2018-01-11T10:52:23.843Z
Small follow-up: if I've decided `-crf 16` provides suitable quality for my individual 1920x1080 .mp4 files, should I keep using that for creating my stacked widescreen .mp4 or do I need to lower that value to get the same quality in a 5760x1080 file?
Rory
CC BY-SA 3.0
2018-01-11T11:28:55.230Z
The higher the resolution, the more relaxed CRF can be (upto a point), but it sounds like you're getting the opposite result. Don't look at the file size, do a subjective check.
Gyan
CC BY-SA 3.0
2018-01-11T05:20:23.453Z
2018-01-11T05:59:15.913Z
2018-01-11T05:59:15.913Z
Gyan
<p>I have three .mov files with video in Apple ProRes (apcn) and audio in PCM S24 LE (in24), of identical length and dimensions (1920x1080), frame rate (23.976024) and each with the same audio track. I'd like to: </p>

<ul>
<li><p>convert to H.264 video and AAC audio, retaining very good quality (for public exhibition), and </p></li>
<li><p>generate a single widescreen video in H.264/AAC, i.e. it'll be 1920px times 3 wide and 1080px high. </p></li>
</ul>

<p>For generating the widescreen I've worked out I can use this command assuming I've prepared the individual mp4 files: </p>

<pre><code>ffmpeg -i left.mp4 -i centre.mp4 -i right.mp4 
   -filter_complex "[0:v:0][1:v:0][2:v:0]hstack=inputs=3" triple.mp4
</code></pre>

<p><strong>Main Question:</strong> </p>

<p>Should I do the process in two steps -- (a) convert files, (b) make widescreen file -- or does that mean the widescreen video is re-encoded therefore it's worse quality? I'd like to keep the separate files so if there's no other impact then I'd prefer to do it as two steps. If I should do the conversion to H.264 at the same time as making the widescreen how do I combine the different commands? </p>

<p><strong>Sub-Questions:</strong> </p>

<ol>
<li><p>When preparing the widescreen I came across an alternative method using <code>overlay</code> like below. Is there any advantage either way? It seems like the <code>overlay</code> should be slower but in testing seemed about the same.</p>

<p><code>ffmpeg -i left.mp4 -i centre.mp4 -i right.mp4 -filter_complex "[0:v:0]pad=iw*3:ih[bg]; [bg][1:v:0]overlay=w[leftcentre]; [leftcentre][2:v:0]overlay=w*2" triple.mp4</code></p></li>
<li><p>When preparing the widescreen, I <em>think</em> ffmpeg chooses the audio from just one of the input files. Since the audio is the same on each it doesn't matter to me which one. Is that right or is it in some way combining them? </p></li>
<li><p>Am I right in thinking a term like <code>[1:v:0]</code> in the <code>filter_complex</code> expression means 'second input, first video track only'?</p></li>
<li><p>Here's my command to convert the .mov files, which seems to work as desired. Is there anything obviously wrong with it? </p>

<p><code>ffmpeg -i left.mov -c:v libx264 -preset medium -tune film -crf 16 -c:a aac -b:a 256k left.mp4</code></p></li>
</ol>

CC BY-SA 4.0
2019-10-09T01:15:00.793Z
May I ask how is your project going? I'm planing to do the same but I don't know if what I want to do will work. I am planing to use two osmo pocket and clicked record same time and one on the left and one on the right recording at the same time. I think it's pretty similar to yours of having a wider view. May I ask if yiu have a sample of yours or how did yours turn out? Thank you so much and I hope to hear from everyone
Pham Don
CC BY-SA 4.0
2019-10-10T07:57:02.200Z
Hi! The project worked well, I used the ffmpeg commands something like that above to make a single widescreen movie file. I used this to play it split across three projectors using a Matrox TripleHead2Go.
Rory
CC BY-SA 4.0
2019-10-10T08:00:37.153Z
fwiw this is the command I ended up using (I think): `ffmpeg -i 1920_LEFT.mov -i 1920_CENTRE.mov -i 1920_RIGHT.mov -filter_complex "[0:v:0][1:v:0][2:v:0]hstack=inputs=3" -c:v libx264 -tune film -crf 16 -b:a 256k myOutputFile.mp4`
Rory
CC BY-SA 4.0
2019-10-10T08:22:40.980Z
fyi my source wasn't multiple camera recordings but rather several hours of recordings from one camera which had been edited into a multi-screen artwork that was to be projected using three projectors simultaneously. I was joining the three videos into a single widescreen one to ensure they were synchronised exactly when playing, since they'd be playing continuously for days in a gallery environment with nobody to check the sync. Hence we used a Matrox TripleHead2Go to split the widescreen video into three separate but synchronised outputs for the projectors. There was just one audio stream.
Rory
CC BY-SA 4.0
2019-10-10T22:50:38.213Z
This does not really answer the question. If you have a different question, you can ask it by clicking [Ask Question](https://video.stackexchange.com/questions/ask). You can also [add a bounty](https://video.stackexchange.com/help/privileges/set-bounties) to draw more attention to this question once you have enough [reputation](https://video.stackexchange.com/help/whats-reputation). - [From Review](/review/low-quality-posts/15697)
Michael Liebman
<video><ffmpeg><conversion>
ffmpeg to convert and merge 3 videos to a single widescreen video
Rory
# ffmpeg to convert and merge 3 videos to a single widescreen video

(Asked by: username_0 on 2018-01-11)

I have three .mov files with video in Apple ProRes (apcn) and audio in PCM S24 LE (in24), of identical length and dimensions (1920x1080), frame rate (23.976024) and each with the same audio track. I'd like to: 

convert to H.264 video and AAC audio, retaining very good quality (for public exhibition), and 
generate a single widescreen video in H.264/AAC, i.e. it'll be 1920px times 3 wide and 1080px high. 

For generating the widescreen I've worked out I can use this command assuming I've prepared the individual mp4 files: 
ffmpeg -i left.mp4 -i centre.mp4 -i right.mp4 
   -filter_complex "[0:v:0][1:v:0][2:v:0]hstack=inputs=3" triple.mp4

Main Question: 
Should I do the process in two steps -- (a) convert files, (b) make widescreen file -- or does that mean the widescreen video is re-encoded therefore it's worse quality? I'd like to keep the separate files so if there's no other impact then I'd prefer to do it as two steps. If I should do the conversion to H.264 at the same time as making the widescreen how do I combine the different commands? 
Sub-Questions: 

When preparing the widescreen I came across an alternative method using overlay like below. Is there any advantage either way? It seems like the overlay should be slower but in testing seemed about the same.
ffmpeg -i left.mp4 -i centre.mp4 -i right.mp4 -filter_complex "[0:v:0]pad=iw*3:ih[bg]; [bg][1:v:0]overlay=w[leftcentre]; [leftcentre][2:v:0]overlay=w*2" triple.mp4
When preparing the widescreen, I think ffmpeg chooses the audio from just one of the input files. Since the audio is the same on each it doesn't matter to me which one. Is that right or is it in some way combining them? 
Am I right in thinking a term like [1:v:0] in the filter_complex expression means 'second input, first video track only'?
Here's my command to convert the .mov files, which seems to work as desired. Is there anything obviously wrong with it? 
ffmpeg -i left.mov -c:v libx264 -preset medium -tune film -crf 16 -c:a aac -b:a 256k left.mp4

**Tags:** video, ffmpeg, conversion

> **Comments:**
> **username_1**: May I ask how is your project going? I'm planing to do the same but I don't know if what I want to do will work. I am planing to use two osmo pocket and clicked record same time and one on the left and one on the right recording at the same time. I think it's pretty similar to yours of having a wider view. May I ask if yiu have a sample of yours or how did yours turn out? Thank you so much and I hope to hear from everyone  
> **username_0**: Hi! The project worked well, I used the ffmpeg commands something like that above to make a single widescreen movie file. I used this to play it split across three projectors using a Matrox TripleHead2Go.  
> **username_0**: fwiw this is the command I ended up using (I think): `ffmpeg -i 1920_LEFT.mov -i 1920_CENTRE.mov -i 1920_RIGHT.mov -filter_complex "[0:v:0][1:v:0][2:v:0]hstack=inputs=3" -c:v libx264 -tune film -crf 16 -b:a 256k myOutputFile.mp4`  
> **username_0**: fyi my source wasn't multiple camera recordings but rather several hours of recordings from one camera which had been edited into a multi-screen artwork that was to be projected using three projectors simultaneously. I was joining the three videos into a single widescreen one to ensure they were synchronised exactly when playing, since they'd be playing continuously for days in a gallery environment with nobody to check the sync. Hence we used a Matrox TripleHead2Go to split the widescreen video into three separate but synchronised outputs for the projectors. There was just one audio stream.  
> **username_2**: This does not really answer the question. If you have a different question, you can ask it by clicking [Ask Question](https://video.stackexchange.com/questions/ask). You can also [add a bounty](https://video.stackexchange.com/help/privileges/set-bounties) to draw more attention to this question once you have enough [reputation](https://video.stackexchange.com/help/whats-reputation). - [From Review](/review/low-quality-posts/15697)  

---

## 1 answers

### Answer by username_3 on 2018-01-11. Score: 4 | Accepted answer

Quality-wise, it's better to use the original MOVs, but if the MP4-based stacking looks ok, that's the final arbiter.
ffmpeg -i left.mov -i centre.mov -i right.mov 
-filter_complex "[0:v:0][1:v:0][2:v:0]hstack=inputs=3"
-c:v libx264 -tune film -crf 16 -b:a 256k triple.mp4

When using the originals, it doesn't matter whether you do it in one step or two. For streamlining purposes, I would do it in two - then the two encodes aren't competing for memory or CPU.

The stack filters are somewhat more efficient. They require all inputs to have the same size in the dimension normal to the join direction i.e. same height for hstack. Overlay is a generic filter, so it doesn't. Also, stack filters will freeze on the first and last frame of inputs which start late or finish early.
In digital files, audio and video are independent i.e. they exist within the same file and are synced via timestamps but logically they are distinct entities. ffmpeg relies on -map options to select streams for inclusion in the output. In the absence of any -map option, it picks one audio - the "best" - from among all the inputs. See https://ffmpeg.org/ffmpeg.html#Stream-selection
[1:v:0] ... "means 'second input, first video track only'?"  --> Yes.
Looks fine. The suitability of the tune value depends on the material.

> **Comments:**
> **username_0**: Great, thanks! I've just done this in two steps, making .mp4 files and then using `hstack` on them to make a triple-width .mp4. I'm surprised to see the file size is _smaller_ for the triple-width file than any individual .mp4 file! Bitrate Viewer shows me the triple-width file has significantly lower bitrate (avg 12Mbps instead of 18Mbps) despite having three times the width. Is it re-encoding using some defaults and I need to use some arguments to control the quality level of that re-encoding?  
> **username_3**: Just to be clear: did you use MP4 or MOVs as source for the stacking?  
> **username_0**: I used the .mp4s. Will do it with the .mov files instead.  
> **username_0**: Small follow-up: if I've decided `-crf 16` provides suitable quality for my individual 1920x1080 .mp4 files, should I keep using that for creating my stacked widescreen .mp4 or do I need to lower that value to get the same quality in a 5760x1080 file?  
> **username_3**: The higher the resolution, the more relaxed CRF can be (upto a point), but it sounds like you're getting the opposite result. Don't look at the file size, do a subjective check.  

---

