Opened 6 years ago
Last modified 4 weeks ago
#7449 open defect
copyts fails if PCR near rollover
Reported by: | Nick | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | copyts dts |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
When the -copyts option is used and the PCR is near the rollover point (doesn't need to rollover, just be near it) ffmpeg appears to drop every video frame and fails to produce video output.
ffmpeg version 3.4.4 (Ubuntu 18.04)
Command: ffmpeg -i pcr_near_rollover.ts -copyts -c:v libx264 -c:a copy output.ts
Input media: https://download.silicondust.com/tmp/pcr_near_rollover.ts
The output file is small containing the audio but no video. Debug output shows a large number of "cur_dts is invalid" messages and "dropping frame 0" messages.
Removing -copyts produces valid video.
Supply an input file with a PCR further away from the rollover produces valid video.
Change History (7)
comment:1 by , 6 years ago
Keywords: | dts added; pcr removed |
---|
comment:2 by , 4 years ago
Component: | undetermined → avformat |
---|
Looks like a similar problem still exists in 4.3.1
must have been fixed 7 years ago, it seemed: https://trac.ffmpeg.org/ticket/3176
no?
comment:3 by , 4 years ago
Status: | new → open |
---|
No, I doubt 738ebb4a0e0c8fbdc83b44cf30b8c9b7ac866270 can fix rollover. Do you have the source file?
comment:5 by , 3 years ago
Some realated stuff https://patchwork.ffmpeg.org/project/ffmpeg/patch/1514545850-24529-1-git-send-email-mymoeyard@gmail.com/
and
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20191112212906.18539-9-cus@passwd.hu/
Which was reported to fix this problem https://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-May/036277.html. Of course, it was NAK'ed. Instead commit here #7876 was done.
comment:6 by , 3 years ago
I will just point out that rollover happens at 0x1FFFFFFFF that is decimal 8589934592. Yet in #7876 it happens at 8589931780 and in #8689 it happens in 8586744840.
What is also funny is this: https://github.com/FFmpeg/FFmpeg/commit/ef7b117b7be8a81d6b245cadf096cbe4b1a12987
Is the issue reproducible with current FFmpeg git head, the only version supported here?
Why are you using
-copyts
if not using it produces better results?