<p>Unless you know you have a specific need to preserve timestamps, there's no need to use <code>-copyts</code>. MPEG-TS, being a format, used for remote viewing, will have some start time offset, by default, to allow for buffering at the player's side. MP4 for local playback, doesn't need that, <code>copyts</code> will preserve it.</p>

CC BY-SA 3.0
2017-10-07T12:55:20.630Z
but what is the difference between no `-copyts` and `-copyts` + `-start_at_zero`? Is there any need of it, why does it exists?
A. Newb
CC BY-SA 3.0
2017-10-07T13:33:30.517Z
`start_at_zero` is relevant if you're seeking into the input i.e. `-ss 10` Ordinarily, the first sought frame has its TS reset to zero. With s_a_0, its TS will now be 10. If used with `copyts`, that TS will be conveyed to the output.
Gyan
CC BY-SA 3.0
2017-10-07T16:53:44.127Z
I thought you meant if I `-ss 10` a .ts file, it will actually ss @ 11.4 (1.4 delay from ts), but if I do use -ss 10 with s_a_0, it will actually start at 10? 
When I checked, this doesn't make sense as it is not what is happening. 

The original .ts file had start: 1.4, when going under `-ss 10`, that same one had a start of 0.0480, same if I added start_at_zero to it, or both copyts and start_at_zero.
A. Newb
CC BY-SA 3.0
2017-10-07T17:39:20.533Z
Let's say your MPEG-TS has start time of 15 and duration of 10s., and your codec is intra-coded, so we don't have to worry about GOP. With `-ss 3 -i in.ts -c copy out.mp4`, first sought frame has PTS of 0 after the demuxer stage, and out.mp4 has start time of 0. With `-ss 3 -copyts -i in.ts -c copy out.mp4`, the first sought frame has PTS of 18 after demuxer, which gets carried over during mux in out.mp4. With `-ss 3 -start_at_zero -copyts -i in.ts -c copy out.mp4`, first sought frame has PTS of 3 after demuxer, which gets carried over during mux in out.mp4.
Gyan
CC BY-SA 3.0
2017-10-07T21:54:10.837Z
thank you for the further clarification. Now to wrap it up, following your original answer - In what exact case where I just want to remux a file, from .ts to a .mp4 container without losing any quality, there will be a need of including `-copyts`? And if I do need it in certain situations, isn't it always better to include s_a_0 if I do not want to have that "buffering" to my new .mp4 output?
A. Newb
CC BY-SA 3.0
2017-10-08T04:21:49.677Z
You should never need copyts when copying into a MP4. Let ffmpeg generate new timestamps. Timestamps have no impact on video/audio quality.
Gyan
CC BY-SA 3.0
2017-10-08T13:15:11.563Z
what about audio/video sync? Or that is (iirc) only after the 26 hour:something:something mark?
A. Newb
CC BY-SA 3.0
2017-10-08T13:36:57.690Z
Not an issue normally, but I don't know the current state of how ffmpeg handles PTS rollover at the 26 hr mark. Update: apparently, not [well](https://trac.ffmpeg.org/ticket/6251).
Gyan
CC BY-SA 3.0
2017-10-08T21:22:28.817Z
so taking in consideration what one of the people said in the comments on your link, back to one of my questions, is there anything wrong or anything negative about using both `-copyts` and `-start_at_zero` on any .ts file always when dealing with a remux .ts to .mp4? Sorry for being so annoying with the questions, but thank you very much for being even more consistent with all the answers, really.
A. Newb
CC BY-SA 3.0
2017-10-09T07:47:06.337Z
All copyts + sa0 will achieve is that the start time of the MP4 will represent the offset of the trimmed portion within the source file, but the identity of the source file, or the command used to generate it won;t carry through. Unless you know you need to, why bother?
Gyan
CC BY-SA 3.0
2017-10-09T20:10:04.157Z
well I was not sure, I have recordings of streams, twitch.tv mostly that are in .ts format so I was not sure if it would cause any problem, but yeah, if you say so, I will just remux them all from .ts to mp4 with `-c:v copy -c:a copy -bsf:a aac_adtstoasc` without `-copyts` or sa0. I was very interested in the behind the scenes aspect, does not using copyts generate approriate new TS by itself, can it go out of sync before 26h, and all those stuff which I had no idea of!
A. Newb
CC BY-SA 3.0
2017-10-07T05:26:32.913Z
2017-10-07T05:26:32.913Z
Gyan
<p>Should I just use plain command like this:</p>

<pre><code>ffmpeg -i C:\video_input.ts -c:v copy -c:a copy -bsf:a aac_adtstoasc C:\video_output.mp4
</code></pre>

<p>but I have seen many using <code>-copyts</code> to it, why is this needed I do not completely understand it's documentation?</p>

<pre><code>ffmpeg -i C:\video_input.ts -c:v copy -c:a copy -bsf:a aac_adtstoasc -copyts C:\video_output.mp4
</code></pre>

<p>and also every time I use <code>-copyts</code> there is an added delay before the first frame starts, so to fix this is it safe to use <code>-start_at_zero</code> or it breaks the point of copyts to some degree (if that makes any sense)?</p>

<pre><code>ffmpeg -i C:\video_input.ts -c:v copy -c:a copy -bsf:a aac_adtstoasc -copyts -start_at_zero C:\video_output.mp4
</code></pre>

<p>Thanks!</p>

<ffmpeg><streaming><mp4><mpeg>
Proper command to remux mpeg-ts to mp4 with FFmpeg?
A. Newb
# Proper command to remux mpeg-ts to mp4 with FFmpeg?

(Asked by: username_0 on 2017-10-06)

Should I just use plain command like this:
ffmpeg -i C:\video_input.ts -c:v copy -c:a copy -bsf:a aac_adtstoasc C:\video_output.mp4

but I have seen many using -copyts to it, why is this needed I do not completely understand it's documentation?
ffmpeg -i C:\video_input.ts -c:v copy -c:a copy -bsf:a aac_adtstoasc -copyts C:\video_output.mp4

and also every time I use -copyts there is an added delay before the first frame starts, so to fix this is it safe to use -start_at_zero or it breaks the point of copyts to some degree (if that makes any sense)?
ffmpeg -i C:\video_input.ts -c:v copy -c:a copy -bsf:a aac_adtstoasc -copyts -start_at_zero C:\video_output.mp4

Thanks!

**Tags:** ffmpeg, streaming, mp4, mpeg


---

## 1 answers

### Answer by username_1 on 2017-10-07. Score: 4 | Accepted answer

Unless you know you have a specific need to preserve timestamps, there's no need to use `-copyts`. MPEG-TS, being a format, used for remote viewing, will have some start time offset, by default, to allow for buffering at the player's side. MP4 for local playback, doesn't need that, `copyts` will preserve it.

> **Comments:**
> **username_0**: but what is the difference between no `-copyts` and `-copyts` + `-start_at_zero`? Is there any need of it, why does it exists?  
> **username_1**: `start_at_zero` is relevant if you're seeking into the input i.e. `-ss 10` Ordinarily, the first sought frame has its TS reset to zero. With s_a_0, its TS will now be 10. If used with `copyts`, that TS will be conveyed to the output.  
> **username_0**: I thought you meant if I `-ss 10` a .ts file, it will actually ss @ 11.4 (1.4 delay from ts), but if I do use -ss 10 with s_a_0, it will actually start at 10?  When I checked, this doesn't make sense as it is not what is happening.   The original .ts file had start: 1.4, when going under `-ss 10`, that same one had a start of 0.0480, same if I added start_at_zero to it, or both copyts and start_at_zero.  
> **username_1**: Let's say your MPEG-TS has start time of 15 and duration of 10s., and your codec is intra-coded, so we don't have to worry about GOP. With `-ss 3 -i in.ts -c copy out.mp4`, first sought frame has PTS of 0 after the demuxer stage, and out.mp4 has start time of 0. With `-ss 3 -copyts -i in.ts -c copy out.mp4`, the first sought frame has PTS of 18 after demuxer, which gets carried over during mux in out.mp4. With `-ss 3 -start_at_zero -copyts -i in.ts -c copy out.mp4`, first sought frame has PTS of 3 after demuxer, which gets carried over during mux in out.mp4.  
> **username_0**: thank you for the further clarification. Now to wrap it up, following your original answer - In what exact case where I just want to remux a file, from .ts to a .mp4 container without losing any quality, there will be a need of including `-copyts`? And if I do need it in certain situations, isn't it always better to include s_a_0 if I do not want to have that "buffering" to my new .mp4 output?  
> **username_1**: You should never need copyts when copying into a MP4. Let ffmpeg generate new timestamps. Timestamps have no impact on video/audio quality.  
> **username_0**: what about audio/video sync? Or that is (iirc) only after the 26 hour:something:something mark?  
> **username_1**: Not an issue normally, but I don't know the current state of how ffmpeg handles PTS rollover at the 26 hr mark. Update: apparently, not [well](https://trac.ffmpeg.org/ticket/6251).  
> **username_0**: so taking in consideration what one of the people said in the comments on your link, back to one of my questions, is there anything wrong or anything negative about using both `-copyts` and `-start_at_zero` on any .ts file always when dealing with a remux .ts to .mp4? Sorry for being so annoying with the questions, but thank you very much for being even more consistent with all the answers, really.  
> **username_1**: All copyts + sa0 will achieve is that the start time of the MP4 will represent the offset of the trimmed portion within the source file, but the identity of the source file, or the command used to generate it won;t carry through. Unless you know you need to, why bother?  
> **username_0**: well I was not sure, I have recordings of streams, twitch.tv mostly that are in .ts format so I was not sure if it would cause any problem, but yeah, if you say so, I will just remux them all from .ts to mp4 with `-c:v copy -c:a copy -bsf:a aac_adtstoasc` without `-copyts` or sa0. I was very interested in the behind the scenes aspect, does not using copyts generate approriate new TS by itself, can it go out of sync before 26h, and all those stuff which I had no idea of!  

---

