ffmpeg takes forever to read the concatenated ts about livestream_saver HOT 4 OPEN

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

from livestream_saver.

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).

from livestream_saver.

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.

from livestream_saver.

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.

from livestream_saver.