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
Intelligible blog title? Maybe, maybe not.
The Advanced Encryption Standard (AES) has been widely recognised as government- and military- grade encryption for the past 12 years. The AES specification was initially established in 2001 by the U.S National Institute of Standards and Technology (NIST) as a replacement for the then encryption standard DES (Data Encryption Standard).
The AES cipher was initially called Rijndael (pronounced “rain dahl”) and was developed by Belgian cryptographers Joan Daemen and Vincent Rijmen.
As part of the requirements for my dissertation I have produced an 256-bit CBC FIPS-197 compliant implementation of the AES algorithm.
What does 256-bit CBC FIPS-197 compliant mean?
Implementing AES in a new language (C) has proven to have its challenges as I was trying to understand exactly how AES works at the same time. Most of the problems I encountered where problems with the C programming language as opposed to a misunderstanding of how AES works.
Despite being well established as the current encryption standard there are limited resources on the internet that explain how AES works in a straight forward manner to someone who has a fundamental working knowledge of cryptography. For all the smoke and mirrors, AES is quite as simple encryption algorithm.
by James Ridgway