DIGITAL WATERMARKING OF COMPRESSED MEDIA

1
DIGITAL WATERMARKING OF COMPRESSED MEDIA

• Presented _at_
• AFRL/Villanova University
• Kick-off Meeting
• Bijan Mobasseri
• RJ Berger III
• Mike Marcinak
• Villanova University
• Villanova, PA
• August 18, 2004

2
Background

• Sponsor Air Force Research Laboratory/IFEC
  Multi-Sensor Exploitation Branch
• Task develop algorithms for embedding of digital
  watermarks directly in the compressed bitstream
  of imagery and video
• Staff
• PI Bijan G. Mobasseri
• RA RJ Berger, Mike Marcinak, Chris Fleming, Dom
  Cinalli
• Undergrad Zach Cohen
• Project duration18 months
• Funding 148,000.

3
Outline

• Proposal review
• Challenges of compressed media
• Media compression
• Prior work
• Contrast with the proposed approach
• Results so far
• Future work

4
Excerpts from the proposal

• Compressed domain is now the native format of
  most multimedia signals. It would be inefficient
  to require either full or even partial
  decompression of the signal to perform
  watermarking
• In this document we advocate watermarking, not
  in raw or partially decompressed signal but
  directly in the compressed bitstream. With no
  need to do either full or even partial
  decompression, the algorithm is fast and real
  time
• The basic idea proposed here is that
  watermarking of VLCs is essentially equivalent to
  controlled channel errors
• The novelty of our proposed approach is the way
  we combine watermarking and error detection and
  correction

5
Watermarking in compressed media challenges

• Understanding the medium is a prerequisite to
  watermarking it
• Uncompressed NTSC video runs at 168 Mb/sec.
  MPEG-2 runs at lt10 Mb/sec. a 96 reduction
• Redundancy is at the heart of data hiding.
  Compressed video leaves precious little space to
  hide data while maintaining robustness, security
  and imperceptibility

6
Compressed media
7
MEDIA COMPRESSSIONJPEG OVERVIEW
8
Elements of JPEG

• JPEG is built on the properties of discrete
  cosine transform but is a lot more
• 8x8 DCT block transform
• Perceptual masking(quantization)
• Zigzag ordering
• Run-length encoding compression
• Variable-length encoding

9
DCT domain
Source Andreas Westfeld
10
Removing insignificant terms

• Quantization matrix zeros out perceptually
  insignificant DCT terms

Z(u,v)
Source Andreas Westfeld
11
Color quantization table

• Color bands are much more aggressively compressed
  than luminance. Here is the quantization table

Color table
Luminance table
12
Re-ordering

• DCT coefficients are reordered in a linear array
  according to the following pattern.

13
DCT/IDCT
14
Entropy coding

• Zigzag scanning following quantization insures
  long runs of AC coefficients
• DC coefficient is differentially encoded
  (relative to the previous block)
• Non-zero AC coefficients are variable length
  encoded (Huffman)

15
Run/Size

• Each AC coefficient in the zigzag scan is
  characterized by a pair (Run, Size).
• Run indicates the number of zeros preceeding the
  coefficient.
• Size or category indicates the magnitude of the
  coefficient

5 0 0 0 -3 0 2 1 0 8
The last coefficient has size 4 and run 1
16
Huffman coding of run/size
5 0 0 0 -3 0 2 1 0 8
17
Appended bits

• Each VLC must be followed by appended bits.
• The number of appended bits is equal to the size
  of the coefficient.
• Correct interpretation of appended bits is
  crucial in maintaining synchronization

1111101101000
18
Where did Table K.5 come from?

• Table K.5 is optimized for an average image
  obtained.
• Most JPEG encoders do not bother to optimize the
  table even though compression wont be as
  efficient.
• This oversight on the part of most encoders is
  the single most important reason we can implement
  our algorithm.

19
Final JPEG bitstream

• For the 8x8 block the following represents its
  JPEG bitstream
• 1010101 0100 001 0100 0101 100001 0110
  100011 001 100011 001 001 100101 11100110
  110110 0110 11110100 000 1010
• Total number of bits 92
• Original block 512
• Compression ratio 5.61

20
JPEG markers

• The bitstream is parsed by markers designated by
  FF

21
JPEG Hierarchy
22
Frame Header
23
Scans
24
Quantization table identifier
25
Huffman Table Specification
26
Inside compressed media
Variable length codes are the only features
available to carry hidden data
27
Previous work in compressed domain watermarking
28
Transformed domain vs. compressed domain
watermarking

• Early work in watermarking was in fact done in
  transformed domain(Cox)
• The distinction we make between the two is
  important
• Transformed domain watermarking embeds the
  watermark in transform coefficients frequently
  requiring partial decompression
• Compressed domain watermarking embeds the
  watermark in the compressed bitstream. The
  algorithm will necessarily be bit manupulation
• More recently the term JPEG-to-JPEG
  watermarking has been proposed

29
JSTEG
Source Andreas Westfeld
30
F3
Source Andreas Westfeld
31
F4
Embed 0110
Source Andreas Westfeld
32
Watermarking with file size preservation

• The only work competing with our approach was
  presented _at_SPIE04(Fridrich et al).
• The proposed approach is lossless, file size
  preserving and is performed in the compressed
  domain.
• A summary follows.

33
Algorithms summary
34
DATA HIDING IN THE ENTROPY CODED SEGMENT
35
Hierarchical view
36
Label-carrying VLCs

• In MPEG, there is a subset of VLC codes that
  represent identical runs but differ in level by
  just one. These are called label carrying VLCs by
  Langelaar

From Langelaar et al, IEEE SP Magazine September
2000
37
Data hiding in lc-VLC

• The algorithm proposed by Langelaar embeds
  watermark bits in the LSB of the level of the
  lc-VLCs

38
Data hiding capacities
39
Pros and cons

• This approach is basically a variation of LSB
  watermarking applied in compressed domain
• It is not terribly sophisticated and is not
  lossless
• It is simple to implement and it does work(our
  UAV video metadata embedding code works on this
  principal)

40
Watermark, bit errors and error resilient coding
41
Ideawatermark as intentional bit error

• Embed watermark bits in the VLCs as controlled
  bit errors.
• VLCs, however, have no inherent error protection.
  Any bit error will cause detection failure up to
  the next resynchronization marker
• Use algorithms designed to recover from channel
  errors

42
Problems

• Consider the VLC for Run 1/Size 4, 1111101101000
• Embed a 0 in one of the bit positions
• 1111001101000
• The problem is that our watermarked VLC violates
  the codes prefix condition, is not consistent
  with the appended bits and is probably
  irreversible.

43
Project objectives

• We are proposing to meet a set of objectives that
  have seldom been met in watermarking research
  before
• Compressed domain embedding
• Lossless embedding
• File-size preserving
• Useful capacity
• Format compliance
• Visually imperceptible

44
OUR EARLIER WORK

• SPIE04

45
IDEA

• A popular method to combat channel errors is
  through two decoding.
• The error(watermark) can be trapped and partially
  reversed.
• We have adapted a proposed scheme to watermarking.

46
Two-way decodable VLCs

• Girod has proposed an elegant design whereby
  conventional VLCs are made to exhibit
  resynchronizing property
• To construct resynchronizing VLCs from ordinary
  VLCs, we first define a packet consisting of N
  consecutive VLCs

vlcfliplr(vlc)
47
Watermark Embedding
VLCs
Cover signala,b,d,c
Bidirectional VLC
Watermarked ww1,w2,w3,w4) bidirectional VLC
48
Concept of flag
49
Synchronization issues

• The bidirectional decoding relies on the ability
  to reverse decode upon encountering a watermarked
  VLC
• For this to happen, one has to hunt for the
  end-of-block marker. Problem is these markers are
  abundantly emulated within data

• We call them potential end-of-blocks(PEOB)
• We establish that reverse decoding from a false
  EOB will violate one or more encoding rules. True
  EOB does not.

50
Finding end-of-packet
51
Watermarking capacity

• If watermark burst length does not extend into
  the copy of the current VLC, 100 error recovery
  is possible.
• It then follows that

52
Implementation
53
Pluses and minuses

• ?The algorithm is applied in compressed domain
• ? It is lossless
• ?It does not preserve file size
• ? The bitstream is not standard-compliant

54
Metadata Embedding in Compressed UAV Video via
Digital Watermarking
55
Metadata

• Descriptive Information
• Date / Time
• Direction
• Location
• etc

Video
Metadata
SuperStream

• Why Embed?
• Reduce bookkeeping
• Efficient storage
• Reduce comm. bandwidth
• Smart graphical display

http//www.airforce-technology.com/projects/predat
or/predator3.html
56
Video Metadata Synchronization

• Requirements
• Metadata sampling starts simultaneously with
  recording of video
• Metadata is sampled at a constant rate
• Result
• Video and metadata are concurrently displayed and
  maintain synchronization.

57
Metadata Viewer Application

• Concurrently display metadata video
• Graphical User Interface (GUI)
• Abstract technical detail
• Easy-To-Use

58
WRAP UP
59
FUTURE WORK

• Work on format-compliance of watermarked
  bitstream.
• Integration of run/size parameters in the tree.
• Broad assessment/comparison of watermarking
  capacity.
• Multiple watermark bit embedding and associated
  binary tree.
• Application to error resilient video coding.
• Integrated software package.
• Applications of interest to the Air Force.