Answers.Body: <p>I don't have a sample of your file so I don't know if this fixes it or not, but have you tried a simple remux?</p>
  
  <pre><code>ffmpeg -y -i h264_file.ts -c copy remuxed.ts
  </code></pre>
  
  <p>This is also basically the same thing, but helpful if you want video and audio in separate files before you remux:</p>
  
  <pre><code>ffmpeg -y -i h264_file.ts -map 0:0 -c:v copy -muxdelay 0 video.ts -map 0:1 -c:a copy -muxdelay 0 audio.ts
  ffmpeg -y -copyts -i video.ts -i audio.ts -c copy remuxed.ts
  </code></pre>
  
  <p>You could also try reencoding audio but copying video.  Encoding audio but copying video will be fast and usually concerns about reencoding loss is a lot less significant with audio.  (Use audio synchronization, see <code>-async</code> in documentation.)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-24T02:08:24.130Z
Answers.Text: I hadn't considered re-muxing it - thanks for the suggestion.  I will try it and reply back.
Answers.UserDisplayName: George Mari
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-25T00:57:46.603Z
Answers.Text: Unfortunately, the re-muxing did not fix it.  Specifically, I tried the two separate steps you listed.  I also tried:  `ffmpeg -i ./file.ts -c copy file_remuxed.ts` `ffmpeg -i ./file.ts -c copy -vsync drop file_remuxed_vsync_drop.ts` `ffmpeg -i ./file.ts -c copy -r 60 file_remuxed_r60.ts` `ffmpeg -i ./file.ts -c copy -r 30 file_remuxed_r30.ts` All resulted in packet durations of N/A when examined using ffprobe.
Answers.UserDisplayName: George Mari
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-23T01:48:23.983Z
Answers.LastActivityDate: 2019-05-23T01:48:23.983Z
Answers.UserDisplayName: acker9
Body: <p>I have H.264 files that, when I run FFprobe on them, like this:</p>
  
  <pre><code>ffprobe -i h264_file.ts -show_packets -select_streams v
  </code></pre>
  
  <p>...it shows that each video packet has no values for duration, and no value for duration_time, like this:</p>
  
  <blockquote>
  <pre><code>...
  [PACKET]
  codec_type=video
  stream_index=0
  pts=8098077717
  pts_time=89978.641300
  dts=8098077717
  dts_time=89978.641300
  **duration=N/A
  duration_time=N/A
  convergence_duration=N/A
  convergence_duration_time=N/A**
  size=2354
  pos=14633920
  flags=_
  [/PACKET]
  ...
  </code></pre>
  </blockquote>
  
  <p>My question is, other than re-encoding the file, and assuming I know the source to be 60 fps, is there a way to correct this video packet duration?</p>
  
  <p>I know I can do it by re-encoding - I have done so successfully.  But I am wondering if there is an easier and faster way of doing it.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-05-21T18:02:29.777Z
Comments.Text: Why do you need duration? The effective duration is the delta with the pts of the next frame.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-05-24T02:07:23.673Z
Comments.Text: Without the packet duration, MythTV thinks the transport stream file has a duration twice as long as it actually is.  I think it defaults to 30fps, but this source generates files at 60 fps.
Comments.UserDisplayName: George Mari
Tags: <h.264><ffprobe>
Title: H.264 video packet duration missing
UserDisplayName: George Mari
ThreadText: # H.264 video packet duration missing
  
  (Asked by: username_0 on 2019-05-21)
  
  I have H.264 files that, when I run FFprobe on them, like this:
  
  ```
  ffprobe -i h264_file.ts -show_packets -select_streams v
  
  ```
  
  ...it shows that each video packet has no values for duration, and no value for duration\_time, like this:
  
  > ```
  > ...
  > [PACKET]
  > codec_type=video
  > stream_index=0
  > pts=8098077717
  > pts_time=89978.641300
  > dts=8098077717
  > dts_time=89978.641300
  > **duration=N/A
  > duration_time=N/A
  > convergence_duration=N/A
  > convergence_duration_time=N/A**
  > size=2354
  > pos=14633920
  > flags=_
  > [/PACKET]
  > ...
  >
  > ```
  
  My question is, other than re-encoding the file, and assuming I know the source to be 60 fps, is there a way to correct this video packet duration?
  
  I know I can do it by re-encoding - I have done so successfully. But I am wondering if there is an easier and faster way of doing it.
  
  **Tags:** h.264, ffprobe
  
  > **Comments:**
  > **username_1**: Why do you need duration? The effective duration is the delta with the pts of the next frame.  
  > **username_0**: Without the packet duration, MythTV thinks the transport stream file has a duration twice as long as it actually is.  I think it defaults to 30fps, but this source generates files at 60 fps.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-05-23. Score: 0
  
  I don't have a sample of your file so I don't know if this fixes it or not, but have you tried a simple remux?
  
  ```
  ffmpeg -y -i h264_file.ts -c copy remuxed.ts
  
  ```
  
  This is also basically the same thing, but helpful if you want video and audio in separate files before you remux:
  
  ```
  ffmpeg -y -i h264_file.ts -map 0:0 -c:v copy -muxdelay 0 video.ts -map 0:1 -c:a copy -muxdelay 0 audio.ts
  ffmpeg -y -copyts -i video.ts -i audio.ts -c copy remuxed.ts
  
  ```
  
  You could also try reencoding audio but copying video. Encoding audio but copying video will be fast and usually concerns about reencoding loss is a lot less significant with audio. (Use audio synchronization, see `-async` in documentation.)
  
  > **Comments:**
  > **username_0**: I hadn't considered re-muxing it - thanks for the suggestion.  I will try it and reply back.  
  > **username_0**: Unfortunately, the re-muxing did not fix it.  Specifically, I tried the two separate steps you listed.  I also tried:  `ffmpeg -i ./file.ts -c copy file_remuxed.ts` `ffmpeg -i ./file.ts -c copy -vsync drop file_remuxed_vsync_drop.ts` `ffmpeg -i ./file.ts -c copy -r 60 file_remuxed_r60.ts` `ffmpeg -i ./file.ts -c copy -r 30 file_remuxed_r30.ts` All resulted in packet durations of N/A when examined using ffprobe.  
  
  ---
  
  