Evading YouTube Copyright Detectors

Three Possible Methods Worth

Consideration
Version DEC_2015_R312a

Method I
Evading YouTube Copyright Detectors
Using VLC's Video Puzzle Filter
With Closed Captioning (EIA-608, CEA-708)
[and Embedded 2d Barcodes]

Method II
Evading YouTube Copyright Detectors
Using

An Analogue Multiplexed Analogue

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

Method III
Evading YouTube Copyright Detectors
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
Evading YouTube Copyright Detectors
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?

Only the logo gives it away.

Can you find Geek Charming?

Only the logo gives it away.

Can you find Geek Charming again?

Only the logo gives it away.

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.
1. Recover the Sound & Vision. The recovered material should be viewable as
is in real time with no delays.
2. 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!
3. Decoding must be robust and fast. there should be no more than 500ms
before the 'deblocked state' is recovered.
4. 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 decode
Some simplifications must be made mandatory for easier decoding
Simplification 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 practices
The 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 practices
The 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 = 1080p

3. Frame Number : Y:###### (base32; 277m; permit overrun)
YV:###### announces when a video frame will change state
YA:###### announces when audio scrambling state will change
Combined 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 State
Syntax example : K.135F
Multiplexing Rules
1. 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.

In recent times, the solution has been to

encode video with Wavelet methods.

As digital video started in the early 1990s,

that is nearly 25 years of defacto use.

DCT compreses AC components best vs

Wavelets compres DC componants best.

However, for Error Correction and Signal

to Noise Ratio reasons 8x8
macroblocks are an imperfect and
rather inflexible solution.

CODECs like Dirac have arisen out of

attempts to fix the coding efficiency
problem.

When it comes to compressibility, the

standard 8x8 macroblock size is almost
too small. Coding Theory suggests
larger macroblocks should be used.

However, Wavelets and DCT are good at

compressing different aspects of a signal.

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
Evading YouTube Copyright Detectors
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

Evading YouTube Copyright Detectors

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

The DCT transforms an 88 block of input

values to a linear combination of these
64 patterns.
The patterns are referred to as the twodimensional DCT basis functions, and
the output values are referred to as
transform coefficients.

MAC transmits luminance and

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

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 The MAC encoding and decoding
Source CODEC that can be used
procedures will have to be
with
different from any conventional
digital video systems used today

CCCP (Combined Community

Codec Pack)
This should not discourage
anyone from trying, the technical

VLC
hurdles are not infinite

Other Codecs so that it can be

The interoperability solutions are

used with players like GOM or
mostly common sense ones and
Windows Media Player
not difficult

Multiplexed Analogue Components (MAC) Filter

requirements for Internet Digital Video
All encoding must be Progressive
I. HD 720p, 1080p and 4kp modes must
be used exclusively
II. Chrominance (C) & Luminance (L) must
be horizontally swappable, vertical
swapping is forbidden
III. A working group must find ways of
random block interleaving C & L;
resolution/5 active video horizontal
slices must be used
IV. A 2 pixel boundary should be observed
between C & L, the fill colour gradient
can be random

Multiplexed Analogue Components (MAC) Filter

requirements for Internet Digital Video
Forbidden Practices

More Forbidden Practices

I. Any coding of Digital Audio in the

Vision Domain, this is not
analogue telly!

I. Frame rate coding must be at least

20 fps, 24 to 30 fps preferred; 24 fps
minimum

II. Excessive C or L compression,

4096 levels of quantization each
must be the bare minimum

II. No Anamorphic coding! CPU use

goes up & the video decoding delay
is increased.
III. No rate sampling of C or L, it is
too messy!

III. All 2d barcodes to indicate

encoder state -- if used -- must be
IV. MAC grayscale encoding variation
encoded to survive
must be R=G=B!
downsampling to 240p
V. No Colour in MAC mode!

Multiplexed Analogue Components (MAC) Filter

requirements for Internet Digital Video
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

Multiplexed Analogue Components (MAC) Filter

requirements for Internet Digital Video
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

Multiplexed Analogue Components (MAC) Filter

requirements for Internet Digital Video
On 4k (UHDTV) encoding

4K 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

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

Version & Subversion, CODEC

Frame Number (FN)

Version & Subversion

MAC Block Encoding State (BES)

Frame Number

Audio State (AS), Future AS @ FN

Future MAC BES @ FN

Because barcodes have their own Error

Correction, no chekdigit or checksum is
required!

Mandatory for all

Separable

MAC 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.
Requirements

All 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.

Multiplexed Analogue Components (MAC) Filter

requirements for Internet Digital Video
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
Evading YouTube Copyright Detectors
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
st
inventor of the 1 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

Please mount the compete series as a public torrent!

Australian & NZ Series with no HDTV torrents

Please mount the compete series as a public torrent!

NZ Series with no HDTV torrents

Please mount the compete series as a public torrent!
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 paperpushing working life then-familiar to many
Kiwis.

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 .

Gliding On won several Feltex Awards

including best male and female actors and
best entertainment.

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 ...