On Sun, Jul 24, 2016 at 16:49:30 +0200, Peter White wrote: > <(for f in ./*.MOV; do echo "file '$PWD/$f'"; done) > > is a very fancy way of saying *.MOV. ;) Essentially that is what > happens there: > > ffmpeg -i *.MOV
No, it isn't at all. It's a bash-ism (or perhaps zdh-ism) which provides a pseudo file containing the output of the command within the brackets as content. Valid approach, and it's used in the wiki as well. https://trac.ffmpeg.org/wiki/Concatenate This one resulting file is passed as a concat file to "-i". But, as Cley pointed out, that file doesn't have a proper extension or a proper header, so "-f concat" should be added as an input option. And/or a proper header added. > I suppose files.txt is a list of one file path per line? I believe > this is not accepted as input by ffmpeg. It expects media files not > text files listing those. The original poster is using the concat demuxer, read about it in the docs or on the wiki page link I mentioned above. You are right though in saying that "files.txt" is being interpreted as a multimedia file. It either needs the extension .concat (I believe), or better "-f concat". > Also have a look at what Cley Faye wrote in their reply. To concatenate > files you need the concat filter. Just using "-c:v copy -c:a copy" only > gets you what ffmpeg deems the best quality input. That's total nonsense. You *cannot* use a filter with "-c copy". Mark is using the concat *demuxer*, and that may just be fine. I had said he should check the single input files first, but you (Peter) are right in saying that ffmpeg's interpretation of files.txt was misleading the process. Moritz _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
