screencut detection

[juGGaKNot]

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=e8b83b788ffe9af4b48b049450c387069fda1266

Also handles cases of tons of short scenes in sequence and avoids making those scenecuts as well.

scenecut

Integer: 40

Sets the threshold for IDR frame placement (read: scene change detection).

x264 calculates a metric for every frame to estimate how different it is from the previous frame. If the value is lower than scenecut, an IDR frame is used. The metric is slightly more complex than this, but it's a reasonable approximation. Higher values of scenecut increase the number of scenecuts detected.

So, for a source with alot of scene changes should i set scenecut to a lower value ?

[Dark Shikari]

No, where does it say that?

[juGGaKNot]

if

Higher values of scenecut increase the number of scenecuts detected.

and

Also handles cases of tons of short scenes in sequence and avoids making those scenecuts as well.

than

i was thinking that for a source with alot of scene changes i should set scenecut.

Before i read the commit i was thinking that a higher value detects more so called "flashes" and helps but now i see "cases of tons of short scenes in sequence and avoids making those scenecuts" so if in small scenes it avoid making scenecuts for better quality a higher scenecut value would not let it do that.

[Betsy25]

If I understand correctly, it defaults to 1 frame, which seems quite unrealistic imho, for example lot of thriller/horror movies have flashbacks, which take some 5 to 10 frames.

[Dark Shikari]

If I understand correctly, it defaults to 1 frame, which seems quite unrealistic imho, for example lot of thriller/horror movies have flashbacks, which take some 5 to 10 frames.The only way to catch those is to do a very long-distance analysis, which takes a lot of CPU time. I didn't want to increase runtime, so the only way you can get such long analysis is by using lots of B-frames.

[juGGaKNot]

The only way to catch those is to do a very long-distance analysis, which takes a lot of CPU time. I didn't want to increase runtime, so the only way you can get such long analysis is by using lots of B-frames.

So 16 b-frames with b-adapt 1 is better than 3 b-frames with b-adapt 2 for this kind of source ?

[Dark Shikari]

So 16 b-frames with b-adapt 1 is better than 3 b-frames with b-adapt 2 for this kind of source ?No...

[LoRd_MuldeR]

So 16 b-frames with b-adapt 1 is better than 3 b-frames with b-adapt 2 for this kind of source ?

Can only catch flashes of 1 frame in length with b-adapt 1.
With b-adapt 2, can catch flashes of length --bframes.

http://www.soadfans.de/forum/images/armageddon/smilies/tja.gif