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

CC BY-SA 4.0
2019-05-24T02:08:24.130Z
I hadn't considered re-muxing it - thanks for the suggestion.  I will try it and reply back.
George Mari
CC BY-SA 4.0
2019-05-25T00:57:46.603Z
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.
George Mari
CC BY-SA 4.0
2019-05-23T01:48:23.983Z
2019-05-23T01:48:23.983Z
acker9
<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>

CC BY-SA 4.0
2019-05-21T18:02:29.777Z
Why do you need duration? The effective duration is the delta with the pts of the next frame.
Gyan
CC BY-SA 4.0
2019-05-24T02:07:23.673Z
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.
George Mari
<h.264><ffprobe>
H.264 video packet duration missing
George Mari
# 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.  

---

