As of last night I have written the first two chapters (Introduction and Literatury Survey) of the Final Report.
I hope to use the rest of this week to develop embedding mechanisms (not sure how long this will take).
During downtime I have been experimenting with gtk+3. On Mac I have experienced the following issue:
gtk gcc -Wall helloworld.c -o helloworld $(pkg-config --cflags --libs gtk+-3.0) Package xcb-shm was not found in the pkg-config search path. Perhaps you should add the directory containing `xcb-shm.pc' to the PKG_CONFIG_PATH environment variable Package 'xcb-shm', required by 'cairo', not found Package xcb-shm was not found in the pkg-config search path. Perhaps you should add the directory containing `xcb-shm.pc' to the PKG_CONFIG_PATH environment variable Package 'xcb-shm', required by 'cairo', not found helloworld.c:3:21: error: gtk/gtk.h: No such file or directory
However, this can be fixed by running:
by James Ridgway
Progress on my dissertation this week has certainly left me on a high - I have fixed my issue with audio distortion!
I doubt I would have reached the resolution of this issue this quickly without the help of my supervisor, Mike Stannett. We spent an hour this week disecting my code and the workings of FFmpeg over Skype. At the end of this we were reasonably confident that we had issolated the problem, which I can now tell you was to do with the sample format of the audio stream. The audio sample format was not being properly decduced from the input file - the audio channel was been treated as 16 bit sample rate instead of 32 bit. Given my experimentation with WAV audio steganography at the start of this project I was reasonably confident that this was the issue.
Enabling the support of other (non-s16) sample formats in FFmpeg proved to be a bit of a difficultly that needed to be overcome given my recent restructing of including FFmpeg libraries (avformat, avcodec, ...) directly in my project. However, it is fair to say that several hours later I resolved this.
I can now successfully transcode a video on any operating system (Windows, Linux, OS X) whereby the quality of the audio and video persists.
Over the last few days I have looked into modifying motion vector related values - I have had success with this to an extent, and I am continuing to explore the possible options.
I have also solved my "analysis" issue that I was having where frame pictures where claiming to have a picture size of 0x0. Now, I need to work on embedding and extracting data from video frames.
I have decided to walk before I can run - sticking with a very basic encoding strategy with the possibility to explore other methods at a later date. There is also the possibility to take this further by adding error correction codes and other such enhancements at a later date.
My aims over the course of the next 7 days:
by James Ridgway
I was hoping that my this point I would have had a reasonable right up on motion vectors. Whilst I have been undertaking further reading and have a better understanding of how these work, I have not yet had the chance to formalise this in a write up. I have also been looking at how I would go about modify motion vectors.
From what I have gauged so far, and from emails with Michael Niedermayer (one of the contributors of FFmpeg), I will need to modify FFmpeg to be able to provide the encoding mechanisms with custom motion vectors.
I'm not whole happy with the idea of modifying FFmpeg, as keeping my version of it up to date with FFmpeg will be difficult, but I am now moving forwards with the idea that my code will have to directly include the source of FFmpeg - as it will need to be modified in parts. It's not ideal, but for now, it will do.
So, with this strategy in mind I set about attempting to setup a project that will run be entirely self contained, and will not run off pre-compile/pre-install FFmpeg libraries. In the main, this has been successful. It took some effort, but in the end it all worked well, and make files were eventually sorted so that I could compile across platforms. The state of my desk reflects the amount of working that I have done since last Friday's meeting (photo).
I have mentioned in previous blog posts about my issues of transcoding on different platforms. To recap, I seem to get an issue with audio distortion. Previosuly, transcoding only worked perfectly on Ubuntu, on Windows or Mac OS X I would get audio distrortion. Now it appears with this self contained instance I get it all the time - regardless of OS! Why do I always have to encounter a set back?!
Anyway, It has been suggsted to me (by Paul Ridgway) that I might be getting errors with floating point operations - as floating point number representations can differ between systems. Whether or not it is floating point operations, I belief that his point of a compiler flag, or OS-compiler related issue being the source of my problems as highly plausible.
I am now going to battle on with trying to solve this issue. Should I fix this, or get overly fustrated with this (highly probable), I will work on any of the following:
My to-do list also includes:
by James Ridgway
My aims for this week are:
In my previous two posts I mentioned improvements to the websit, and the development of an AES cryptosystem.
Firstly, the website. I have added a resources section where I will be uploading aspects of my work as the project progresses. However, it is likely that these resources will remain private until the completion of this project.
It turns out that my AES implementation had a bug in it! I found this when attempting to validate it against AES test vectors. This was a simple bug in the key expansion where an int was being treated as a signed int when it should have been an unsigned int.
My AES cryptosystem now validates against test vectors for 128-bit 192-bit and 256-bit keys. Unit tests have been produced using Cunit to validate the cryptosystem.
I have also written up a small document on AES (which can be found in the resources section)., explaining exactly how the algorithm works, how it differs from Rijndael, and how the different block modes work. Although I only intend on using the CBC block mode for my project, I have documented how all of the main block modes (ECB, CBC, OFB, CFB) work. This document has been structed and written so that it can be merged/adapted for inclusion in the final project report.
I intend to use the rest of this week to enhance my knowledge of motion vectors before attempting (again) to manipulate motion vectors during the transcode process. Last week I emailed a contributor of the FFmpeg project, and i have been advised to look at libavcodec/motion_est*.c files, this is where motion vectors are chosen - but first I need to read up a bit more on how they work.
Finally, if I get the time, I will investigate my cross platform issues with audio distortion. I have been advised that different floating point representations on different systems may be a contributing factor and that I should look ath the configure file for FFmpeg and any compiler flags.
My progress and outlook for the rest of the week for the rest of the week can be summaries as folows:
by James Ridgway
In atticipation of new content which should hopefully appear over the next week or so I have made some updates to my website.
Most of these changes aren't public facing, however, an entirely new section of the website is under construction and will hopefully be released by the end of the week.
The only change you mght notice is that the blog section is now paginated.
by James Ridgway