Evading YouTube Copyright Detectors Using Video Puzzles

Avoiding YouTube's Copyright Detection Subsystem using VLC's Puzzle Filter with Closed Captioning and Multiplexed Analogue Componants

Evading YouTube Copyright Detectors

Three Possible Methods Worth Consideration

Version DEC_2015_R312a

Method I


Using VLC's Video Puzzle Filter

With Closed Captioning (EIA-608, CEA-708)

[and Embedded 2d Barcodes]

Method II


Using

An Analogue Multiplexed Analogue Components CODEC

With

Closed Captioning (EIA-608, CEA-708) & 2D Embedded Barcodes

Method III


Using

An RGBV Edward Raymond Turner CODEC

With

Closed Captioning (EIA-608, CEA-708)&2D Embedded Barcodes

Can you find Frenimies?
Only the logo gives it away.

Method I


Using VLC's Video Puzzle Filter

With Closed Captioning (EIA-608, CEA-708)

[and Embedded 2d Barcodes]

The VLC Puzzle Method is not like this ...

Can you find Frenimies again?

Can you find Geek Charming?

Can you find Geek Charming again?

As you can see, a simple video transform can cause great confusion.

If you are a computer, the confusion created from the simplest transform can be total...

So then...
Why are videos with possible copyright claims not upped in a ever changing puzzle format?

Most YouTube users are Americans, and Americans are not that bright.

ALL Videos would have to be re-encoded before being upped. THEN decoded after being saved to disk.

There are significant video and audio synchronization problems in every scrambling system.

The puzzle encoding format alone does not at all fix the audio part of the YouTube Copyrighted Material Recognition Subsystem.

YouTube users would have to learn how to encode and decode the videos, and that takes time.

What is this VLC Puzzle Filter?

So what!
These problems are not really problems...

All video processing would have to be done in the "Progressive Domain" and the output format would have to be Progressive.

There would have to be a telex like signal indicating the state of the puzzle encoder for near real time resynchronization

Audio subband recoding might be needed on a small scale. Inverting 2 subbands may work, 4 in Stereo. In Stereo the subbands would have to be different in each channel.

This may require the use of some embedded bar codes.

Video metadata (aspect = 16:9; puzzle = 4x3; ...) is needed.

Scrambling : Is the Chroma, Luma or both (of a puzzle piece) negative? Make it hard for the detector...

Writing the "Puzzle Reverser" ... not an easy filter to write at first.

This is the VLC Puzzle Filter again...

Notable VLC Puzzle Filter Issues

The VLC Puzzle Filter (encoder, decoder; with CC parser and audio (encoder, decoder)) would have to be modified version of the code base of the existing filter.

The current Puzzle Filter should be left untouched with only its codebase used to prototype the block encoder-decoder here with its CC parser.

For VLC or other encoder-decoder sets (like CCCP) this should be a drop in filter with separate encoder and decoder settings.

What must the playback decoder do?

Overall : One would need to save the YouTube video to a local drive for this decoder to work in the 1st place.Programs that allow one to save YouTube videos are vital to the development and testing of this system.Recover the Sound & Vision. The recovered material should be viewable as is in real time with no delays.

Save the recovered video to disk in the Clear. If one fails to write a clear version of the video to disk one's drive will end up full of lightly encrypted video!

Decoding must be robust and fast. there should be no more than 500ms before the 'deblocked state' is recovered.

Source Video Coding must be so simple that it can be done in near real time or real time for writing a decoded copy to disk.

Video Coding Issues

Low Complexity Video Coding Systems are easier to decodeSome simplifications must be made mandatory for easier decodingSimplification 1 : Limit the puzzle to no more than 5x5 and all Clear states (on the granularity of block rows [ie : {1 2 3}]) are forbidden.Simplification 2 : Only move video blocks left or right of their original position, and specify the vertical and horizontal cut points.Simplification 3 : Video blocks CANNOT be rotated in any way.Simplification 4 : Only permit one block (puzzle piece) per Row to be Chroma inverted. Chroma + Luma inversion should be added when this is a mature coding scheme.Simplification 5 : The puzzle blocks should only change state rarely, say once ever 256 seconds or as quickly as 123 seconds (-/+) 5%.Simplification 6 : Metadata should fill up, but not overflow a standard terminal (80x24) line of text.Simplification 7 : Matadata should be limited to 1 line + checksum, with no line overflows permitted, and in CLEAN PRINTABLE ASCII.

Video Coding Issues (metadata)

The video block state & audio scrambler state and current local frame number metadata should update at 3 Hz for redundancy, initially 2 Hz for debugging. The current block state (and frame number) should be transmitted once per second as a bare minimum.

The future block state (if it is subject to change) should be transmitted once per second, but ALL future row states should be fully refreshed ever 2 seconds.

The video stream state (resolution, aspect, ) should be transmitted once per second as a bare minimum.

The audio scrambling state should be transmitted once per second.

ALL metadata should have a 2 or 3 digit checksum, hex coding is preferred for bandwidth conservation. Hex permits CRC12 or CRC13-BBC_LW.

Where to put the Metadata

There has to be a way of inserting a datastream into the video file that is free and cheap. The Closed Captioning (CC) signal meets these requirements completely.The CC signal is not heavily used in Internet video, so use it. The Language choice descriptor should be random, but not language of program. This is a potentially messy issue : no existing CC stream should be altered or interfered with in any way. However, a safe harbor (language or languages) should be used for carrying the scrambler metadata.VLC and most other video players use the close captioning signal when they can, so support is near universal. In essence, for this to work the CC stream must be spied on.

What is the MPEG CC data structure?
(For Internet Video, CC is embedded differently)

What is the Closed Captioning Character Set?

Video & Audio Metadata Coding

Coding practicesThe first 10 seconds of video should be in the clear.This practice gives a chance to fully setup the decoder at least 3 times.

Metadata coding practicesThe Metadata coding has to be robust and simple, but the order of the groups should always be random except for any checksum. Checksums should be at the end of each line.The CC encoding standard imposes about 32 characters per line, so the block scrambler state must be terse.There should be at least one metadata block per second, with an average rate of 50 chars per second.

Video & Audio Metadata Coding I

Suggested metadata groups (capital letters + numbers) :1. Aspect : A0 = 4x3; A2 = 16x9... only about 8 types needed

APPEND Frame Rate before Aspect Ratio!

1A = 24fps, 3A = 30fps, 5A = 29.9fps, 7A = 25 fps ...

2. Resolution R1 = 480i, R3 = 576i, R5 = 720p, R7 = 1080p3. Frame Number : Y:###### (base32; 277m; permit overrun) YV:###### announces when a video frame will change state YA:###### announces when audio scrambling state will changeCombined Frame Rate, Aspect Ratio, Resolution & Frame Number state identification

DEMO 1 : 2A2.R5.Y:123F20 (note coding of decimal Frame #)DEMO 2 : 1A0.R3.Y:97JQ (note terse coding of decimal Frame #)

Video & Audio Metadata Coding II

1. Block Allocation : PB10 = 3x3; PB15 = 3x4; PB17 = 4x3 PB20 = 4x4...; QPB## for announcing the next (future) block states but not the frame where the change takes place that is announced in the Frame Counter group.2. Row Allocation : {R1, R2; ..R5} ==> R#.##Row State Dictionary is from (1 ... FFF, hex); add X before R to announce the next (future) row state. The Frame Counter group will announce when the next change in video coding takes place.3. Audio State : Mono = M or for Stereo (SC1 or SC2) + 'bands swapped' (B01xB03) ==> C1.B02xB05; add J to the end to indicate the next future audio scrambler state.Demonstration syntax :PB10 R1.12 XR3.2 XR1.9 MB1xB5J ...PB15 R1.0F R3.32 XR2.1 SC1B3xB7 ...

The Row State Dictionary

In a 3x3 system for each row, there are only about 9 permutations = 9^(3 rows) = 729 states minus 3 clear states.In a 4x4 system for each row, there are a lot more permutations, and 5x5 systems are more complex.To save bandwidth, each row state should be given a numerical value.The numerical value that is equal to in the clear (1 2 3), (1 2 3 4) should be forbidden.

Video & Audio Metadata Coding III
Checksums & Multiplexing

Checksums will be needed to keep the transmitted data intact.CHECKSUMS ARE MANDITORY FOR EACH CODEGROUP.CRC12 or CRC13-BBC_LW is recommended.Checksum : K. + Hex(CRC(metadata_string))metadata_string (4 to 12 different kinds actually) ~= Frame (# + Aspect + Rate) + Block (Type + State) + Audio Scrambler StateSyntax example : K.135FMultiplexing Rules1. Current States > Future States [Audio or Video]2. A recommended Current : Future ratio should be 80:20 until a Audio or Video scrambling state is within 24 seconds then 20:80 and within 3 seconds of a change 100% future states.

CRC-13 BBC LW (1982)
Newly added to Wikipedia!

Metadata Coding IV

Version numbers+A## (Audio Scrambler); +V## (Video Block Encoder)+C## (Encoding System); +M## (Encoder Multiplexer)+RD## (Block Row Dictionary)At least one version number (of any of the above) should be announced each second using Round Robin rotation.When a video is loaded in an offline state, the CC stream should be parsed to find the version numbers before the content is played.

Metadata Coding V

In order for other decoders to be able to decode the block state datagram and recover professional quality video, the horizontal and vertical cut points must be specified

The number of cut points = blocks used (H or V) minus 1.

Suggested syntax

%1v.###, %2v.### Vertical cut points

%1h.###, %2h.### Horizontal cut points

The pixel cut point must be coded in Base32 in the most numerically compact way possible.

To compensate for times when the cutpoints are not known a low complexity edge detection filter must be used to find the cutpoints. At lower resolutions this must be done to resolve any ambiguity with the exact location of the cut points.

Metadata coding units

In order to keep syntax terse but meaningful to the decoder the following printable encoding schemes are permitted

Hex (aka base 16)

Base32 (Crockford: http://www.crockford.com/wrmg/base32.html) is for frame numbers and pixel cut points. But : No padding symbols or checksums (yet)!

Base32 is a notation for encoding arbitrary byte data using a restricted set of symbols which can be conveniently used by humans and processed by old computer systems which only recognize restricted character sets.

Base32 comprises a symbol set made up of 32 different characters, as well as an algorithm for encoding arbitrary strings using 8-bit characters into the Base32 alphabet.

Base64 initially should not be used until a more sophisticated syntax(maybe influenced by the Automatic Information System) can be developed.

Metadata coding, syntax ...

Can you find a better (readable) syntax for this purpose that is more bandwidth efficient? Free to try, but it may be difficult... Future state coding is OK, but still needs some cleanup and simplification. CC parsing is computationally cheap. Thus CC encoding has real countermeasure risks.Countermeasures must be ready from within the 1st six months of the use of this coding system being implemented

RTTY ancillary audio stream

The RTTY audio stream (separate audio stream, not audible) is another possible Digital Video feature worth trying.Creating an RTTY modem that is computationally inexpensive is reasonably easy. The RTTY decoding subsystem would however not be in sync with the CC datastream for decoder commands. There are sync issues here.A robust modem mode [that has some built in Error Correction] and a speed of 75 baud (or 300 baud) should be a default.

Video Encoding & Decoding Issues

Chopping video into blocks and coding them, then recovering a quality video signal is a video processing challenge. Audio coding has equivalent challenges.

If a video block is internal, it will have ringing and deringing issues on all of its edges. Screen edge blocks will have these issues on to of their sides.

Viewers can only tolerate 500ms of bad blocking. Large scale blocking used here is visually obvious, its elimination must be absolute.

MPEG systems in macroblocking mode can be tolerable but the blocks are smaller. This is not a true MPEG macroblock system, but must cope with its artifacts.

Audio Encoding & Decoding Issues

Inserting a linear jamming signal is not a good idea, this is not an analogue transmission system. Do it only if it works.

The audio coding must be independent of the many current audio coding schemes associated with video formats on the Internet.

There are about 5 common audio formats that YouTube (and others) can encode into a FLV, WebMedia so the artifacts of multiple audio encoding must be avoided where possible.

There should be a bare minimum of 7 to a maximum of 15 audio bands. The bands used should be based on the capabilities of the original audio. This means about 5 x 2 (stereo vs mono) encoder-decoder profiles.

The subbands that will be subject to swapping or inversion should be limited to 2 modified per channel in Stereo

This is not a working system yet!

This block scrambling system will have to be devised from scratch with the existing filters already mentioned and other software component libraries.

A custom puzzle filter (encoder and decoder) will have to be made from VLCs current puzzle filter.

The encoder-decoder work will have to be open sourced.

Initially this system will be a mess, but in 3 months a working model should exist.

Could this work elsewhere...

Video Puzzles would be a cheap way to get secure teleconferencing, without the huge overhead of standard cryptography.

For secure uses : there must be a secure IRC or CC link to transmit the puzzle and audio state.

This might take some tinkering to make it work...

Just because a solution is seemingly awkward, does not mean it will not work sometimes the best solution is the most bizarre one.

FYI
There is a new way to encode Digital Video
that does not use JPEG Macroblocks

JPEG based Macroblock coding used in JPEG video has been part of digital video coding standards since the beginning of digital video.

As digital video started in the early 1990s, that is nearly 25 years of defacto use.

However, for Error Correction and Signal to Noise Ratio reasons 8x8 macroblocks are an imperfect and rather inflexible solution.

When it comes to compressibility, the standard 8x8 macroblock size is almost too small. Coding Theory suggests larger macroblocks should be used.

In recent times, the solution has been to encode video with Wavelet methods.

However, Wavelets and DCT are good at compressing different aspects of a signal.

DCT compreses AC components best vs Wavelets compres DC componants best.

CODECs like Dirac have arisen out of attempts to fix the coding efficiency problem.

HVEC's Coding Tree Units (added to the standard in 2013) are the first attempt to use a larger coding unit that is in practical operation yet is not alien to DCT JPEG methods.

FYI : HVEC Coding Tree Units (CTUs)

HEVC replaces macroblocks with CTUs. CTUs can use larger block structures of up to 6464 pixels and can better sub-partition pictures into variable sized structures.

HEVC initially divides the picture into CTUs which are then divided for each luma / chroma component into coding tree blocks (CTBs).

A CTB can be 6464, 3232, or 1616 with a larger pixel block size usually increasing the coding efficiency. CTBs are then divided into one or more coding units (CUs), so that the CTU size is also the largest coding unit size.

The arrangement of CUs within a CTB is known as a quadtree since a subdivision results in four smaller regions.

CUs are then divided into prediction units (PUs) of either intra-picture or inter-picture prediction type which can vary in size from 6464 to 44.

The prediction residual (derived from the CU) is then coded using transform units (TUs) which contain coefficients for spatial block transform and quantization. A TU can be 3232, 1616, 88, or 44 pixel block sizes.

Method II


Using

An Analogue Multiplexed Analogue Components CODEC

With

Closed Captioning (EIA-608, CEA-708) & 2D Embedded Barcodes

There is no such thing as a
Multiplexed Analogue Components (MAC)
CODEC for Digital Video ...

JPEG based Digital Video never needed MAC

JPEG colour information is interleaved with monochrome information with the Discrete cosine transform

Because digital bits are used there is no temporal conflict to cause distortion of colour information


With A

Multiplexed Analogue Components CODEC

Using Closed Captioning (EIA-608, CEA-708)

&

2D Barcodes used by Mobile Phones

(JPEG) DCT vs MAC
Analogue Multiplexing is NOT JPEG

MAC transmits luminance and chrominance data separately in time rather than separately in frequency (as other analog television formats do, such as composite video).

The DCT transforms an 88 block of input values to a linear combination of these 64 patterns.

The patterns are referred to as the two-dimensional DCT basis functions, and the output values are referred to as transform coefficients.

What did the old MAC signal look like?

How did the old MAC system function?

What can be borrowed from MAC?

There is not that much that can be directly borrowed from the old MAC system

The separation areas for Chroma & Luma are still valid

You can't use a YUV system, the image processing costs are too high

Barcode set aside areas vs NICAM audio & crypto data

Aaach! There is no
Multiplexed Analogue Components (MAC) CODEC for Digital Video Broadcasting !

Someone will have to write an Open Source CODEC that can be used with

CCCP (Combined Community Codec Pack)

VLC

Other Codecs so that it can be used with players like GOM or Windows Media Player

The MAC encoding and decoding procedures will have to be different from any conventional digital video systems used today

This should not discourage anyone from trying, the technical hurdles are not infinite

The interoperability solutions are mostly common sense ones and not difficult

Multiplexed Analogue Components (MAC) Filter requirements for Internet Digital Video

All encoding must be ProgressiveHD 720p, 1080p and 4kp modes must be used exclusively

Chrominance (C) & Luminance (L) must be horizontally swappable, vertical swapping is forbidden

A working group must find ways of random block interleaving C & L; resolution/5 active video horizontal slices must be used

A 2 pixel boundary should be observed between C & L, the fill colour gradient can be random


Forbidden Practices

Any coding of Digital Audio in the Vision Domain, this is not analogue telly!

Excessive C or L compression, 4096 levels of quantization each must be the bare minimum

All 2d barcodes to indicate encoder state -- if used -- must be encoded to survive downsampling to 240p

More Forbidden Practices

Frame rate coding must be at least 20 fps, 24 to 30 fps preferred; 24 fps minimum

No Anamorphic coding! CPU use goes up & the video decoding delay is increased.

No rate sampling of C or L, it is too messy!

MAC grayscale encoding variation must be R=G=B!

No Colour in MAC mode!


Coding 3x4 video

Only 720p should be used, 1080p some 3 years later ...

The C & L should be next to each other

A '1 pixel' guardband between C & L must be observed

Otherwise encode same as 16x9


Encoding procedures

For all HDTV source material, 4k encoding is mandatory as provides more than enough room, for 4x3 : 720p is all that is needed

Because one is encoding onto a next higher resolution layer, there will always be space left over for transmitting encoder state in barcode form as indicated by D for data

It is okay to encode a saturation state for the video in a data block for film origin material


On 4k (UHDTV) encoding4K UHDTV (2160p) is 3840 pixels wide by 2160 pixels tall (8.3 megapixels), which is four times as many pixels as 1920x1080 (2.1 megapixels).

8K UHDTV (4320p) is 7680 pixels wide by 4320 pixels tall (33.2 megapixels), which is sixteen times as many pixels as current 1080p HDTV.

Using 4k mode to encode 16x9 origin material provides plenty of room for future changes

+ D can be filled with 2D barcoded data showing the CODEC state

ALSO : Up to 16 modes are available, here 12 are for future use

Stacked 2d barcode coding requirements for video downsampling

For each pixel generated by any common 2d barcode encoder, that pixel should be multiplied by 4 or 6

The lowest level of error correction is sufficient, but it will decrease the data capacity of the barcodes so terse MAC state coding is a must

Byte encoding at 8 bits per char (or 6 bits per char) is mandatory

Current and future MAC state barcode blocks must be interleaved with each other to fill all available space in the Data block area

Current state barcode blocks must be replicated at least 2x but 3x is preferred

Future state barcode blocks should be replicated at least 2x

A video frame, if frozen must be recoverable from the bar code information alone

Stacked 2d barcode coding requirements for video downsampling

A terse syntax is needed to convey current and future MAC state in a barcode

Mandatory

Version & Subversion, CODEC

Frame Number (FN)

MAC Block Encoding State (BES)

Audio State (AS), Future AS @ FN

Future MAC BES @ FN

Because barcodes have their own Error Correction, no chekdigit or checksum is required!

Each item encoded with a barcode should be unique to the barcode to reduce its size and complexity to allow for easier real time decoding

Mandatory for all

Version & Subversion

Frame Number

SeparableMAC BES, AS

Future : AS @ FN, MAC BES

An alternate audio encoding scheme suitable for MAC encoding

Decoding MAC video will be a greater strain than modified MPEG video. Not only must the MPEG video be decompressed, but the Chroma & Luma must be merged into RGB. Doing all of the extra decoding steps has a substantial CPU time cost possibly up to 10% extra CPU time may be needed. RequirementsAll audio encoding and decoding must be as simple as possible, yet still support Stereo and decodability after downsampling.

Any audio encoding scheme must be variable so as to allow for some encryption methods.

Variability is needed to fool or confuse the flawed and broken YouTube audio Copyright Detection subsystem.

An alternate audio encoding scheme suitable for MAC encoding

Solution

Upshift all Audio Frequencies at a variable frequency pivot point, using Gaussian Noise Replacement of all frequencies below the shifting frequency pivot point

All audio must be converted to 2.0 Stereo; Multichannel audio is forbidden

All frequencies in Left & Right (or Mono) must be shifted up in frequency between 1234 Hz and 2345 Hz by exactly the same frequency

Ideally, the Shifting Frequency should change every 31 to 67 seconds

All frequencies below the frequency upshifting point must be replaced by a varying intensity Gaussian noise source that gets filtered out during playback

Quirk : about 2 khz of the upper frequencies may be lost, but for 44.1 kHz origin material this may not be be noticeable by most people

Quirk : this will require a uniquely sharp filter at the encoder and decoder, with at best a 100 hz falloff zone;

Quirk : version tracking of the encoder is required for the filter decoding stage

MAC Input & Output Considerations (I)

YUV Coding, for MAC web video encoding, regardless of the sampling mode means that there will have to be 3 pixel block reads for each output pixel block.

A 3:1 YUV encoding and decoding ratio has a high computational and time cost, and video file decoding delays cause end user confusion

MAC Input & Output Considerations (II)

For encoding a 4:5 or 16:9 MAC colour image into a larger pixel format in monochrome, some padding will be needed.

The geometries of Normal and Widescreen video are very different.

Safe Zones will be needed for MAC encoding.

Areas will be needed for the 2d embedded barcodes that will have the needed MAC decoding information.

Although there is plenty of room to use the Closed Captioning signal to announce the current or future MAC encoder state, 4k encoding allows for enough room to put barcodes into the video away from Chroma or Luma information

The barcode probably best suited for this is a stacked 2d rectangular type namely : Aztech Code, QR Code, Micro QR Code or SPAR QCode

Barcode encoding must support 7% or equivalent error correction


Method III


Using

An RGBV Edward Raymond Turner CODEC

With

Closed Captioning (EIA-608, CEA-708)&2D Embedded Barcodes

Who is Edward Raymond Turner?

Edward Raymond Turner was the inventor of the 1st colour film system that was functional and workable, c1902 to c1905!Some 10 UK film shorts recorded with this system have been recovered and restored to the 24/3 = 8 hz colour resolution.

Colour phase delay issues aside this colour encoding system really worked!

MAC Methods for RGBV (Raymond Turner)

As opposed to using YUV encoding of an image in a 2k or 4k space, RGB can be used instead.

To be loyal to the ideas of Edward Raymond Turner, the RGB domains should not be subsampled.

Blue-Violet should be an alternate colour as it may code some material better.

MAC Methods for RGBV (Raymond Turner)
4:3 Material

Some 3 x 4:3 apertures must be into a 2k HDTV pixel space, and still have one 4:3 aperture space left over for near instant decoding information in 2D barcode form.

RGBV should be randomly position switched every 15s to 99s.

The 2D barcode should contain a signed 32 bit frame number (x2 or x3 for error correction)

NON-INTERLACED CODING ONLY!

PREFERRED

50 fps for 50hz (or 24 fps film) material

60 fps to 100 fps for all other material

Technical Reference Annex

QR Code design notes

QR Code Design Notes (II)

QR Code Design Notes (III)

QR Code Design Notes (IV)

There is always BitTorrent, or not

Canadian TV Series with no Complete Series HDTV torrents anywhere.If you can, please mount the compete series as a public torrent.

Mr Young Winging It What's Up Warthogs? How to Be Indie Fries with That?The Latest Buzz

Canadian TV Series with no HDTV torrents
Please mount the compete series as a public torrent!

Canadian TV Series with no HDTV torrents

Australian & NZ Series with no HDTV torrents

NZ Series with no HDTV torrents

In an age before Rogernomics, and well before The Office there was the afternoon tea fund, Golden Kiwi, and 16:00 closing: welcome to the early 80s world of the New Zealand Public Service.

Gliding On (1981 - 1985) was the first NZ sitcom to become a bona-fide classic.

The series was inspired by Roger Hall's hit play Glide Time and satirized a paper-pushing working life then-familiar to many Kiwis.

Gliding On won several Feltex Awards including best male and female actors and best entertainment.

Sony NZ have released a series called Kiwi Gold a selection of Kiwi TV shows from the 70s, 80s & 90s on DVD. The official release date was 10 NOV 2013 .

Volume 2 of Kiwi Gold, has 2 episodes of Gliding On, including the above episode No smoke without fire ...

Telly produced in NZ -- no torrents found!

Hulu : A crime-fighting duo attempts to thwart Napoleon's advances to the West Indies. (after 1800)

Long before 2012 and the 200th year since The 1812 War, this show was the only comedy about the era just before this war.

In English language television, it is still a strange creature.

Torrents of series totally missing ...

Documents

Evading YouTube Copyright Detectors Using Video Puzzles