A couple of weeks ago, this project inspired the idea of a new project - something to occupy myself with when this is over.
by James Ridgway
Today is a day entirely dedicated to working on my dissertation, so I will be blogging as the day unfolds to document what I achieve and any problem that I encounter.
Talking of problems, my first issue was encountered in trying to fix the page numbering in LaTeX. Unfortunately my attempts to fix this have been in vein. For some reason, pages before the contents page are incorrectly numbered. Despite the signed declaration being page “I” and the first item in the contents page, selecting the Signed Declaration from the contents page goes to the title page. Now that I have wasted enough time on this I will process to implementing the rest of the improvements to the final report (as per my last set of feedback).
So far the only real alterations I have made to the final report are:
I have now decided to turn away from the report itself and look more at the programming code. (I am waiting for a reply to an email before I continue with the report writing).
To recap, my project is formed of several key components:
The AES cryptosystem is complete as far as the basic concept goes, a couple of tweaks are necessary to allow it to handle any data, however, I am not too concerned about the cryptography element as this is shaping up quite nicely. This is the most complete element of my project thus far.
In terms of steganography and steganalysis I am well underway. Although I have encountered some serious issues which have been mentioned in previous blog posts, I am sure I will get round this eventually.
I am of course a little concerned about the complete lack of GUI and proven testing as these are still very important parts of my project. I have attempted to include GUI and unit testing components in my project before, however, attempts to modify the FFmpeg based Makefile has been unsuccessful.
So, after not having looked at the unit testing for a while I have attempted to integrate CUnit into my project, and truth be told, it’s only taken 10 minutes and I have fully integrated CUnit.
I have also improved all of the header files so that I no longer get errors and warnings relating to prototypes being redefined. I now want to look at building unit tests for all of my code, hopefully this will help identify any bugs which are causing issues with the steganography encoding.
Later today I also hope to take a look at GUI integration.
by James Ridgway
A large amount of today has been spent investigating the issues that were highlighted during yesterdays blog post.
Some progress has been made. Mike helped to identify a bug in LSB manipulation, so whilst the output isn't as dirty as it once was it is still not completely clear.
Currently, I am out of ideas for things to try that might help to address these issues. As I mentioned in my previous post I intend to investigate the properties (X and Y components) of the motion vectors that cuase issues during the decodeing process. This might or might not yeild anything useful, but at the moment, it's better than doing nothing.
I also have amendments for the first 2 chapters to work on, I need to find some time to update these. Also, as a public remnder to myself, I need to ask Mike about the best place to put the AES material (leave it as an appendix or put it somewhere in the main document body).
by James Ridgway
Terminiology distinction: I use encoding refers to the process of manipulating data to hide a bit. The term Coding is used to refer to the process of the codec uses to output the video bit stream 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:
Basically, 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 introduces 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 change the "do not encode" option so that when their was nothing to encode, the MV x-direction would be left un touched. Simple surely? Well, no. The values I was setting in the motion vectors were not being preserved during the video coding process. I pressume a quantization 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 to great. Thinking that there appear to be compilcations with modifyinh 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 occuring. I am trying to look into the properties of the MVs that cause the bit-flipping.
by James Ridgway
Using a very crude system I have been able to encode "Hi Mike!". It isn't perfect by far and is horribly crude. Let me back track and explain why it was so crude.
My initial method of encoding was trying to set MV table values per macroblock, which wasn't really working. Although I was able to modify the motion vector, the changes I made were not being truely reflected in the motion vector during decoding.
I have now worked out how to modify the overall motion vector, and at the moment I am modifying the X dimension only.
During this experimentation I have also observed that if the motion vectors are modified for an entire frame are too great, this will cause the residual frame to be very large in size and will result in the encoder converting the P-frame to an I-frame. (A P-frame is a predicted frame containing motion vectors that are used as deltas to modify preceding frame representations, an I-frame is a reference frame that essentially contains the picture).
In switching from MV tables to MV, I also changed to a very basic encoding scheme which works as follows, I set the X-direction of a MV as follows:
During the encoding process I was trying to encode the length of the message as a four byte integer representation followed by "Hi Mike!" -- as you can see the integer representation didn't work, but, we have "Hi Mike!" (LSB -> MSB) at encode-time.
Using my analysis tool I have been able to output the follow (note, I stopped selecting bits/mv values as seen as I hit a MV with the x-dimension value of 3.
For some reason there is a "0" value in there - this shouldn't be the case. I'm not sure why there is that discrepency, I might have to look into using ECCs (Error Correcting Codes). Replace the 2's with 0's and we have our encoded message!
by James Ridgway