Body: <p>If I have a bunch of clips to merge that are the same frame rate and same dimensions, but <code>ffmpeg</code> barfs when I try to <code>ffmpeg -f concat -i mylist.txt -c copy output.mp4</code> (or any other output format), to what format should I first convert them before attempting a concat?</p>
  
  <p>Let's call such a format the Greatest Common Denominator format into which one can convert all one's videos so that <code>-f concat</code> will work.  </p>
  
  <p>For instance, one would presume that if there are two streams, one at 60fps and the other at 31fps, that there is a command that takes it as an input, without specifying that it is at 31fps, but specifying that the output should be 60fps.  This would re-encode that stream of course.  Then one specifies the same command for the 60fps input stream which, of course, will do nothing (presumably).  The point is that now you have two “intermediate” files that are as they should be for the fps parameter.</p>
  
  <p>Also, presumably, there would be a higher output resolution specification that would capture much if not all the resolution of both streams and, again, only re-encode in the <em>likely</em> event that one or even both need to be so-re-encoded.</p>
  
  <p>We can go down the list of parameters output by <code>ffprobe -i</code> and compile a complete list of output specifications that end up with the Greatest Common Denominator output format that is virtually guaranteed to behave itself when given as input to <code>-f concat</code>.</p>
  
  <p>This is all with full awareness that the re-encoding could take days and an order of magnitude more disk than the original files.</p>
  
  <p><code>ffprobe</code> shows so many moving parts that it's kind of ridiculous to track down each and every one of the possible contributors to concat failures.</p>
  
  <p>It is entirely acceptable to have this process run for hours, so don't be shy about suggesting very generic output formats that get rid of all possible incompatibilities.</p>
  
  <p>PS:  I've tried the supposed free replacements for YouTube's defunct video editor like OpenShot and Shotcut as well as the suggested <code>ffmpeg</code> conversions/merges to/from intermediate formats.  Nothing works.  Indeed, VLC ends up crashing.  There must be some way to just nuke this.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-06-30T18:06:40.607Z
Comments.Text: Codec and codec/bitstream profile* _must_ match. Without these, concat will fail. Other attributes like stream order can be different if working with MPEG-PS/TS inputs. Timebase should match for producing output that plays at correct speed. What does `ffprobe -i` say for the individual inputs?
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-01T19:08:35.147Z
Comments.Text: Well, that's responsive to a different question than the one I asked.  I understand there are a slew of stream parameters that must match.  I also understand there are no utilities that will automatically detect and correct these mismatches (short of paying Adobe for Premiere).  I'm not sure how I can make the question clearer.
Comments.UserDisplayName: James Bowery
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-01T19:19:39.250Z
Comments.Text: I've tried to clarify the question.
Comments.UserDisplayName: James Bowery
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-01T19:39:59.730Z
Comments.Text: ffmpeg won't do conditional transcoding. If you know the set of properties which is acceptable, then you can transcode all clips to those properties. Almost any output format will do, but I would suggest `.mkv` (Matroska) container. H264 codec for video, and `pcm_s16le` for audio. Set a common resolution and pixel format: `-s 1280x720 -pix_fmt yuv420p` and for audio, common channel count and sampling rate `-ar 48000 -ac 2`.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-01T19:42:01.493Z
Comments.Text: Most concat operations don't fail because of the container, although there are a couple of container-level properties which can throw a wrench.
Comments.UserDisplayName: Gyan
Tags: <ffmpeg><formats>
Title: Greatest Common Denominator format for ffmpeg -f concat -i mylist.txt -c copy output.mp4?
UserDisplayName: James Bowery
ThreadText: # Greatest Common Denominator format for ffmpeg -f concat -i mylist.txt -c copy output.mp4?
  
  (Asked by: username_0 on 2019-06-30)
  
  If I have a bunch of clips to merge that are the same frame rate and same dimensions, but `ffmpeg` barfs when I try to `ffmpeg -f concat -i mylist.txt -c copy output.mp4` (or any other output format), to what format should I first convert them before attempting a concat?
  
  Let's call such a format the Greatest Common Denominator format into which one can convert all one's videos so that `-f concat` will work.
  
  For instance, one would presume that if there are two streams, one at 60fps and the other at 31fps, that there is a command that takes it as an input, without specifying that it is at 31fps, but specifying that the output should be 60fps. This would re-encode that stream of course. Then one specifies the same command for the 60fps input stream which, of course, will do nothing (presumably). The point is that now you have two “intermediate” files that are as they should be for the fps parameter.
  
  Also, presumably, there would be a higher output resolution specification that would capture much if not all the resolution of both streams and, again, only re-encode in the *likely* event that one or even both need to be so-re-encoded.
  
  We can go down the list of parameters output by `ffprobe -i` and compile a complete list of output specifications that end up with the Greatest Common Denominator output format that is virtually guaranteed to behave itself when given as input to `-f concat`.
  
  This is all with full awareness that the re-encoding could take days and an order of magnitude more disk than the original files.
  
  `ffprobe` shows so many moving parts that it's kind of ridiculous to track down each and every one of the possible contributors to concat failures.
  
  It is entirely acceptable to have this process run for hours, so don't be shy about suggesting very generic output formats that get rid of all possible incompatibilities.
  
  PS: I've tried the supposed free replacements for YouTube's defunct video editor like OpenShot and Shotcut as well as the suggested `ffmpeg` conversions/merges to/from intermediate formats. Nothing works. Indeed, VLC ends up crashing. There must be some way to just nuke this.
  
  **Tags:** ffmpeg, formats
  
  > **Comments:**
  > **username_1**: Codec and codec/bitstream profile* _must_ match. Without these, concat will fail. Other attributes like stream order can be different if working with MPEG-PS/TS inputs. Timebase should match for producing output that plays at correct speed. What does `ffprobe -i` say for the individual inputs?  
  > **username_0**: Well, that's responsive to a different question than the one I asked.  I understand there are a slew of stream parameters that must match.  I also understand there are no utilities that will automatically detect and correct these mismatches (short of paying Adobe for Premiere).  I'm not sure how I can make the question clearer.  
  > **username_0**: I've tried to clarify the question.  
  > **username_1**: ffmpeg won't do conditional transcoding. If you know the set of properties which is acceptable, then you can transcode all clips to those properties. Almost any output format will do, but I would suggest `.mkv` (Matroska) container. H264 codec for video, and `pcm_s16le` for audio. Set a common resolution and pixel format: `-s 1280x720 -pix_fmt yuv420p` and for audio, common channel count and sampling rate `-ar 48000 -ac 2`.  
  > **username_1**: Most concat operations don't fail because of the container, although there are a couple of container-level properties which can throw a wrench.  
  
  ---
  
  ## 0 answers
  
  