4

I'm using the latest ffmpeg (3.2.4) on 64-bit Windows 10.

My devices generally split up the files it saves to the SD cards, either with a 2G or 4G file size limit.

Before importing the files into my timeline, it would be very convenient to concatenate the logical files back together to one physical file. This way I don't have "parts" that need to be kept together, and applying settings to a clip doesn't require duplicating everything on the continuation segments.

Naturally the codec and container will always be identical, across the pieces.

I first tried the WAV files I got from the Zoom H4N recorder. I tried:

ffmpeg -i "concat:ste-000.wav|ste-001.wav" -c copy Zoom.wav

and the result was just the first part again, with no concatenation. That is, the file was approx. 2GB in size, but not identical to the first part. There was no error message. I didn't think it was strange that the information displayed at the start of the run only showed the first file, as the parts are supposed to be identical in format so it only has to sniff one to find out.

The final lines of output (shown below) shows that the media time is the same as the first part (1:02).

So, I guess it just doesn't work on WAV. The docs I read are quite vague. But there is no error of any kind, either.

Then I tried it with MOV files from the Canon camera.

Again, there was no error, but the result was only the (approximate) size of the first file, which is 4GB in this device. And the time it reported for the output file, about 18 minutes, is that of the first segment only. It did not concatenate them!

So, is there something wrong or out of date with the documentation? Does it not work on Windows for some reason (I would think that being in quotes should prevent the pipe characters from being an issue), because in all cases it just seems to ignore the command after the first file.

I ended up using the concat demuxer instead, which worked just fine but is not as simple since I can’t just name the files on the command line.

Why is the “easy” form not working? More to the point, why is there no error, yet it ignores all but the first file?

[\\OORT\Media\Video-work\2017\April\29 UNT\original]ffmpeg -i "concat:ste-000.wav|ste-001.wav" -c copy Zoom.wav
ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (GCC)
  configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-zlib
  libavutil      55. 34.101 / 55. 34.101
  libavcodec     57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, wav, from 'concat:ste-000.wav|ste-001.wav':
  Metadata:
    encoded_by      : ZOOM Handy Recorder H4n
    date            : 2008-01-01
    creation_time   : 04:46:57
    time_reference  : 1652832000
    coding_history  : A=PCM,F=96000,W=24,M=stereo,T=ZOOM Handy Recorder H4n
  Duration: 01:02:06.51, bitrate: 8696 kb/s
    Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 96000 Hz, stereo, s32 (24 bit), 4608 kb/s
Output #0, wav, to 'Zoom.wav':
  Metadata:
    ITCH            : ZOOM Handy Recorder H4n
    ICRD            : 2008-01-01
    coding_history  : A=PCM,F=96000,W=24,M=stereo,T=ZOOM Handy Recorder H4n
    time_reference  : 1652832000
    ISFT            : Lavf57.56.101
    Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 96000 Hz, stereo (24 bit), 4608 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
size= 2096160kB time=01:02:06.50 bitrate=4608.0kbits/s speed=15.6x
video:0kB audio:2096160kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000007%

[P:\video-out]\\OORT\Media\Video-work\2017\April\29 UNT\original
[\\OORT\Media\Video-work\2017\April\29 UNT\original]ffmpeg -i "concat:MVI_7945.MOV|MVI_7946.MOV" -c copy p:MVI_7945-6.MOV
ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
  built with ⋯
    ⋮
[mov,mp4,m4a,3gp,3g2,mj2 @ 000000000256cae0] Found duplicated MOOV Atom. Skipped it
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'concat:MVI_7945.MOV|MVI_7946.MOV':
  Metadata:
    creation_time   : 2017-04-28T20:08:24.000000Z
    major_brand     : qt
    minor_version   : 537331968
    com.apple.quicktime.make: Canon
    com.apple.quicktime.model: Canon EOS 70D
    com.apple.quicktime.rating.user: 0.000000
    com.apple.quicktime.author: John Dlugosz
    compatible_brands: qt  CAEP
  Duration: 00:18:25.10, start: 0.000000, bitrate: 35549 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 29460 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc (default)
    Metadata:
      creation_time   : 2017-04-28T20:08:24.000000Z
      timecode        : 22:39:33:15
    Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, stereo, s16, 1536 kb/s (default)
    Metadata:
      creation_time   : 2017-04-28T20:08:24.000000Z
      timecode        : 22:39:33:15
    Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
    Metadata:
      creation_time   : 2017-04-28T20:08:24.000000Z
      timecode        : 22:39:33:15
Output #0, mov, to 'p:MVI_7945-6.MOV':
  Metadata:
    compatible_brands: qt  CAEP
    major_brand     : qt
    minor_version   : 537331968
    com.apple.quicktime.make: Canon
    com.apple.quicktime.model: Canon EOS 70D
    com.apple.quicktime.rating.user: 0.000000
    com.apple.quicktime.author: John Dlugosz
    encoder         : Lavf57.56.101
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 29460 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 24k tbc (default)
    Metadata:
      creation_time   : 2017-04-28T20:08:24.000000Z
      timecode        : 22:39:33:15
    Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, stereo, 1536 kb/s (default)
    Metadata:
      creation_time   : 2017-04-28T20:08:24.000000Z
      timecode        : 22:39:33:15
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=26496 fps=519 q=-1.0 Lsize= 4181879kB time=00:18:25.08 bitrate=31000.3kbits/s speed=21.6x
video:3974174kB audio:207207kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.011905%
Improve this question

1 Answer 1

Reset to default
5

The concat protocol is the wrong choice for most file formats. Transport streams like MPEG-TS are one of the few formats which can be concatenated this way. All this method does is a crude appendation of each input to the previous input. So, any format which has a metadata element, can't be concatenated this way as the metadata of the other files will be in the middle of the output file and not referred to, by the metadata at the front of the file.

You should use the concat demuxer instead. Create a text file i.e.

file '/path/to/file1'
file '/path/to/file2'
file '/path/to/file3'

and then

ffmpeg -f concat -safe 0 -i mylist.txt -c copy output
Improve this answer
2
  • Yes, I know how to use that, it's on the same page I linked to.
    – JDługosz
    May 2, 2017 at 15:37
  • 1
    Re-reading the docs, it makes sense after your explaination. It’s strange though that it would have a different effect from “stream copy”, and most worrying that it doesn’t give any error yet apparently knows it cant’t do it, silently changing the command to a useless copy of the first file instead.
    – JDługosz
    May 2, 2017 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.