Multiple stills - revisited

[MC-arjen]

followup of #84

Q: "question: the Still time code in the response is in integer seconds. Is that sufficient resolution to be used in Rich Media applications? I would like to see resolution improved. Possible to .01 seconds (100Hz)"

A: The still time code is now integer. It is possible to change it to other format, e.g. "10.87".
The original idea was to give information to the user about the still "position" (e.g. 23, 46, 69 sec). It is possible to improve it, like 23.18, 46.36, 69.54, to give more precise information.

Q: "* When using 'start_frame=10&end_frame=20&still_per_mediafile=11', I expect still of '10, 11, 12, ..., 20'. Instead, the first still is of 10.833, and subsequent stills are slightly less than 1 second apart"

A: This is the planned behaviour.
When the user wants still_per_mediafile = 1, then the application gives back the middle frame:
|---------S---------|
If still_per_mediafile = 2, then:
|-----S------S------|
If still_per_mediafile = 3, then:
|----S----S----S----|
The other reason not to use the last frame is it causes error in ffmpeg, because "end of the file".
Also it is possible to change the behaviour like this:
If still_per_mediafile = 1, then:
|---------S---------|
If still_per_mediafile = 2, then:
|S-----------------S| and if end_time is the duration, then: |S----------------S-|
If still_per_mediafile = 3, then:
|S--------S--------S| and if end_time is the duration, then: |S-------S--------S-|

Q: "type=SCENE
* on my testvideo, I got only 2 stills, but I guess that at least 5 or 6 should have been made. I will test this again with some other videos, but like to now what tools are used, or what algorithm is used to conclude that 'a scene change happened', and a still created."

A: The application uses the lav2yuv program, that is part of the MJPEG tools, to determine the scene changes. It's algorithm based on the differences of frames (thresholds).
The scene changes has never be perfect. Lav2yuv sometimes detect more scene changes, than there are really, or less, as in your case. What we additionally implemented is a filter. It doesn't allow still creation shortly after the previous one. It is a safety element in the code not creating hundreds of stills with scene detection.

[MC-arjen]

The scene changes are refactured in 1.7.2. We still use lav2yuv, but the stills are generated by ffmpeg in one run, instead of 1 run per image. So basic performance is quite improved. The algoritme now first transcodes the video to a temporary file, then starts lav2yuv which generates a file with information about the frame changes, and then calls ffmpeg with this file. The images are stored in the same asset.

sidenote: It would be better to integrate the lav2yuv functionality in ffmpeg, as ffmpeg also has all available knowledge. The ffmpeg feature to support the lav2yuv format for stills could be given to the opensource community.