PDA

View Full Version : Tool for finding Shit+freeze frames


BiaTch 5.0
9th October 2003, 03:17
Is there a tool that analyzes DivX 3.11a files & finds Shit/freeze frames?

esby
11th October 2003, 02:20
Technically...

Two cases:
* You have a clean source and you want to clean an encode you did...
* You have a shitty raw and you want to detect shit on it...

The first case is somewhat typical,
the second tends to be seen less & less
since raws encoders are not using anymore divx3.11 most of the time.
(From what I'm seeing in fansubs.)

To answer your question:
First case can be done via measuring max noise between source & encode on 8*8 block.
Second case is crazy and cannot be done easily.
(that would mean analyse average value of 8*8 blocks,
analyse the neighbouring for each blocks,
and make a decision with that kind of stuff...,
meaning possibility of not detecting blocks & detecting blocks when they are none.)

Now for speaking of divx3.11 alpha files.
General case: ( avi - div3)
Using a DRF analyser like GSpot to detect specifical but known problems:
Search for frames using DRF>15,
if there are any there are probably shitted, of course the ugly DRF=32 are the queen of this category.

Special case: Files encoded with nandub ndy - esby.free.fr
the modded nandub create lbk files storing various informations,
including the 'noise' detected,
you can use lbkiller (on the same page), to watch the lbk
and check more easily the frames that might be shitted.
Since the antishit in Ndy version is a bit more effective than rc2,
you probably won't find any shitted frame, unless you are unlucky
or wanting too much from the codec (eg: using 250kbits/s with himotion scenes).
The main drawback is that the encode is slower.

esby

Edit: From a drf view,
shitted frames can be :
* drf=2,3,4 with encoder bug
making these like shit with luminance inverted block
somewhere in the image.
* drf>16, due to a bug in nandub antishit, the algo looping back
increasin drf till he find a better image (theory),
in practical he tries to find the better image, but cannot find one,
and use the last he tried drf=32 most of the time, meaning an ugly zoomed like frame.

The first kind of bug cannot be detected by just drf, while the second can.