GFY EDUCATIONAL SERIES: How to prevent Piracy - A new way.

[borked]

Too slow unfortunately. To make it practical, it should do at least a billion comparisons/hour.

well, to be fair, this is running on a dev server that is about 5 years old. Shit, it takes me about 15 minutes to compile ffmpeg whereas on a new quad core, it's compiled in ~15 secs.

Plus, there could be many instances of the app running - no need for a single fork to be doing all the work...

And of course, you would only search for comparisons after searching for pages that flag your keywords... you wouldn't have to search ALL photos on ALL sites

--edit

ok, I see what you mean - pairwise comparison of a single photo with all your photos.

Can you send me a zip with some photos in (more the merrier, but try to keep the zip <5MB) and a test image to compare against? The script will run *much* faster comparing 1 photo to many than doing 1on1 comparisons...

[borked]

Nearly everything I have tried doing has been with an aim of keeping the image as close to the original as possible and get it to pass as NO PIRATE.

Just think that to make your comparison test as good as possible I need to to be trying to think of a way I could get a whole photoset to pass while still having it acceptable to the human eye.

Similar to what I said above, you could lower the level to whatever is satisfactory to *not* let false negatives through, which would allow more false positives to show up. However, I suppose this stuff is with the view to scan loads of images per hour and to flag ones that require further intervention by a human eye.

Automated scripts will always cause false negatives and positives, but false negatives are much more costly. Much better to let a human brain search through the results flagged as pirated and toss away the false positives, than it is to allow false negatives slip through.

But yes, you're right - if a photoset contains 15 images - it only takes 1 to be flagged as pirated to raise the alarm bell on the photoset.

[Nautilus]

well, to be fair, this is running on a dev server that is about 5 years old. Shit, it takes me about 15 minutes to compile ffmpeg whereas on a new quad core, it's compiled in ~15 secs.

Plus, there could be many instances of the app running - no need for a single fork to be doing all the work...

And of course, you would only search for comparisons after searching for pages that flag your keywords... you wouldn't have to search ALL photos on ALL sites

Is is possible to estimate it's maximum productivity on a good modern server, and take into the account both server and script optimization (multi threaded mode or some other tricks)?

I understand that you need to optimize where you search and what finds you're going to compare, but still - we have a database of about one million pictures to protect, camparing against this db by 1Kpics/hour is kinda not going to work. Even 100K/hour not going to work.

[Relentless]

A good post and an excellent read. Thanks.

The only problem with it is the part where you wrote "The only way to "rip" your stream is to have a screen capture program record full playback of your move. Impossible to prevent that!" That's a very weak Achilles heel to the whole 'solution.' It means essentially, YES your videos can still be pirated. And once *anyone* does it, they have a pirated version of the video which they can use to propagate tubes, torrents and other p2p media exactly the same way they would have if they had downloaded it. The basic problem is that you only need 1 competent thief and all the incompetent ones get access to whatever he stole exactly the same way as if they stole it.

[brandonstills]

b - if we didn't permit downloads, but made sure the movies you like were always available, in full, for 1 year even after you cancelled your membership at some point in the future, would you consider cancelling your membership (15% said they would consider cancelling)

This allows you the opportunity to upsell and try to re-convert them as welll.

[borked]

This allows you the opportunity to upsell and try to re-convert them as welll.

this is exactly what has been implemented - great return rates on those coming back and trying to view a movie they are not entitled to view...

Blocking users from logging in simply because their pass expired is dumb... give them the members area but on trying to view something that they are not entitled to view... upsell, like you said

[borked]

Is is possible to estimate it's maximum productivity on a good modern server, and take into the account both server and script optimization (multi threaded mode or some other tricks)?

I understand that you need to optimize where you search and what finds you're going to compare, but still - we have a database of about one million pictures to protect, camparing against this db by 1Kpics/hour is kinda not going to work. Even 100K/hour not going to work.

Yes, I think I have a way around that... pre-calculate all your images before hand and dump the floating hash. That way, the app simply has to calculate from the single image and compare it for likeness to all the pre-calculated ones.

Let me see if that's possible - that should speed shit up *enormously* (well, except for inital calculations on you image stock). I will put that on "to do" for next week as I'm a bit loaded up atm due to time I wasted in doing this app

[borked]

A good post and an excellent read. Thanks.

The only problem with it is the part where you wrote "The only way to "rip" your stream is to have a screen capture program record full playback of your move. Impossible to prevent that!" That's a very weak Achilles heel to the whole 'solution.' It means essentially, YES your videos can still be pirated. And once *anyone* does it, they have a pirated version of the video which they can use to propagate tubes, torrents and other p2p media exactly the same way they would have if they had downloaded it. The basic problem is that you only need 1 competent thief and all the incompetent ones get access to whatever he stole exactly the same way as if they stole it.

then watermark your streams with the user's username, IP etc - this was discussed in the thread. It's impossible to stop a screen grabber from ripping your streams, but you can deter it perhaps

[DWB]

Timely bump for people to digitally fingerprint their own content easily...

I just heard the FSC, Mansef and Top Bucks just put a hit out on you.

I really do find it extremely amazing that there has been only one person to date that has actually contacted me to discuss wanting to implement things discussed in this thread on their sites.

I only see a handful of people interacting in a serious thread that is highlighting how to combat it

You know I'm waiting patiently.

Just sent you mail BTW about your dog pic.

[DWB]

this is exactly what has been implemented - great return rates on those coming back and trying to view a movie they are not entitled to view...

Blocking users from logging in simply because their pass expired is dumb... give them the members area but on trying to view something that they are not entitled to view... upsell, like you said

How do you implement this with 3rd party billing? At least for an upgrade back into the site after they cancel, I don't think that is possible unless you have their date and your own merchant account, correct?

Don't have to go into details here, can shoot me an email.

[PXN]

Clearly a way better and cheaper solution that FSC/APAP fingerprinting approach.

Great post borked!

[borked]

Clearly a way better and cheaper solution that FSC/APAP fingerprinting approach.

Great post borked!

well, to be honest, the solutions are not really comparable...

The OP was designed at *preventing* content ever being able to get uploaded. Then it evolved to involve injecting use data to track the pirate down, then it evolved to finding copyrighted content to help automate the process in finding copyrighted content already out there.

The FSC solution is to prevent content getting onto those tube sites that are a part of the circle, which I'm not too hot about since that leaves the others free to do as they please.

Let's just say they are complementary approaches to the same goal.

My goal is to evolve the thread to be able to detect movies, but that I fear may never happen outside of a "proof of concept" sandbox due to the bandwidth involved, but hey, I can surprise myself sometime

All this knowledge btw is already out there in forms of scientific papers who have shown ways to detect identical/similar images/videos. The hard part is implementing it in a real-world cost-effective situation.

[borked]

You know I'm waiting patiently.

shit, I knew someone would pick up on that post!
I just posted that in sheer frustration when I was tired and thinking to myself "why am I even bothering with all this frikken complicated shit?"

damn time-sensitive edit gfy button!

[chronig]

A good post and an excellent read. Thanks.

The only problem with it is the part where you wrote "The only way to "rip" your stream is to have a screen capture program record full playback of your move. Impossible to prevent that!" That's a very weak Achilles heel to the whole 'solution.' It means essentially, YES your videos can still be pirated. And once *anyone* does it, they have a pirated version of the video which they can use to propagate tubes, torrents and other p2p media exactly the same way they would have if they had downloaded it. The basic problem is that you only need 1 competent thief and all the incompetent ones get access to whatever he stole exactly the same way as if they stole it.

Hopefully some vid quality will be lost in the doing --- and watermark the vidz and persue the original capturer later

[borked]

Is is possible to estimate it's maximum productivity on a good modern server, and take into the account both server and script optimization (multi threaded mode or some other tricks)?

I understand that you need to optimize where you search and what finds you're going to compare, but still - we have a database of about one million pictures to protect, camparing against this db by 1Kpics/hour is kinda not going to work. Even 100K/hour not going to work.

brandonstills gave me an idea in another thread...

and yes, I've sped things up by 1000x

this is having pre-hashed all your images (which is kinda slow at ~0.1/sec, but new images can be easily added to the db, just the initial compile is going to be slow) and then comparing 1 image against this hash db:

time taken to compare 55 pre-hashed images: 0.120398044586 seconds (~1644544 images/hr)

And that is on my crappy PowerEdge 1850

About as good as it's going to get


--edit
if someone wants to verify that calculation of images/hr based on
intval( 3600 / ( (1 / 55) * $time )
cos my brain is really fried!