[XviD-devel] XviD waterkmark?

Michael Militzer michael at xvid.org
Mon Jul 4 20:35:14 CEST 2005


Hi,

hm, I'm not sure I understood correctly what you are doing. But, if
you added proprietary 'marking functions' to the en- and decoder, that
sounds as if you've changed the bitstream syntax. In this case the videos
created with your modified encoder will very likely not be decoded anymore
by the original XviD decoder. Hence, you will loose compatibility to XviD/
MPEG-4 devices or software. Therefore, I would rather call such an approach
a proprietary syntax extension and not a watermark - after all, the usual
watermark approaches don't harm standard compliance but add data (often
copyright information) that goes unnoticed by decoders not supporting the
watermark technique.

So I'd be interested to know if your approach harms compliance to standard
decoders. If it does, what benefits does it provide in return? Subtitles or
special movie description etc. can also be added using a modern container
format (e.g. mp4 or Matroska) without sacrificing standard compliance of 
the video data. So what's the benefit of your approach over such a solution?

bye,
Michael


Quoting Jakub Piotrowski <jpp at poczta.onet.pl>:

> Hello,
> 
> I'm working on watermarking scheme dedicated for XviD. Did anyone of You ever
> seen anything like this? I mean watermark that is written especially for
> XviD, since it is possible to use any typical watermark on uncompressed video
> and then compress it using XviD (however, due to quite good compression, it
> is questionable how usefull this way is). In my proposed sollution, watermark
> data are added by marking functions added by me to original encoding part of
> XviD, while extraction is performed by analogous function in decoder, and all
> this is supposed to work real-time (especially extraction of data - it
> happens directly while playing movie).
> 
> And just for explanation - my waterkmark is designed to carry additional info
> like description or maybe subtitiles rather than copyright information, and
> will be rather fragile than robust to most of attacks:)
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
> 






More information about the XviD-devel mailing list