[Ffmpeg-devel] libavcodec h264 decoder
Sat Dec 16 20:31:16 CET 2006
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
> 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.
mru at inprovide.com
More information about the ffmpeg-devel