Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T12:55:20.630Z
Answers.Text: but what is the difference between no `-copyts` and `-copyts` + `-start_at_zero`? Is there any need of it, why does it exists?
Answers.UserDisplayName: A. Newb
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T13:33:30.517Z
Answers.Text: `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.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T16:53:44.127Z
Answers.Text: 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.
Answers.UserDisplayName: A. Newb
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T17:39:20.533Z
Answers.Text: 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.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T21:54:10.837Z
Answers.Text: 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?
Answers.UserDisplayName: A. Newb
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-08T04:21:49.677Z
Answers.Text: You should never need copyts when copying into a MP4. Let ffmpeg generate new timestamps. Timestamps have no impact on video/audio quality.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-08T13:15:11.563Z
Answers.Text: what about audio/video sync? Or that is (iirc) only after the 26 hour:something:something mark?
Answers.UserDisplayName: A. Newb
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-08T13:36:57.690Z
Answers.Text: 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).
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-08T21:22:28.817Z
Answers.Text: 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.
Answers.UserDisplayName: A. Newb
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-09T07:47:06.337Z
Answers.Text: 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?
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-09T20:10:04.157Z
Answers.Text: 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!
Answers.UserDisplayName: A. Newb
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T05:26:32.913Z
Answers.LastActivityDate: 2017-10-07T05:26:32.913Z
Answers.UserDisplayName: Gyan
Body: <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>
  
Tags: <ffmpeg><streaming><mp4><mpeg>
Title: Proper command to remux mpeg-ts to mp4 with FFmpeg?
UserDisplayName: A. Newb
ThreadText: # 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!  
  
  ---
  
  