[Ffmpeg-devel] libavcodec h264 decoder

[Måns Rullgård]

Stefan Gehrer <stefan.gehrer at gmx.de> writes:

> Loren Merritt wrote:
>> On Fri, 15 Dec 2006, michael benzon chua wrote:
>>> On 12/15/06, Stefan Gehrer <stefan.gehrer at gmx.de> wrote:
>>>
>>>> Interesting concept, but as soon as you use some real cryptography
>>>> instead of just toggling the sign I think the bitstream size will
>>>> increase as some seemingly random coefficients will be harder to
>>>> compress than what the encoder outputs. Or am I missing something?
>>>
>>> I think this is the case as well. The size of the output .264 file
>>> increased when I changed the dct values. I'm hoping the effect
>>> isn't too significant, and that the encryption is still reversible.
>>
>> The size of the .264 shouldn't change if you just toggle the
>> coefficient's sign, because sign isn't compressed.  Why do you want
>> to mess with the guts of the codec, rather than encrypting the whole
>> stream?
>
> Out of curiosity, I just played one of the Apple HD trailers and tried
> two things: inverting all signs of DCT coefficients and randomly
> inverting signs. In the first case, the video is still surprisingly
> clear, mainly looks like a photo-negative. In the latter case, the
> image is quite distorted but still leaves you with some faint idea of
> what's going on.  I could see an application here e.g. on set-top
> boxes: Instead of just a blank screen telling the user that a channel
> is encrypted, you can give her an idea of what she is missing, in
> order to increase the urge to subscribe to that channel.  Reminds me
> of the old days of scrambled analogue signals.

Broadcasters normally do this using a free preview period.  This means
you can watch a few minutes a day or so without paying.  Similarly,
the first few minutes of pay per view events are usually free.  I
suspect this is more effective than showing a garbled picture.

-- 
M?ns Rullg?rd
mru at inprovide.com