Terminology distinction: I use encoding refers to the process of manipulating data to hide a bit. The term Coding refers to the process of the codec used to output the video bitstream based on the spatial-temporal models.
So most of today has been spent messing around with encoding methods.
I originally got "Hi Mike!" encoded as per my previous blog post. However, in trying to improve this, I somehow took a step backwards and got to a point where I wasn't encoding.
So, after having regained the encoding capability, I was able to encode "Hi Mike" in a single frame using the following system:
- 1 = binary 1
- 2 = binary 2
- 3 = do not encode
I set the x-direction of motion vectors using these values. So the message was hidden in the first P-frame, and all other P-frames just had "3" for the x-direction. This caused a sizable increase in residual frame sizes but also introduced horrendous (and expected) distortion to the video stream.
The next step was to try and make this system more subtle. My attempt to do this involved changing the "do not encode" option so that the MV x-direction would be left un touched when there was nothing to encode. Simple surely? Well, no. The values I was setting in the motion vectors were not being preserved during the video coding process. I presume a quantisation operation (or similar) occurs such that the range of numbers is narrowed, and in some cases, some of the "1" and "2" values get culled.
In an attempt to make the overall embedding operation even more subtle, I attempted to use the LSB of the MV x-direction. This also didn't work too great. Thinking that there appear to be complications with modifying consecutive MVs in a single frame, I then changed to using a method that encoded in the first MV of each frame until encoding was finished. Again, some bytes are being incorrectly displayed because bits are flipping.
I'm not sure why this bit-flipping style issue is occurring. I am trying to look into the properties of the MVs that cause the bit-flipping.