Answers.Body: <p>Split using <code>-f segment -segment_time 10</code> and end with <code>360a-a%03d.mp4</code>. Then create a text file with one entry on each line like <code>file '360a-a001.mp4</code>, interleaving the entries in the correct order. Then join using <code>-f concat -i text.txt</code> and also with <code>-fflags +genpts -async 1 </code></p>
  <p>The <code>-fflags +genpts -async 1</code> is necessary to ensure that the concatenated audio segments will switch over at the same time as the video segment.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-27T16:42:08.327Z
Answers.Text: `-fflags`, its two "f"s and not one
Answers.UserDisplayName: Abdallah Alsamman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-29T04:41:24.100Z
Answers.Text: For me the -async 1 was the key. I had all the other pieces, but without that things were still getting messed up.
Answers.UserDisplayName: Eric
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2015-04-28T08:02:28.273Z
Answers.LastActivityDate: 2021-03-18T15:55:19.247Z
Answers.LastEditDate: 2021-03-18T15:55:19.247Z
Answers.UserDisplayName: Gyan
Body: <p>I am doing some tests with the FFMPEG concat filter (DASH experiments), and am seeing that I start losing lipsync after a few concatenations.</p>
  
  <p>Is it expected that one can concatenate independent MP4-boxed streams?</p>
  
  <p>This seems curious that loss of sync should happen, as I am doing the following:</p>
  
  <ul>
  <li>Transcoding all sources into the same bitrate, frame rate, GOP size,
     dimensions and codec.</li>
  <li>Using MP4Box to create a set of small N-second
     slices, each being a single GOP.</li>
  <li>Interleaving the slices with the
     concat codec from each asset (v1,slice 1;v2,slice 1;v1,slice2...)</li>
  </ul>
  
  <p>Because I am very careful to precondition all the sources to be "in sync", I would expect that concatenating these files should not cause any audio presentation issues, and should look just like a DASH asset (the actual purpose of this test).</p>
  
  <p>UPDATE: I am starting to wonder if it has something to do with some kind of presentation time stamp not being updated correctly, either on the cut or the reassemble side. It always seems that the audio is cutting before the video, and always for the same amount, regardless of the GOP size (being careful of course to make the GOP size a whole fraction of the overall slice size).</p>
  
  <p>As per Mulvya's request, here are the steps I am performing:</p>
  
  <p>Note that I am purposely setting it to one GOP per slice, on the theory that a GOP size smaller than a segment size might be causing the problem. Didn't seem to be the issue.</p>
  
  <pre><code>ffmpeg -i 360a.mp4 
         -vf scale=640:360,setsar=1/1 -r 30 -b:v 1000k
         -c:v libx264 -x264opts keyint=300:min-keyint=300:scenecut=-1
         -c:a aac -strict -2 
         360a-a.mp4
  </code></pre>
  
  <p>(<em>-strict -2</em>: as you can see, I'm using the stock release built on a Mac, which seems to scream about AAC a lot. Could this be the issue?)
  Note that using the <em>copy</em> codec for audio didn't make a difference.</p>
  
  <pre><code>mp4box -split 10 360a-a.mp4
  
  ffmpeg -i 360b.mp4 
         -vf scale=640:360,setsar=1/1 -r 30 -b:v 1000k
         -c:v libx264 -x264opts keyint=300:min-keyint=300:scenecut=-1
         -c:a aac -strict -2
         360b-a.mp4
  
  mp4box -split 10 360b-a.mp4
  
  mp4box -cat 360a-a_001.mp4 -cat 360b-a_001.mp4
         -cat 360a-a_002.mp4 -cat 360b-a_002.mp4
         ...
         -new output.mp4
  </code></pre>
  
  <p>I also tried two forms of the concat operation:</p>
  
  <pre><code>ffmpeg -f concat -i files-18516 -movflags +faststart  -strict -2 -c:v libx264 -c:a aac/copy abc.mp4
  </code></pre>
  
  <p>And the "complex" version (that word REALLY fits!  :-)  ):</p>
  
  <pre><code>ffmpeg -i 360a_001.mp4 -i 360b_001.mp4 -i 360a_002.mp4 -i 360b_002.mp4 -i 360a_003.mp4 -i 360b_003.mp4 -i 360a_004.mp4 -i 360b_004.mp4 -filter_complex  [0:0] [0:1]  [1:0] [1:1]  [2:0] [2:1]  [3:0] [3:1]  [4:0] [4:1]  [5:0] [5:1]  [6:0] [6:1]  [7:0] [7:1] concat=n=8:v=1:a=1 [v] [a] -map [v] -map [a] -strict -2 -c:v libx264 -c:a aac/copy abc.mp4
  </code></pre>
  
  <p>And here are the input and common output formats as reported by FFMPEG. As you can see, the two files were already pretty similar. The extra step is to handle files with different aspect ratios, etc. Note that the video might get stretched...the point here is to test audio issues, not really the video, so I didn't bother padding.</p>
  
  <p>File 360a.mp4:</p>
  
  <pre><code>Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '360a.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
      encoder         : Lavf55.50.100
    Duration: 00:00:30.53, start: 0.033333, bitrate: 1169 kb/s
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 640x360, 1033 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
      Metadata:
        handler_name    : VideoHandler
      Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 125 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
  </code></pre>
  
  <p>File 360b.mp4:</p>
  
  <pre><code>Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '360b.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
      encoder         : Lavf55.50.100
    Duration: 00:00:31.43, start: 0.033333, bitrate: 1120 kb/s
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 640x360, 981 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
      Metadata:
        handler_name    : VideoHandler
      Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
  </code></pre>
  
  <p>Common Output Format:</p>
  
  <pre><code>Output #0, mp4, to '360a/b-a.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
      encoder         : Lavf55.48.100
      Stream #0:0(und): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 640x360 [SAR 1:1 DAR 16:9], q=-1--1, 1000 kb/s, 30 fps, 15360 tbn, 30 tbc (default)
      Metadata:
        handler_name    : VideoHandler
        encoder         : Lavc55.69.100 libx264
      Stream #0:1(und): Audio: aac ([64][0][0][0] / 0x0040), 48000 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        encoder         : Lavc55.69.100 aac
  Stream mapping:
    Stream #0:0 -&gt; #0:0 (h264 (native) -&gt; h264 (libx264))
    Stream #0:1 -&gt; #0:1 (aac (native) -&gt; aac (native))
  </code></pre>
  
  <p>Each slice looks essentially like:</p>
  
  <pre><code>Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '360a-a_001.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 1
      compatible_brands: isom
      creation_time   : 2015-04-26 19:23:40
    Duration: 00:00:10.00, start: 0.000000, bitrate: 1183 kb/s
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 1046 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
      Metadata:
        handler_name    : VideoHandler
      Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 129 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-25T15:26:33.647Z
Comments.Text: Can you post the commands you used? Both MP4Box and ffmpeg.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-26T20:00:53.030Z
Comments.Text: @Mulvya : done.
Comments.UserDisplayName: Mark Gerolimatos
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-26T20:54:56.657Z
Comments.Text: encoder settings: You shouldn't need to mess with `scenecut`.  If x264 wants to insert a non-IDR I frame to compress better, let it.  Your `min-keyint` setting will make sure any extra I frames are not IDR (keyframes).  IDK if this will help compression any on scenecuts, but it shouldn't hurt.  And should have no bearing on your a/v sync issue.  Audio: ffmpeg's built-in `aac` encoder is significantly worse than `libfdk_aac`.  If you find you need to xcode your audio, use that.  Preferably don't xcode the audio at all.  (`-c:a copy`), once you get your a/v sync sorted.
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-26T20:55:32.423Z
Comments.Text: Is a/v in sync in the split files, before remuxing them into a merged video?  e.g. if you just play one of the 10-sec files with your player of choice.
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-26T21:06:36.930Z
Comments.Text: Also, try with `x264opts=stitchable=1`; that might or might not be needed.  Looking in the code, the option is only checked in one place, to set `h->pps->i_pic_init_qp` in `x264_ratecontrol_new()`, whatever that means. :P  I would guess that this would be a "plays or not" issue, rather than just leading to a desync, unless the player's error-handling or invalid streams is leading to desync.  But really I don't know.
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T05:34:25.180Z
Comments.Text: Why use mp4box to split and concat? ffmpeg offers segment and concat options as well. Split using "-f segment -segment_time 10" and end with "360a-a%03d.mp4". Then create a text file with one entry on each line like "file '360a-a001.mp4", interleaving the entries in the correct order. Then join using -f concat -i text.txt  and also with -flags +genpts -async 1
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T16:51:08.307Z
Comments.Text: @PeterCordes : To answer your excellent questions, the keyint settings are for when one uses DASH. For adaptive encoding, one must have fixed GOP sizes. At least that's the current party line in the not-too-well-specified DASH world. As for -c:a copy, that was my original implementation...it made no difference. By the way, how do you get "code inserts" in the middle of a line?
Comments.UserDisplayName: Mark Gerolimatos
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T16:51:42.410Z
Comments.Text: @PeterCordes question 2: yes, the A/V sync seems fine in each 10-second segment.
Comments.UserDisplayName: Mark Gerolimatos
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T16:56:13.553Z
Comments.Text: @Mulvya Question 1: As for using MP4Box, I was originally just using the FFMPEG split and concat filters. I apologize for giving the MP4Box concat form, up until the very end, I was using the concat filter (the question specifies concat!). I will post a version using that. As for using MP4BOX split, the "word out on the street" in the DASH world is to use MP4BOX for splitting, as it "apparently" is "DASH aware". Remember, these are DASH tests I am doing...the loss of A/V sync on concat was an accidental discovery.
Comments.UserDisplayName: Mark Gerolimatos
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T17:14:56.360Z
Comments.Text: @Mulvya  GENPTS WAS THE ANSWER! Thank you so very much. Frankly, I would have expected PTS to be generated by default (if you are in the FFMPEG group, please consider doing that), but so be it :-)  . If you please state your comment as an answer, I will choose it and give you some game points :-)
Comments.UserDisplayName: Mark Gerolimatos
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T17:39:42.340Z
Comments.Text: @Mulvya Since PTS is not generated by default, when should I be generating it, and when should I not? I would assume that PTS calculation would slow down encoding, so if it can be avoided I would prefer to do that. But in a DASH world, where is PTS generation necessary for proper operation? Even though DASH has nothing to do with reassembly, there WILL be scenarios where I am concatenating in a DASH environment (such as producing a single asset for non-DASH complient players).
Comments.UserDisplayName: Mark Gerolimatos
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T17:43:39.210Z
Comments.Text: @Mulvya Regarding your comment about libfdk_aac, I see that none of my FFMPEG builds support it. Can I dynamically add an encoder without rebuilding? I am currently using it in a server-side environment, and am loathe to rebuild a tool in live use.
Comments.UserDisplayName: Mark Gerolimatos
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T18:40:08.207Z
Comments.Text: code inserts: backticks.  see the markup guide.  re: genpts.  Calculating fresh timestamps is a couple adds / multiplies per frame.  x264 does more work than that per PIXEL.  I'd expect it's literally impossible to measure the performance impact of genpts.
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T18:45:33.043Z
Comments.Text: re: fixed GOP.  Yes, you want each segment to be a single GOP.  Non-IDR I frames aren't GOP boundaries.  Prediction / references / etc. can cross I frames if they aren't IDR frames.  I was suggesting you keep your `keyint:min_keyint` settings, but drop your `scenecut` setting.  IDK if x264 will do any better without it, but it shouldn't do worse.
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-27T18:49:38.493Z
Comments.Text: re: libfdk_aac: If `genpts` fixes your sync problems even with `-c:a copy`, then use that.  Otherwise, make a test-build of ffmpeg, or get a static binary.  Make sure it works well, THEN replace the server's `/usr/local/bin/ffmpeg`.  If you are xcoding audio, `libfdk_aac` is the only decent AAC encoder for ffmpeg.  See http://www.hydrogenaud.io/forums/index.php?showtopic=102699 for a fairly recent listening test someone did, comparing fdk_aac against ffmpeg's native encoder.  "Significant and big quality advantage"...
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-28T08:06:05.057Z
Comments.Text: Glad it worked out. Added answer. I'm not a coder or part of ffmpeg. I also don't work that much with streaming media, but in my video editing work, I use ffmpeg fairly regularly for conversions and other sundry work, so I've encountered these common issues before.
Comments.UserDisplayName: Gyan
Tags: <ffmpeg><filter>
Title: FFMPEG: Why does the concat filter cause loss of a/v sync/lipsync?
UserDisplayName: Mark Gerolimatos
ThreadText: # FFMPEG: Why does the concat filter cause loss of a/v sync/lipsync?
  
  (Asked by: username_0 on 2015-04-24)
  
  I am doing some tests with the FFMPEG concat filter (DASH experiments), and am seeing that I start losing lipsync after a few concatenations.
  
  Is it expected that one can concatenate independent MP4-boxed streams?
  
  This seems curious that loss of sync should happen, as I am doing the following:
  
  * Transcoding all sources into the same bitrate, frame rate, GOP size,
    dimensions and codec.
  * Using MP4Box to create a set of small N-second
    slices, each being a single GOP.
  * Interleaving the slices with the
    concat codec from each asset (v1,slice 1;v2,slice 1;v1,slice2...)
  
  Because I am very careful to precondition all the sources to be "in sync", I would expect that concatenating these files should not cause any audio presentation issues, and should look just like a DASH asset (the actual purpose of this test).
  
  UPDATE: I am starting to wonder if it has something to do with some kind of presentation time stamp not being updated correctly, either on the cut or the reassemble side. It always seems that the audio is cutting before the video, and always for the same amount, regardless of the GOP size (being careful of course to make the GOP size a whole fraction of the overall slice size).
  
  As per Mulvya's request, here are the steps I am performing:
  
  Note that I am purposely setting it to one GOP per slice, on the theory that a GOP size smaller than a segment size might be causing the problem. Didn't seem to be the issue.
  
  ```
  ffmpeg -i 360a.mp4 
         -vf scale=640:360,setsar=1/1 -r 30 -b:v 1000k
         -c:v libx264 -x264opts keyint=300:min-keyint=300:scenecut=-1
         -c:a aac -strict -2 
         360a-a.mp4
  
  ```
  
  (*-strict -2*: as you can see, I'm using the stock release built on a Mac, which seems to scream about AAC a lot. Could this be the issue?)
  Note that using the *copy* codec for audio didn't make a difference.
  
  ```
  mp4box -split 10 360a-a.mp4
  
  ffmpeg -i 360b.mp4 
         -vf scale=640:360,setsar=1/1 -r 30 -b:v 1000k
         -c:v libx264 -x264opts keyint=300:min-keyint=300:scenecut=-1
         -c:a aac -strict -2
         360b-a.mp4
  
  mp4box -split 10 360b-a.mp4
  
  mp4box -cat 360a-a_001.mp4 -cat 360b-a_001.mp4
         -cat 360a-a_002.mp4 -cat 360b-a_002.mp4
         ...
         -new output.mp4
  
  ```
  
  I also tried two forms of the concat operation:
  
  ```
  ffmpeg -f concat -i files-18516 -movflags +faststart  -strict -2 -c:v libx264 -c:a aac/copy abc.mp4
  
  ```
  
  And the "complex" version (that word REALLY fits! :-) ):
  
  ```
  ffmpeg -i 360a_001.mp4 -i 360b_001.mp4 -i 360a_002.mp4 -i 360b_002.mp4 -i 360a_003.mp4 -i 360b_003.mp4 -i 360a_004.mp4 -i 360b_004.mp4 -filter_complex  [0:0] [0:1]  [1:0] [1:1]  [2:0] [2:1]  [3:0] [3:1]  [4:0] [4:1]  [5:0] [5:1]  [6:0] [6:1]  [7:0] [7:1] concat=n=8:v=1:a=1 [v] [a] -map [v] -map [a] -strict -2 -c:v libx264 -c:a aac/copy abc.mp4
  
  ```
  
  And here are the input and common output formats as reported by FFMPEG. As you can see, the two files were already pretty similar. The extra step is to handle files with different aspect ratios, etc. Note that the video might get stretched...the point here is to test audio issues, not really the video, so I didn't bother padding.
  
  File 360a.mp4:
  
  ```
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '360a.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
      encoder         : Lavf55.50.100
    Duration: 00:00:30.53, start: 0.033333, bitrate: 1169 kb/s
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 640x360, 1033 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
      Metadata:
        handler_name    : VideoHandler
      Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 125 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
  
  ```
  
  File 360b.mp4:
  
  ```
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '360b.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
      encoder         : Lavf55.50.100
    Duration: 00:00:31.43, start: 0.033333, bitrate: 1120 kb/s
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 640x360, 981 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
      Metadata:
        handler_name    : VideoHandler
      Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
  
  ```
  
  Common Output Format:
  
  ```
  Output #0, mp4, to '360a/b-a.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
      encoder         : Lavf55.48.100
      Stream #0:0(und): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 640x360 [SAR 1:1 DAR 16:9], q=-1--1, 1000 kb/s, 30 fps, 15360 tbn, 30 tbc (default)
      Metadata:
        handler_name    : VideoHandler
        encoder         : Lavc55.69.100 libx264
      Stream #0:1(und): Audio: aac ([64][0][0][0] / 0x0040), 48000 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        encoder         : Lavc55.69.100 aac
  Stream mapping:
    Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
    Stream #0:1 -> #0:1 (aac (native) -> aac (native))
  
  ```
  
  Each slice looks essentially like:
  
  ```
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '360a-a_001.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 1
      compatible_brands: isom
      creation_time   : 2015-04-26 19:23:40
    Duration: 00:00:10.00, start: 0.000000, bitrate: 1183 kb/s
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 1046 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
      Metadata:
        handler_name    : VideoHandler
      Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 129 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
  
  ```
  
  **Tags:** ffmpeg, filter
  
  > **Comments:**
  > **username_1**: Can you post the commands you used? Both MP4Box and ffmpeg.  
  > **username_0**: @Mulvya : done.  
  > **username_2**: encoder settings: You shouldn't need to mess with `scenecut`.  If x264 wants to insert a non-IDR I frame to compress better, let it.  Your `min-keyint` setting will make sure any extra I frames are not IDR (keyframes).  IDK if this will help compression any on scenecuts, but it shouldn't hurt.  And should have no bearing on your a/v sync issue.  Audio: ffmpeg's built-in `aac` encoder is significantly worse than `libfdk_aac`.  If you find you need to xcode your audio, use that.  Preferably don't xcode the audio at all.  (`-c:a copy`), once you get your a/v sync sorted.  
  > **username_2**: Is a/v in sync in the split files, before remuxing them into a merged video?  e.g. if you just play one of the 10-sec files with your player of choice.  
  > **username_2**: Also, try with `x264opts=stitchable=1`; that might or might not be needed.  Looking in the code, the option is only checked in one place, to set `h->pps->i_pic_init_qp` in `x264_ratecontrol_new()`, whatever that means. :P  I would guess that this would be a "plays or not" issue, rather than just leading to a desync, unless the player's error-handling or invalid streams is leading to desync.  But really I don't know.  
  > **username_1**: Why use mp4box to split and concat? ffmpeg offers segment and concat options as well. Split using "-f segment -segment_time 10" and end with "360a-a%03d.mp4". Then create a text file with one entry on each line like "file '360a-a001.mp4", interleaving the entries in the correct order. Then join using -f concat -i text.txt  and also with -flags +genpts -async 1  
  > **username_0**: @username_2 : To answer your excellent questions, the keyint settings are for when one uses DASH. For adaptive encoding, one must have fixed GOP sizes. At least that's the current party line in the not-too-well-specified DASH world. As for -c:a copy, that was my original implementation...it made no difference. By the way, how do you get "code inserts" in the middle of a line?  
  > **username_0**: @username_2 question 2: yes, the A/V sync seems fine in each 10-second segment.  
  > **username_0**: @Mulvya Question 1: As for using MP4Box, I was originally just using the FFMPEG split and concat filters. I apologize for giving the MP4Box concat form, up until the very end, I was using the concat filter (the question specifies concat!). I will post a version using that. As for using MP4BOX split, the "word out on the street" in the DASH world is to use MP4BOX for splitting, as it "apparently" is "DASH aware". Remember, these are DASH tests I am doing...the loss of A/V sync on concat was an accidental discovery.  
  > **username_0**: @Mulvya  GENPTS WAS THE ANSWER! Thank you so very much. Frankly, I would have expected PTS to be generated by default (if you are in the FFMPEG group, please consider doing that), but so be it :-)  . If you please state your comment as an answer, I will choose it and give you some game points :-)  
  > **username_0**: @Mulvya Since PTS is not generated by default, when should I be generating it, and when should I not? I would assume that PTS calculation would slow down encoding, so if it can be avoided I would prefer to do that. But in a DASH world, where is PTS generation necessary for proper operation? Even though DASH has nothing to do with reassembly, there WILL be scenarios where I am concatenating in a DASH environment (such as producing a single asset for non-DASH complient players).  
  > **username_0**: @Mulvya Regarding your comment about libfdk_aac, I see that none of my FFMPEG builds support it. Can I dynamically add an encoder without rebuilding? I am currently using it in a server-side environment, and am loathe to rebuild a tool in live use.  
  > **username_2**: code inserts: backticks.  see the markup guide.  re: genpts.  Calculating fresh timestamps is a couple adds / multiplies per frame.  x264 does more work than that per PIXEL.  I'd expect it's literally impossible to measure the performance impact of genpts.  
  > **username_2**: re: fixed GOP.  Yes, you want each segment to be a single GOP.  Non-IDR I frames aren't GOP boundaries.  Prediction / references / etc. can cross I frames if they aren't IDR frames.  I was suggesting you keep your `keyint:min_keyint` settings, but drop your `scenecut` setting.  IDK if x264 will do any better without it, but it shouldn't do worse.  
  > **username_2**: re: libfdk_aac: If `genpts` fixes your sync problems even with `-c:a copy`, then use that.  Otherwise, make a test-build of ffmpeg, or get a static binary.  Make sure it works well, THEN replace the server's `/usr/local/bin/ffmpeg`.  If you are xcoding audio, `libfdk_aac` is the only decent AAC encoder for ffmpeg.  See http://www.hydrogenaud.io/forums/index.php?showtopic=102699 for a fairly recent listening test someone did, comparing fdk_aac against ffmpeg's native encoder.  "Significant and big quality advantage"...  
  > **username_1**: Glad it worked out. Added answer. I'm not a coder or part of ffmpeg. I also don't work that much with streaming media, but in my video editing work, I use ffmpeg fairly regularly for conversions and other sundry work, so I've encountered these common issues before.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-04-28. Score: 4
  
  Split using `-f segment -segment_time 10` and end with `360a-a%03d.mp4`. Then create a text file with one entry on each line like `file '360a-a001.mp4`, interleaving the entries in the correct order. Then join using `-f concat -i text.txt` and also with `-fflags +genpts -async 1`
  
  The `-fflags +genpts -async 1` is necessary to ensure that the concatenated audio segments will switch over at the same time as the video segment.
  
  > **Comments:**
  > **username_3**: `-fflags`, its two "f"s and not one  
  > **username_4**: For me the -async 1 was the key. I had all the other pieces, but without that things were still getting messed up.  
  
  ---
  
  