epic-kitchens / epic-kitchens-100-annotations

:plate_with_cutlery: Annotations for the public release of the EPIC-KITCHENS-100 dataset

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Video P09_08 has an FPS of 60

iranroman opened this issue · comments

EPIC_100_video_info.csv states that video P09_08 has an FPS=29.97002997002997 and a duration of 126.459667 seconds. This results in around 3790 expected frames total.

However, inspecting inside rgb_frames one can find 7599 frames for this video. Similarly, the last action in the video ends at frame 7253.

Therefore, it makes more sense that the FPS of this video is around FPS=60 given that 7599/126.459667 = 60.090305.

Same story with video P17_02.

stated fps: 47.95204795204796
stated duration: 545.77

highest frame number found in rgb_frames: 32754

expected fps : 32754/545.77 = 60.0143

Therefore the correct fps should also be around 60 for this video.

There's a difference between the video's native fps (which is how the video was recorded) and how we extract the frames. As described clearly in our paper (see our PAMI paper, page 3 footnote where this is detailed), all videos are re-encoded to a uniform fps before rgb frames were extracted.
The file you're referencing here details the native fps.

Hi Dima,
Are all videos re-encoded to 60 fps? Based on similar calculations it seems videos with 50 native fps remained 50 fps for the extracted frames.

I'm not 100% sure but I think the extracted frames from original EK55 videos are 60fps, while additional videos from EK100 (P##_1##) has native fps (50fps). I think this point should be clarified.

All videos are released in their native fps. These are variable (mostly 60fps for EK55 and 50fps for EK100 videos, indeed those are the ones starting with _1, but some have variable native fps - please see here column fps.

You can see the exact code to extract frames for EK100 videos here
For EK50 videos, these were unified to 60fps and the code to encode is here

In our paper, we explain the reason we had to change from 60fps to 50fps in our follow-up collection. This was related to the native lighting frequency which had caused flickering in our earlier recordings. Please refer to our IJCV paper where we explain this decision.