3 ms·

Can anyone on here speculate on how you might even start with this? Even using their heat map system, you'd have to run that same test on every frame (every fe

Can anyone on here speculate on how you might even start with this? Even using their heat map system, you'd have to run that same test on every frame (every few frames maybe) of every piece of copyrighted content uploaded. I don't consider myself a brilliant programmer, but I wouldn't even know where to begin on doing something like this at scale. Maybe you could index key parts of the frame and use that to narrow it down bit by bit (pun probably intended)? So confused...

jeffffff 16y ago
it's some sort of fuzzy hashing technique. you have to run through every frame of every video and compute a number that represents that frame. to make the match approximate you have to come up with a hash function that is resilient to small changes, either by throwing away information or by some other means. then you have to store this fingerprint of the frame. then every time someone submits a video you compute the fingerprints of the frames and check against the ones already in your database. Each check is constant time since it's a hash table. If any/enough frames match, label it as a copy!
j-g-faustus 16y ago
Here's a starting point, how to do it with music: http://www.redcode.nl/blog/2010/06/creating-shazam-in-java/ http://www.redcode.nl/blog/2010/06/creating-shazam-in-java/ You chunk a song into small segments and create a sort of "fingerprint" for each piece using Fourier analysis or similar. (So a song segment is represented by a frequency histogram, similar to this: http://www.flickr.com/photos/svartling/4229109164/ http://www.flickr.com/photos/svartling/4229109164/ ) The fingerprints are stored in a DB. To match a song fragment, chunk and analyze it in the same way. For each segment, find the closest match in the database. If most of the closest matches belong to the same song, and appear in the same order as in the song fragment you are trying to find, you have a match. Creating fingerprints from a series of video segments is roughly similar, Fourier can be used for 2D images as well. Doing it like this, you can reduce the volume of data you need to compare against with several orders of magnitude. Scaling to YouTube volumes is still hard, but that's the sort of scaling a company like Google already has plenty of experience in.
- robryan 16y ago
  What about slowed down or sped up video? The chunks would be of different size, I suppose cropping would be less of a problem as it would still match up best to the same movie. The shazam paper may have covered this but I read it a lot time ago, can't remember.
  - j-g-faustus 16y ago
    I don't know how YouTube does it in practice, but you could either - make the chunks small enough that they are essentially static images (one or a few frames) - use some form of dynamic chunking where a chunk lasts until the image is sufficiently different according to some metric. In both cases the chunks are fairly resistent to changes in speed, and the worst you need to deal with is that multiple chunks in clip A may map to the same chunk in clip B.
showerst 16y ago
This may be related to some form of perceptual hashing: http://www.phash.org/ http://www.phash.org/

jeffffff 16y ago

it's some sort of fuzzy hashing technique. you have to run through every frame of every video and compute a number that represents that frame. to make the match approximate you have to come up with a hash function that is resilient to small changes, either by throwing away information or by some other means. then you have to store this fingerprint of the frame. then every time someone submits a video you compute the fingerprints of the frames and check against the ones already in your database. Each check is constant time since it's a hash table. If any/enough frames match, label it as a copy!

j-g-faustus 16y ago

Here's a starting point, how to do it with music: http://www.redcode.nl/blog/2010/06/creating-shazam-in-java/ http://www.redcode.nl/blog/2010/06/creating-shazam-in-java/ You chunk a song into small segments and create a sort of "fingerprint" for each piece using Fourier analysis or similar. (So a song segment is represented by a frequency histogram, similar to this: http://www.flickr.com/photos/svartling/4229109164/ http://www.flickr.com/photos/svartling/4229109164/ ) The fingerprints are stored in a DB. To match a song fragment, chunk and analyze it in the same way. For each segment, find the closest match in the database. If most of the closest matches belong to the same song, and appear in the same order as in the song fragment you are trying to find, you have a match. Creating fingerprints from a series of video segments is roughly similar, Fourier can be used for 2D images as well. Doing it like this, you can reduce the volume of data you need to compare against with several orders of magnitude. Scaling to YouTube volumes is still hard, but that's the sort of scaling a company like Google already has plenty of experience in.

robryan 16y ago
What about slowed down or sped up video? The chunks would be of different size, I suppose cropping would be less of a problem as it would still match up best to the same movie. The shazam paper may have covered this but I read it a lot time ago, can't remember.
- j-g-faustus 16y ago
  I don't know how YouTube does it in practice, but you could either - make the chunks small enough that they are essentially static images (one or a few frames) - use some form of dynamic chunking where a chunk lasts until the image is sufficiently different according to some metric. In both cases the chunks are fairly resistent to changes in speed, and the worst you need to deal with is that multiple chunks in clip A may map to the same chunk in clip B.

showerst 16y ago

This may be related to some form of perceptual hashing: http://www.phash.org/ http://www.phash.org/