I have a node server that uses child-process to use ffmpeg to convert a video to mp4. However if the server crashes while transcoding, then I'd like to resume transcoding the file (similar to -C with curl).

I figured I could just start transcoding the file from where it finished to a seperate file and then just concat the two. And while transcoding the file from where it finished works and the file that starts midway plays back fine, when I concat the two files with ffmpeg -i "concat:part1.mp4|part2.mp4" -c copy ouput.mp4 Only the first part will play, and when it gets to the second part it just stays on the last frame of the first part or goes black depending on the video player. (But playing part2.mp4 itself works fine)

There isn't any error during either conversion or the concat.

  • I assume you are transcoding the files to H264. Be aware that this codec uses interframe compression, i.e., the majority of the frames don't have complete information, but just the differences compared to the previous frame; therefore, you can't just concatenate them like that, since the references to the previous keyframes won't match. – PaulJ Nov 29 '14 at 14:24
  • I think he is treating them as two separate runs so I don't think he would see any referencing issue with the second file. The first file could have unexpected referencing issues at the end of the video due to the server crash which may be the problem. Is the final file the expected size? Have you tried concatenating just the video streams without audio? Can you skip into part 2 without trying to do a clean transition from part 1? – dstob Dec 5 '14 at 17:54
  • I have tried without audio, and I hage tried skipping to the second part without transitioning from the 1st but it still doesn't play. Perhaps if I trim the first part by a minute or two before concating it? – Jonathan. Dec 6 '14 at 3:33
  • You've got 2 possible ways: clip part1 along the keyframe boundary (before the last keyframe) and encode part2 from there. And second - patch ffmpeg to store or reconstruct the encoder's internal state, which will unlikely be a viable solution due to numerous and numerous technical pitfalls. – ogurets Dec 10 '17 at 4:29

Your Answer

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

Browse other questions tagged or ask your own question.