x264 settings for video slideshow?

[wiseant]

Hi

I am working on a video slideshow application
I presume that the video clip sizes will range from 1920x1080 down to 320x180
Right now, the user has the option of choosing up to 46 different transitions.
The user needs to set the number of frames that each image has as well as the number of frames for the transition overlap

For example, my default settings are an Imagesequence of 48 frames and a transition overlap of 24 frames. What this means is that the image will display for 24 frames, then the transition will display for 24 frames, then the second image will appear, etc, etc.

The formula for determining the total framecount for x number of unique images is

((ImageSequence + ImageSequence - overlap) * NumberofImages) - (ImageSequence - overlap) = NumberofFrames

so, with a folder of 1000 images, an Imagesequence of 48 frames and a transition overlap of 24 frames, the total framecount is

((48 + 48 - 24) * 1000) - (48 - 24) = 71976 frames at 24 fps = 49 min 59 secs

if the user wants to encode to DVD or Bluray specs - I need to setup HCEnc and x264 to conform, but if the user just wants a 264/mp4/mkv clip I am wondering if I use options for x264 encoding like --min-keyint = to the number of frames for the transition overlap, and possibly, --tune stillimage, --no-scenecut, --no-deblock if it will make a difference in encoding efficiency / quality?

My concern is that in the above case the first 24 frames are identical, but the next 24 frames will each have a different amount of transition effects applied to it

Right now, I am just using

cd c:\x264
x264.exe --crf 20 --threads 2 --preset superfast -o "transition.264" "c:\transition.avs"
c:\x264\MP4Box.exe -add "transition.264" -new "c:\transition.mp4"
pause



I have a sample for download at mediafire: 12.6 MB, 448x252

http://www.mediafire.com/download/p6t3r94a6upw3da/slideshow.mp4


TIA

[Emulgator]

I would say that the permanent transitions render the assumption "--tune stillimage" useless,
because fades are all over the place, but well, try it...

[wiseant]

@Emulgator

I haven't tested "--tune stillimage" - but yeah, I don't think it would work because of the transitions. I need to test the other settings - I was hoping to get some guidance regarding --no-scenecut, --no-deblock - or other settings that might have a positive impact . . .

[Asmodian]

I assume lowering --min-keyint, using --no-scenecut, or using --no-deblock will only lower encoding efficiency / quality. All of those are quality / efficiency improving features and I see no reason a slide show with transitions would improve without them.

[kotuwa]

Looks like too late... But replying anyway since I have Questions (and answers!) :D


I am working on a video slideshow application
.....

--tune stillimage, --no-scenecut, --no-deblock if it will make a difference in encoding efficiency / quality?

Right now, I am just using

cd c:\x264
x264.exe --crf 20 --threads 2 --preset superfast -o "transition.264" "c:\transition.avs"
c:\x264\MP4Box.exe -add "transition.264" -new "c:\transition.mp4"
pause


Efficiency comes in different forms.
For size efficiency (and also quality) using something like --preset veryslow or --preset slower will help a lot, rather than using --preset superfast.....

And --crf 20 seems too low for default or only quality setting. Most of the time it will show artifacts!

Better if the app gives options to select Speed and Quality.


--tune stillimage ... no idea it is meant for still still images or moving stillimages! lol... it gives high psy values, high aq-strength... low deblock... most of them seems unnecessary I think....
--no-scenecut, will give speed!
Scenecut (not disabling) might help if the energy of the show is high!
--no-deblock, i have no idea... probably can be situational!


Apart from those, I think using a higher --merange value will help in slideshows. Can someone confirm?
Also higher --bframes may help... Slideshows has similar forward frames, but they do not have same frame in a forward frame unlike in anime though!.. Still bidirectional frames would help right?
:)