It seems obvious the proper approach would be to parse the file, even if that slows the process down at all. Assuming a file to be VFR is unnecessary and produces false-positives. If the source the CBR, the outfile should be CBR. If this can be looked into and hopefully resolved to preserve the Constant frame rate I would really appreciate it. Then issue:įfmpeg -i "concat:1.ts|2.ts|3.ts" -c copy -bsf:a aac_adtstoasc merged.mp4ĭue to the above issue the result from concat will be VFR: I convert 1.mp4, 2.mp4, 3.mp4 (all encoded at CFR) with above method to. With h.264 video and AAC audio, the following can be used:įfmpeg -i input1.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.tsįfmpeg -i input2.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate2.tsįfmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc output.mp4 If you have MP4 files, these could be losslessly concatenated by first transcoding them to mpeg transport streams. Then I convert it back to MP4, and ffmpeg does not understand it is CFR, so it provides the same rounding. ffmpeg converts it as it can, with some rounding (in my time time line: sometime 3754, sometime 3753, but the real duration should be 3753.75, and Ts accepts no decimal). I convert MP4 to TS, which has a hard coded (spec) frequency of 90 000 Hz. ![]() ![]() Instead of the actual stts (time table) atom which takes lot of space and which is not CFR stricly speaking. Instead FFmpeg should detect the CFR in TS to MP4 conversion and create a CFR stts atom. ![]() Summary of the bug: Problem due to technical limitation of TS format, duration are rounded and this rounding is not detected during TS to MP4 (not a bug, only a lack of feature).
0 Comments
Leave a Reply. |