[Ssc-dev] scrum/design notes from yesterday

Mon May 28 19:47:46 EDT 2012

I implemented the temporal blur and alpha-blending the blur and did some
size tests:

Taking a 38 second H264 video 960x522 @ 25fps
I first transcoded the video to MP4 (keeping the audio unchanged)
Then I blurred out a (large) face throughout at different locatoins and
pixellated or colour-filled a few other regions. the redacted video keeps
the sound track and the unredaction track is silence (black except for the
regions redacted in the other video)
                 MP4  Gzipped
Original     4331780  4319099
Transcoded   2315600  2017631
Redacted     2290469  1913402
Unredaction  1334545   689893
The output is a substantial loss of visual quality, as you might expect
from the direct transcode being half the size. The redacted video is
slightly smaller. The Unredaction data is half the size but when gzipped is
1/3 of the size.

Here's the redaction descriptor file: (also attached)
# This is a test of redaction with blurring.
# Run with e.g.
# ./ffmpeg -y -i test.mp4 -filter_complex 'redact=blurbox.txt [dump] [out]'
-map '[dump]'  -map "0:1" -acodec copy 'outputa.mp4' -map '[out]'
'outputb.mp4'
# Writes two files outputa.mp4 containing the original audio track and the
# redacted video.
# outputb.mp4 contains the original video in the regions redacted out of the
# other track.
seed 8978
0,1,-20,200,-10,200,blur
0,4,150,250,150,250,black
1,2,200,400,0,200,blur
2,3,200,400,200,400,blur
3,4,0,200,200,400,blur
4,40,760,960,322,522,blur
0.5,1.5,450,500,80,300,green
1.5,2.5,500,550,80,300,white
2.5,5,550,600,80,300,blue
1,40,100,400,400,800,pixel

I attach the outputa & outputb files (limited to 100 frames each).

Let me know if you have any questions / feature requests.
The code can certainly be made faster (lots of float operations that could
be int) though I don't know how much. It runs (writing both streams) at
about 78fps on my lenovo x200 on battery
Andrew

PS to run on an old ffmpeg the same effect can be achieved by running it
twice:
This says it runs at 30-32fps, so perhaps the 68fps is the sum of the two
output fps rates in the former example.
./ffmpeg -y -i test.mp4 -vf 'redact=blurbox.txt [d] [out], [d]nullsink' -an
outputb.mp4
./ffmpeg -y -i test.mp4 -vf 'redact=blurbox.txt [out] [d], [d]nullsink'
-acodec copy outputa.mp4

On Fri, May 25, 2012 at 1:21 PM, Andrew Senior <andrew.senior at gmail.com>wrote:

> Sorry I didn't make it yesterday. Things were rather hectic.
> Thanks for the summary. Lots of good progress everywhere!
>
> I made progress on my avfilter and now have a working filter that has two
> outputs - one redacted data (like before) and the other the data needed to
>  unredact.  I'm working on making the blurring time-smoothed and more
> visually appealing.
> As I understand it, the filter can be run to produce either output stream
> in older ffmpeg builds, or with the latest version both streams can be
> written simultaneously to different files. With the right codec, the
> unredaction data should be highly compressible.
>
> Andrew
>
>
> On Fri, May 25, 2012 at 11:24 AM, Nathan of Guardian <
> nathan at guardianproject.info> wrote:
>
>>
>>
>> 1) We've come up with a name for our data format: JSON Evidenciary
>> Mobile Media Metadata Format or JEM^3 or just JEM!
>>
>> The idea is to say "mine the JEM" or "extract the JEM" or "bundle the
>> JEM" or "Download the JEM".
>>
>> Full publishing of the proposed JEM v1.0 Spec is imminent as part of our
>> goals for June 18th meeting with IBA.
>>
>> 2) Aside from our partners at UC Berkeley, we also want to get UStream,
>> Bambuser, YouTube and other partners who may have rich metadata already
>> being captured and stored to supporting exporting in JEM format.
>>
>> 3) Harlo shared her server/API submission protocol format. At this
>> point, each trusted party you will submit to is expected to host a
>> server that supports a known set of HTTP/S based calls. After some
>> review, feedback we came up with the following... Harlo is working on a
>> more detailed version of this, but I wanted to get my notes down.
>>
>> ** We should move all this to the dev site wiki, but again for now, just
>> blasting them to the list **
>>
>> - the hash of the unredacted file will be used the key to link all
>> ongoing conversations, interactions around that file. there is no other
>> id, or user/pwd needed to communicate. however, if a OpenPGP public key
>> id is submitted along with the hash, then all communication will be made
>> using that public key.
>>
>> - as soon as possible, there needs to be a /submitHash call to begin the
>> chain of custody, verification of unredact format. This can also be
>> submited via SMS or email if HTTP/S call is not available. This is where
>> the OpenPGP public key id can be provided for future interaction,
>> tracking across submissions.
>>
>> - the /submitUpload is an HTTP/S POST with some ability to resume and
>> handle low-bw/high-latency connections. This is where the unredacted
>> media file and JEM will be submitted. Ideally this is encrypted to the
>> Trust Party public key, and signed by the submitter's public key. This
>> will be built directly into InformaCam for now.
>>
>> - finally, there is a /getMessage?hash capability to check for
>> messages/responses from the Trusted Party to the submitter. This is
>> ideally encrypted via OpenPGP public key.
>>
>> 4) Deployment: for now, it is recommended that the Trusted Party Repo is
>> hosted on a desktop/laptop running Ubuntu with encrypted disks,
>> physically hosted on premise at the Trusted Parties legally owned
>> location. Access to the machine will be through Tor Hidden Services via
>> an HTTP/S .ONION address. This means there is no worry about NAT'ing or
>> public IPs, and the true location of the Repo is not exposed.
>>
>> In addition, media will be kept in its OpenPGP encrypted format, and
>> only unlocked when the user enter's the password for their private key.
>> Private keys can also be stored on a USB drive, such that they are only
>> available for decryption when that drive is inserted.
>>
>> 5) We are really excited about the Rashoman UI prototype shared by
>> Aphed, and want to provide a JEM with location and other sensor data in
>> it, to begin playing with integration of mapping, compass heading, etc.
>>
>> 6) Hans and Nathan have been making great progress on IOCipher virtual
>> encrypted file system, and SyncSafe, the first app to use IOCipher as an
>> encrypted file/media store. SyncSafe provides another way to safely
>> store and transfer InformaCam exported Media+JEM bundles. Stay tuned for
>> more progress on this.
>>
>> 7) Nathan (me!) made good progress on ObscuraCam v2 - photo editing side
>> has improved UI that works well on ICS 4.0/tablets now. Video side now
>> supports audio. Another round of tuning/tweaking the region
>> management/editing updating is still needed. Another 8-16 hours of dev
>> work estimated.
>>
>> 8) Guardian has started the Mobile Reporter project with Small World
>> News (Alive.in) and Free Press Unlimited. There is a great deal of
>> overlap of core components with SSC, and all will benefit from this, as
>> long as we can work out how to build these things in a modular,
>> platform-centric way. In short, we need to create our uber platform
>> block diagram for all of this work, and start thinking of it in more of
>> that manner.
>>
>> That's all I have for now!
>>
>> +n
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ssc-dev mailing list
>>
>> Post: Ssc-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>
>> To Unsubscribe
>>        Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>        Or visit:
>> https://lists.mayfirst.org/mailman/options/ssc-dev/andrew.senior%40gmail.com
>>
>> You are subscribed as: andrew.senior at gmail.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20120528/8499f87c/attachment-0001.htm>
-------------- next part --------------
# This is a test of redaction with blurring.
# Run with e.g.
# ./ffmpeg -y -i test.mp4 -filter_complex 'redact=blurbox.txt [dump] [out]' -map '[dump]'  -map "0:1" -acodec copy 'outputa.mp4' -map '[out]' 'outputb.mp4'
# Writes two files outputa.mp4 containing the original audio track and the
# redacted video.
# outputb.mp4 contains the original video in the regions redacted out of the
# other track.
seed 8978
0,1,-20,200,-10,200,blur
0,4,150,250,150,250,black
1,2,200,400,0,200,blur
2,3,200,400,200,400,blur
3,4,0,200,200,400,blur
4,40,760,960,322,522,blur
0.5,1.5,450,500,80,300,green
1.5,2.5,500,550,80,300,white
2.5,5,550,600,80,300,blue
1,40,100,400,400,800,pixel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outputa.mp4
Type: video/mp4
Size: 392590 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20120528/8499f87c/attachment-0002.mp4>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outputb.mp4
Type: video/mp4
Size: 211290 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20120528/8499f87c/attachment-0003.mp4>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vf_redact.c
Type: text/x-csrc
Size: 21381 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20120528/8499f87c/attachment-0001.c>