The seek functionality of StreamReader on the video stream does not return the correct frame if the start_time_stamp of the video stream is nonzero. #3824
It seems like this repo is not getting actively monitored any more, but I still would like to report this issue with the seek functionality of StreamReader here. I will post another discussion in pytorch forum later.
The issue is the seek functionality of StreamSmart does not seek to the correct position when the start_time_stamp of the video stream is non-zero. To reproduce the bug, use the code below and put the two attached videos in the same folder of the test script.
The start_time_stamp of source.mp4 is zero and we can see that the seek functionality could seek to the correct frame by seeking to the time_stamp = (frame_index / fps), i.e. the first part succeeds. Then we use the command ffmpeg -i tmp/test_bug/source.mp4 -output_ts_offset 0.033333 -c copy tmp/test_bug/test.mp4 to generate test.mp4 from source.mp4. test.mp4 is exactly the same as source.mp4 except that the former has a non-zero start_time_stamp. However, the seek method of StreamReader returns a different frame and fails the second part of the test script.
I believe this behavior is not desired because a typical user of a video will not be aware of the value of the start_time_stamp. The same call of the seek method may return two different frames, causing unexpected misalignment problems. I tried another Video Reader, the Decord, and it could handle this issue correctly and always return the same frame whether the start_time_stamp is zero or not.
It would be highly appreciated if someone could further investigate this issue.
🐛 Describe the bug
It seems like this repo is not getting actively monitored any more, but I still would like to report this issue with the seek functionality of StreamReader here. I will post another discussion in pytorch forum later.
The issue is the seek functionality of StreamSmart does not seek to the correct position when the start_time_stamp of the video stream is non-zero. To reproduce the bug, use the code below and put the two attached videos in the same folder of the test script.
The start_time_stamp of
source.mp4
is zero and we can see that the seek functionality could seek to the correct frame by seeking to thetime_stamp = (frame_index / fps)
, i.e. the first part succeeds. Then we use the commandffmpeg -i tmp/test_bug/source.mp4 -output_ts_offset 0.033333 -c copy tmp/test_bug/test.mp4
to generatetest.mp4
fromsource.mp4
.test.mp4
is exactly the same assource.mp4
except that the former has a non-zero start_time_stamp. However, the seek method of StreamReader returns a different frame and fails the second part of the test script.I believe this behavior is not desired because a typical user of a video will not be aware of the value of the start_time_stamp. The same call of the
seek
method may return two different frames, causing unexpected misalignment problems. I tried another Video Reader, the Decord, and it could handle this issue correctly and always return the same frame whether the start_time_stamp is zero or not.It would be highly appreciated if someone could further investigate this issue.
https://github.com/user-attachments/assets/56ed60b0-fbe0-4109-a661-f9e13f3aca1d
https://github.com/user-attachments/assets/5370d068-407a-46d5-8722-ca9bcc93831c
Versions