ffmpeg concat不适用于绝对路径

我需要将concat与绝对路径一起使用，但这似乎不起作用。在文档中，它说应该起作用。任何人都知道如何使其工作吗？ ffmpeg文件

它不起作用，因为它似乎将文本文件目录附加到文件路径

Impossible to open 'C:/temp/ffmpeg/c:/temp/ffmpeg/01.mov'

我使用Windows 7。

ffmpegTest.txt:
file 'c:/temp/ffmpeg/01.mov'
file 'c:/temp/ffmpeg/02.mov'

"Y:/Shotgun/bin/ffmpeg/bin/ffmpeg.exe" -f concat -i "C:/temp/ffmpeg/ffmpegTest.txt" -c copy "C:/temp/ffmpeg/test.mov
ffmpeg version N-58949-g0e575c2 Copyright (c) 2000-2013 the FFmpeg developers
  built on Dec  9 2013 22:06:49 with gcc 4.8.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      52. 58.100 / 52. 58.100
  libavcodec     55. 45.100 / 55. 45.100
  libavformat    55. 22.100 / 55. 22.100
  libavdevice    55.  5.102 / 55.  5.102
  libavfilter     3. 92.100 /  3. 92.100
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
[concat @ 0000000000337920] Impossible to open 'C:/temp/ffmpeg/c:/temp/ffmpeg/01.mov'
C:/temp/ffmpeg/ffmpegTest.txt: Invalid argument

我只是遇到类似的错误消息。我最终想通了。有两个问题。

问题1：

做的时候

ffmpeg -f concat -i <path_to_text_file> ...

在path_to_text_file必须使用正斜杠，而不是反斜杠，即使是在Windows中。但是，此规则似乎不适用于命令行上的视频文件路径-仅适用于命令行上的文本文件路径。

问题2：

ffmpeg将文本文件中列出的路径解释为相对于文本文件位置的路径。（特别是，列出的路径不是相对于当前工作目录的。）

因此，例如，如果您要连接在一起的视频文件与文本文件位于同一目录中（但与当前工作目录不同），则文本文件中列出的路径应该只是视频文件名没有任何先前的目录。

希望这对以后的人有所帮助。

您可以任意使用一个文本文件，像这样的输入文件的列表：

ffmpeg -f concat -i ffmpegTest.txt -c:v copy output.mov

要么

您可以像这样明确地命名文件：

ffmpeg.exe -f concat -i 'c:/temp/ffmpeg/01.mov' -i 'c:/temp/ffmpeg/02.mov' -c:v copy 'C:/temp/ffmpeg/output.mov'    

请注意，您一个接一个地使用2个输入，然后-c:v copy用来表示不应仅进行重新编码连接。另外，这是concat多路分配器。这是灵活的，但确实要求2个输入文件具有相同的编解码器。

文本文件的内容如您所写：

file 'c:/temp/ffmpeg/01.mov'
file 'c:/temp/ffmpeg/02.mov'

注意单引号

通用格式为：

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

这将适用于多个驱动器和路径。

这里是一个真正的作品并置文件的例子：

file '/run/media/rnx/New Volume1/PREMIER_OUTPUTEST/Sequence004.mpeg'
file '/home/rnx/Sequence003.mpeg'
file '/run/user/rnx/gvfs/users on edtmchn/Public/Sequence01.mpeg'

这是跨领域的：
一个内部驱动器
一个外部USB驱动器
一个网络驱动器位于同一域的另一台Windows计算机上

该命令的用法是：

ffmpeg -f concat -i conc.txt -c:v copy -strict -2 output.mpeg

这按预期工作，没有任何错误。

注意; 在Windows上，如果将concat与文本文件一起使用，则文本文件中的路径必须相对于输出path。

例如

ffmpeg -f concat -i file.txt "C:\foo\file.mp4"

如果文件位于目录中，则C:\temp\bar.mp4文本文件如下所示：

file ..\temp\bar.mp4
...

使用

ffmpeg.exe" -f concat -safe 0 -i fileWithAbsoluePaths.txt -c copy out.mov

就你而言

"Y:/Shotgun/bin/ffmpeg/bin/ffmpeg.exe" -f concat -safe 0 -i "C:/temp/ffmpeg/ffmpegTest.txt" -c copy "C:/temp/ffmpeg/test.mov

密钥是-safe 0。这样就可以将绝对路径放入txt文件中。

@Eric的答案提供了一条重要的说明，以允许在concat demuxer输入中使用完整路径（您必须提供-safe 0ffmpeg选项）。但是，在Windows下，ffmpeg的concat demuxer无法正确处理以磁盘名开头的绝对/完整路径。尽管它在安全检查中正确识别了完整路径，但是在打开文件时会误将此类路径解释为相对路径（因为它们不是以斜杠开头）。由于非绝对路径是相对于concat解复用器输入脚本的位置的，因此ffmpeg将后者的路径添加到文件路径之前。如果concat脚本命令行参数不包含任何文件路径分隔符（即只是文件名），则问题将被掩盖。

插图：

concat.txt:
file 'c:/videos/01.flv'
file 'c:/videos/02.flv'


ffmpeg -f concat -safe 0 -i "C:/temp/concat.txt" -c copy "C:/temp/test.flv"
...
[concat @ 0000000000abcdef] Impossible to open 'C:/temp/c:/videos/01.flv'
C:/temp/concat.txt: Invalid argument


cd C:\temp
ffmpeg -f concat -safe 0 -i "./concat.txt" -c copy "C:/temp/test.flv"
...
[concat @ 0000000000abcdef] Impossible to open './c:/videos/01.flv'
./concat.txt: Invalid argument


ffmpeg -f concat -safe 0 -i "concat.txt" -c copy "C:/temp/test.flv"
# Works successfully!

虽然cmd.exe不区分大小写，但ffmpeg不区分大小写（主要是在linux上构建，它倾向于* nix shell约定）。我认为，如果c:将输入文件的每一行上的更改为C:，它应该可以工作。