Breakthrough / PySceneDetect

:movie_camera: Python and OpenCV-based scene cut/transition detection program & library.

Home Page:https://www.scenedetect.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

detect function doesn`t use start_time, end_time arguments

Vsevosemnog opened this issue · comments

scenedetect == 0.6.1

The start is 00:33:50.580 the end is 00:38:53.680
str(scene[0]) = "00:33:50.580"
str(scene[1]) = "00:38:53.680"

help_scenes = detect(video_path=video_path, detector=ContentDetector(threshold=15.0,min_scene_len=int(60 * clip_fps)), start_time=str(scene[0]), end_time=str(scene[1]))

for this found scenes is

Detecting scenes...

[2023-08-09 08:43:17,224] INFO - (00:00:00.000 [frame=0, fps=50.000], 00:03:56.320 [frame=11816, fps=50.000])
[2023-08-09 08:43:17,225] INFO - (00:03:56.320 [frame=11816, fps=50.000], 00:05:02.580 [frame=15129, fps=50.000])

detect function found 2 scenes with time (00:00:00.000 to 00:03:56.320) and (00:03:56.320 to 00:05:02.580)
So, the time is wrong, because i set arguments start_time and end_time

What did i do wrong? please help

Does the issue persist with other videos? Can you share a full code sample? Can you share the video this happens with as well?

I just tested locally and these arguments seem to be working as expected. It's possible seeking in the input video is broken or non-functional, which might lead to this issue. If that's the case, then seeking behavior might need to be updated.

Start time is used pretty early in the detect function to seek into the video, so it seems like that's not happening:
https://github.com/Breakthrough/PySceneDetect/blob/main/scenedetect/__init__.py#L147

I tried to use code from your link

help_video = open_video(video_path)
help_video.seek(str(scene[0]))
help_scene_manager = SceneManager()
help_scene_manager.add_detector(ContentDetector(threshold=15.0,min_scene_len=int(60 * clip_fps)))
help_scene_manager.detect_scenes(video=help_video, end_time = str(scene[1]))
help_scenes = help_scene_manager.get_scene_list()

str(scene[0]) = "00:33:50.580"
str(scene[1]) = "00:38:53.680"

and then i get error like this

[2023-08-10 09:00:49,774] INFO - try-except block in create_runtime_metadata
[2023-08-10 09:00:49,774] INFO - '<' not supported between instances of 'str' and 'int'

Does str start_time works properly?

I converted string_timestamp to float (seconds of video)
but detect_scenes gave me this result

[(00:00:00.000 [frame=0, fps=50.000], 00:03:57.320 [frame=11866, fps=50.000]), (00:03:57.320 [frame=11866, fps=50.000], 00:05:03.580 [frame=15179, fps=50.000]), (00:05:03.580 [frame=15179, fps=50.000], 00:05:04.660 [frame=15233, fps=50.000])]

The time interval is wrong again (should be between 33 min and 38 min)

Sorry, i can`t share the video

Could you try to update to v0.6.2 and see if that resolves the issue? Locally I tried the same code sample using both strings and floats, and it seemed to work okay. I'm not sure where the first error comes from, but the latter does seem to come from this line but can probably be ignored, as it's corrected below here. We should fix the warning on our end, but the code should still function.

After you call seek on the video, could you share the values of help_video.position, help_video.frame_number, and help_video.duration? I suspect something is happening where the video cannot report the correct timecode.

Lastly, can you also share the version of OpenCV you are using, and also see if updating to a more recent version resolves the issue? Thanks.

P.S. Can you reliably reproduce this with different videos?

I updated to v0.6.2 - issue didn`t resolve
opencv-ptyhon - 4.8.0.76
I tried to watch what happens with video when i seek position
str(scene[0]) = 00:33:50.580

help_video = open_video(video_path)
print("\n\n\n\n")
print("BEFORE SEEK")
print(help_video.position)
print(help_video.frame_number)
print(help_video.duration)
help_video.seek(str_time_to_float(str(scene[0])))
print("AFTER SEEK")
print(help_video.position)
print(help_video.frame_number)
print(help_video.duration)

if i try
help_video.seek((str(scene[0]))
the error occurs and program exites. Code does not function further

TypeError: '<' not supported between instances of 'str' and 'int'

scene[0] is FrameTimeCode type

so when i do
help_video.seek(scene[0])

error doesn`t occur, but i gave to this function this argument scene[0] = 00:33:50.580
and this happened

BEFORE SEEK
00:00:00.000
0
00:38:53.700
00:33:50.580
2030.058
AFTER SEEK
00:00:00.000
-101500 - something bad happend and i`m still in 00:00:00.000 position of the video
00:38:53.700

This error happens when i do something like this

help_video.seek(scene[0].get_seconds())
even if i use frame like this
help_video.seek(scene[0].frame_num)

It's possible the video is corrupt or the container type does not allow seeking. Any example files you can provide would be helpful if we are to resolve this on the PySceneDetect side of things.

However, as a workaround, you can try re-encoding the video using ffmpeg first, or try using a different video backend (e.g. open_video('video.mp4', backend='pyav')).

We can try falling back to slow seeking, but I am weary about adding this directly to PySceneDetect without the ability to reproduce the issue with a test video. I was under the impression that OpenCV should handle cases like this when it interacts with ffmpeg. The only other thing I can think of is using the timestamp in milliseconds to seek instead of frame number.

Inside the OpenCV backend, we use frame numbers for seeking here:
https://github.com/Breakthrough/PySceneDetect/blob/main/scenedetect/backends/opencv.py#L248

I'm curious if CAP_PROP_POS_MSEC would work for this particular video. Can you also report the result of help_video.position_ms? That uses this property, unlike all the other timecode methods, which are frame based.

Any samples you or anyone else can provide that exhibit this behavior would be very helpful. Thank you!

BTW: The Python API docs cover which methods accept strings for timecodes, and which require frame numbers / FrameTimecode objects explicitly. Hope this helps.

Thanks a lot, you were right, the file is corrupted