Detect scene change using x264 1st pass

[Lele-brz]

Hi all,
I'm looking for a way to detect scene changes, since I'm using x264 to encode the video I was wondering if I could reuse the statistics of the first pass to detect scene changes.

Thanks for any help
bye

[kemuri-_9]

if you have scenecut activated (the scene change trigger) and a high max-keyint (to allow large GOPs between scene changes),
in the statistics file all the frames listed as type:I or type:i will be scene changes.
the value you specify for scenecut (or using the default 40) will determine how aggressive it is in finding scene changes.
however!
If you use multiple threads (--pre-scenecut is activated with multiple threads), then you are degrading the scenecut decision, so only use 1 thread if you want more accurate results.

[Dark Shikari]

if you have scenecut activated (the scene change trigger) and a high max-keyint (to allow large GOPs between scene changes),
in the statistics file all the frames listed as type:I or type:i will be scene changes.
the value you specify for scenecut (or using the default 40) will determine how aggressive it is in finding scene changes.
however!
If you use multiple threads (--pre-scenecut is activated with multiple threads), then you are degrading the scenecut decision, so only use 1 thread if you want more accurate results.Untrue. Pre-scenecut isn't inherently worse; in fact, I'd say its more accurate as to detecting actual scenecuts.

But remember, scenecut is designed to optimize efficiency--not to optimize detection of real scenecuts. So, for example, scenecut bases its decision on the distance until the next planned IDR frame, etc, etc.

[kemuri-_9]

I'll have to look at some of my stat files then, as I generally get 40% more I-frames on my settings with --pre-scenecut than w/o.
see which one is more accurate with the decisions.

[Lele-brz]

Thanks,
would it be better to use pass1 and parse the stats or something else?

Would a command line like the following is ok:

--pass 1 --keyint 999999 --scenecut 40 --bitrate 440 --stats output.stats --threads auto --thread-input --output NUL input.avs

[Dark Shikari]

With that kind of keyint you might want to raise scenecut threshold.

[Lele-brz]

In my case I just want to detect the scene changes for generating a kind of index of the clip.
Since I guess that the x264 is already calculating motion vectors, maybe SAD I would like to reuse them for my purpose.

when I parse the statistics generated by pass 1 I get :

in:112 out:109 type:P q:10.00 tex:10590 mv:368 misc:202 imb:8 pmb:51 smb:517 d:-;

I guess in and out are frame numbers
type: the suggested frame type (not sure if 2 pass will confirm that)

for the others I have no idea, not even sure that there's something I can use for my needs.

Thanks

[kemuri-_9]

2nd pass uses the frame decisions decided in 1st pass what was put into the stats, it doesn't alter them any.

[Lele-brz]

I'm trying with different parameters and I'm getting interesting results.

As first pass I'm using: (missing ones use defaults)
--subme 1 --bframes 12 --analyse none --me umh --ref 1 --weightb --keyint 5500 --scenecut 190

As explained in this post:

http://forum.doom9.org/showthread.php?t=140170

I noticed that slow fade in - fade out are not always selected as IDR frames.

Now, I know I'm abusing x264 to get something that it's not in its purpose, but is there a way to detect fading by analyzing B-frames with weighted prediction?

[Quark.Fusion]

--b-adapt 2?

[lovelove]

In my case I just want to detect the scene changes for generating a kind of index of the clip.
Have you been able to solve this, Lele-brz? If yes, could you please post the solution here, so that others can benefit as well? (I am also looking for ways to create an index file of a clip). thank you.