The timestamp not correct after seek

[kerry]

Summary of the bug:
Use ffplay to play a static hls address, if there no seek, the timestamp is normally, but if we do seek(press → or ↑) the timestamp will return to zero and then accumulate again, this issue will cause progress bar not correct after seek.

I have found the code may caused this issue in ffmpeg/libavformat/seek.c#732, if cur_dts is valued as seek_timestamp(the seek value), the timestamp will normally even after seek, but this modify may have side effect. So could you analysis this and give a office solution. Thanks.

How to reproduce:

ffplay http://live.ximalaya.com/radio-first-page-app/history/1994/24.m3u8\?start\=1644363000000\&end\=1644368400000

ffplay version 5.0 Copyright (c) 2003-2022 the FFmpeg developers

built with Apple clang version 13.0.0 (clang-1300.0.29.30)

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Balling]

but if we do seek(press → or ↑) the timestamp will return to zero

Well, I cannot reproduce this. Please describe it more precise.

[kerry]

Replying to Balling:When playing a music URI with ffplay, we know that pressing the up key on the keyboard can fast forward 60 seconds, pressing the right key can fast forward 10 seconds, and we can see the playing time stamp in the lower right corner of the command line window. So we can simulate fast forward by pressing up or down after ffplay is started, and then observe the playing time stamp in the command line window. You can see that the time stamp will be zero after fast forward.Hope this could help for you.

but if we do seek(press → or ↑) the timestamp will return to zero

Well, I cannot reproduce this. Please describe it more precise.

[Marton Balint]

Not a regression or a crash, so does not qualify as important.