ffmpeg takes forever to read the concatenated ts

[fireattack]

Lately I noticed an issue: when downloading long livestream, it would take forever to merge.

After some quick tests, it appears that the part that is very slow is to read the natively concatenated ts files.

No matter if it's just to ffprobe it, or to read it as input in ffmpeg, it is extremely slow and ffmpeg will throw thousands of [mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004476c0] Found duplicated MOOV Atom. Skipped it with it.

Here is one sample (merely 5h+): https://1drv.ms/f/s!Akq11jtCTJYwg7YYldMf_jj0esbgUA

ffprobe audio.ts alone would take around 30s on my dated computer.

Now, try to mux it ffmpeg -i audio.ts -c copy output.mp4:

It took a whopping 993s (16min) to just remux audio. Video file would take even longer.

The most interesting about this is that the time it takes isn't linear to the duration of the track. It feels like exponential.

In contrast, using mkvmerge, it does take longer time than typical to read it too, but at least it can re-mux it relatively fast:

mkvmerge audio.ts -o audio.mka - 22s

I understand this is an external dependency issue, so probably nothing can be done here; just think it might be worth a note.

[fireattack]

Another issue with merging: it looks like after we concatenated the file, we firstly remux each track to mp4 and then remux them together.

I'm not sure why not just remux all the tracks together in one-pass; as it could prolong the merging process significantly due to disk I/O (since it is writing the file one more time).

[glubsy]

Thanks for reporting. Unfortunately there is not much I can do about this.
My understanding is that the repeated Found duplicated MOOV Atom log messages from ffmpeg should not be a real problem as they are mostly just a warning.

What version of ffmpeg are you using? I don't have any major issue with 4.3.2, 4.4.2, nor 5.0.1. It does take a while for very long livestreams but so far I have not found any other reliable way of doing concatenation + remux.

Another issue with merging: it looks like after we concatenated the file, we firstly remux each track to mp4 and then remux them together.

I'm not sure why not just remux all the tracks together in one-pass; as it could prolong the merging process significantly due to disk I/O (since it is writing the file one more time).

Indeed, that is what is happening. I don't remember exactly why I ended up doing it this way, but as far as I know, there is not other way around this.
Feel free to experiment with other methods though, and if you find one that is reliable and doesn't result in a corrupt file, please let us know. ;)

I plan on revisiting this step in the future, especially to handle corrupt video/audio packets better.

[fireattack]

So far I never notice any broken video, so yeah "Found duplicated MOOV Atom" is just a warning and likely what causes this slowness, but this is just performance.

As for muxing, I think we can just use native concat as we do now, and then directly mux the result two .ts files together using ffmpeg. (ffmpeg -i video_nativecat.ts -i audio_nativecat.ts -c copy etc.), without muxing each track into separate mp4 file first.

It will still have the performance issues mentioned above (since we still need to read it at least once), but it removes the need to read/write the track twice (or thrice if we count concat). And I don't find it causing issues in final result.

Edit: a bug ticket about the remuxing long duration video issue is now created: https://trac.ffmpeg.org/ticket/9941

[glubsy]

Thanks for taking the time to create that ticket.

Regarding muxing, I'm fairly certain I ran into issues doing it the way you suggest, I think the audio and video were not synchronized last time I tried (and probably some other weird issues like that).
But since you're saying you didn't have any issue on your side, I'll have to test that again.