<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>

CC BY-SA 3.0
2017-02-27T16:42:08.327Z
`-fflags`, its two "f"s and not one
Abdallah Alsamman
CC BY-SA 3.0
2017-09-29T04:41:24.100Z
For me the -async 1 was the key. I had all the other pieces, but without that things were still getting messed up.
Eric
CC BY-SA 4.0
2015-04-28T08:02:28.273Z
2021-03-18T15:55:19.247Z
2021-03-18T15:55:19.247Z
Gyan
<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>

CC BY-SA 3.0
2015-04-25T15:26:33.647Z
Can you post the commands you used? Both MP4Box and ffmpeg.
Gyan
CC BY-SA 3.0
2015-04-26T20:00:53.030Z
@Mulvya : done.
Mark Gerolimatos
CC BY-SA 3.0
2015-04-26T20:54:56.657Z
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.
Peter Cordes
CC BY-SA 3.0
2015-04-26T20:55:32.423Z
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.
Peter Cordes
CC BY-SA 3.0
2015-04-26T21:06:36.930Z
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.
Peter Cordes
CC BY-SA 3.0
2015-04-27T05:34:25.180Z
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
Gyan
CC BY-SA 3.0
2015-04-27T16:51:08.307Z
@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?
Mark Gerolimatos
CC BY-SA 3.0
2015-04-27T16:51:42.410Z
@PeterCordes question 2: yes, the A/V sync seems fine in each 10-second segment.
Mark Gerolimatos
CC BY-SA 3.0
2015-04-27T16:56:13.553Z
@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.
Mark Gerolimatos
CC BY-SA 3.0
2015-04-27T17:14:56.360Z
@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 :-)
Mark Gerolimatos
CC BY-SA 3.0
2015-04-27T17:39:42.340Z
@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).
Mark Gerolimatos
CC BY-SA 3.0
2015-04-27T17:43:39.210Z
@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.
Mark Gerolimatos
CC BY-SA 3.0
2015-04-27T18:40:08.207Z
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.
Peter Cordes
CC BY-SA 3.0
2015-04-27T18:45:33.043Z
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.
Peter Cordes
CC BY-SA 3.0
2015-04-27T18:49:38.493Z
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"...
Peter Cordes
CC BY-SA 3.0
2015-04-28T08:06:05.057Z
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.
Gyan
<ffmpeg><filter>
FFMPEG: Why does the concat filter cause loss of a/v sync/lipsync?
Mark Gerolimatos
# 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**: @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?  
> **username_0**: @PeterCordes 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.  

---

