Set frame rate of video extracting

[zliang7]

This value means how many image files generated per second.
To reduce the number of image files, the value must be less than
the video FPS.

[zliang7]

This PR is trying to fix #194. To reduce the number of image files, this PR use frame rate value(FPS) Instead of using step value of frame.
@nmanovic , PTAL

[nmanovic]

Option -vsync 0 is very important. It allows to generate non-duplicated frames. -r can lead to duplicated frames and in general it is bad

• need to annotate the same frame twice
• there is no correspondence between frame and video. What does frame Register new users #3 mean? Is it duplication of frame Support Pascal VOC Format #2? Is it an unique frame?

[zliang7]

I have tried to keep the vsync options. But if both -vsync and -r options are specified, ffmpeg reports error:
"Using -vsync 0 and -r can produce invalid output files"

[nmanovic]

@zliang7, this is why '-r' option is not good here. See my thoughts below.

[nmanovic]

nm/rest_api should replace develop very soon. Could you please submit your changes into nm/rest_api branch?

[nmanovic]

The main problem with the approach is you will get annotation file which doesn't correspond to the video file. For example, originally you have a video file with 30FPS. If someone annotates the whole video file we will get <frame000000>, <frame000001>, ... inside the annotation file for every frame. Now you say that we can provide "custom" FPS. You will get another <frame000000>, <frame000001>, ... which don't correspond to the original video file. How to match if you don't store extra parameters (e.g. custom frame rate) inside the annotation file?

[zliang7]

I'm not familiar with the internals of backend. Is there any difference between upload a video directly with upload all frame images pre-extracted locally?

[nmanovic]

@zliang7, if you still have questions it is better to organize a meeting and discuss.

[nmanovic]

Let me clarify my vision for the feature:

• Need several extra fields:

  • start frame. It should be 0 by default, >=0, less than stop frame. It will be good if you can specify it as frame number or as time
  • stop frame. It should be empty by default (corresponds to the end), >=0, more than start frame. It will be good if you can specify it as frame number or as time
  • step. It should be empty by default (corresponds to the minimum possible step), >0. It will be good if you can specify it as frame number or as time

• Inside dump file you should have exact correspondence between the video file and dumped frames. For example, if you annotate only 1 frame from 30 frames you should be <frame000000>, <frame000029>, ... inside the annotation file.

• As I said previously the patch should be submitted into nm/rest_api branch. It will be merged into develop branch very soon.

[nmanovic]

• start frame. It should be 0 by default, >=0, less than stop frame. It will be good if you can specify it as frame number or as time

May be for unification the default value for start frame should be also empty.

[nmanovic]

One more important note. The same approach can work not only for a video file. It can work for a set of images or an archive. All these parameters above should be as a part of rest api and go to DB as well.

[nmanovic]

@zliang7 , should we expect a new patch for the issue or just close the PR?

[zliang7]

@nmanovic , it's OK to close this PR. I will try to submit again after your restful api PR get merged. But before that, I need some time to understand your huge change to rebase/change this one.

I still have some questions about your thoughts. Instead of setup a meeting to discuss, I prefer to discuss in the issue page. So everyone can see it and join the discussion, since
cvat is an opensource project. Please see my question at #194

[nmanovic]

OK. Let's make one more iteration with the PR. I will close it for now.