[FFmpeg-trac] #9494(undetermined:new): Seeking in MPEG TS with copyts overflows for 13+ hours
FFmpeg
trac at avcodec.org
Thu Nov 4 10:18:12 EET 2021
#9494: Seeking in MPEG TS with copyts overflows for 13+ hours
-------------------------------------+-------------------------------------
Reporter: Radek | Owner: (none)
Hladík |
Type: defect | Status: new
Priority: normal | Component:
| undetermined
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by Radek Hladík):
Replying to [comment:1 Balling]:
> >I know that mpegts timestamp have the resolution of cca 26.5 hours, but
this problem occurs exactly in the half.
>
> Not that simple, 2^33 / 90000 seconds = 26 hours 30 minutes 43.718
seconds. There is rollover support, but not perfect. #7876, #7449, #8689.
I did not want to clutter the original ticket message with the rollover
too much as I think that it is an unrelated problem. I've read through a
lot of tickets in this tracker before posting, I even tried the patch from
#7876 and it did not change a thing.
As far as I understand the rollover, the pts is 33-bit long unsigned
number with 90000 timebase. However my problem occurs almost exactly at
2^32^ /90000=4294967296/90000 = 47721.85884 seconds = 13.2560719012346
hours. So it looks like to me that the 33rd bit gets lost somewhere and/or
is converted into sign but I do not want to speculate as I do not know the
ffmpeg code....
Also if I just copy the whole file without seeking, then everything works
fine:
{{{
% ffmpeg -i 16hours.ts -c copy -copyts test_copy_ts.ts >a6 2>&1
}}}
and even the progress time is fine:
{{{
frame=1440000 fps=76557 q=-1.0 Lsize= 1200748kB time=15:59:59.99 bitrate=
170.8kbits/s speed=3.06e+03x
}}}
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9494#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list