What specification for IR communication to AV equipment?
A worthy task and one which should keep you usefully employed indefinitely ! :-)

If you wish to create a truly universal IR remote control then you need to provide a "learning" function that can "listen" to sequences from other devices. You could make your device "learning only" as some are, but if you mix that with a knowledge of existing protocols such as the man that Oli mentioned.

That site does have a learning IR remote page (I found this afer I started to talk anout learning cintrollers, honest ! :-).They provide some useful advice. The majority of the material below is copied from links from the above pages BUT it is copied here not so much (if at all) to provide prtocol information but rather to show the sort of thing you are going to have to deal with to make something that is truly universal. 

"Learning" IRremote controller:


This type of universal remote controllers has the ability to learn new codes. Usually you must align it head to head with the original remote controller and then press a special sequence of buttons on both controllers. The universal remote controller sees the patterns transmitted by the original remote controller and stores them in its memory. Later it can play back the learned patterns when you press the keys on the universal remote controller.
One of the biggest advantage of this approach is that the universal remote controller can learn codes of brand new remote controllers, which didn't exist yet when the universal remote controller was created. 
But that doesn't mean that a learning universal remote controller can learn just about every possible protocol. I can imagine for instance that the ITT code will not be recognized because of the very short IR pulses it produces, whilst most universal remote controllers expect to see some sort of carrier in the range of 36 to 40 kHz. 




An example only of what you are up against if you want to makea truly unversal remote ! :-) 

ITT Protocol from here


Only 14 very short IR pulses per message
Pulse distance encoding
Long battery life
4 bit address, 6 bit command length
Self calibrating timing, allowing only simple RC oscillator in the transmitter
Fast communication, a message takes from 1.7ms to 2.7ms to transmit
Manufacturer Intermetall, now Micronas  
Other protocols may not be recognized because of less obvious technical reasons. For instance the NRC17 code may cause some problems on some universal remote controllers. If it does cause problems it is probably because every NRC17 command consists of at least 3 messages (Start, Command and Stop). I can imagine that some learning universal remote controllers can get quite confused by these Start and Stop messages.




An IR message is transmitted by sending 14 pulses.
 Each pulse is 10µs long.
 Three different time intervals between the pulses are used to get the message across:
 100µs for a logic 0, 200µs for a logic 1 and 300µs for the lead-in and lead-out.





Then, having "cut your teeth":

Nokia NRC17 Protocol


The Nokia Remote Control protocol uses 17 bits to transmit the IR commands, which immediately explains the name of this protocol. 
The protocol was designed for Nokia consumer electronics. It was used during the last few years in which Nokia produced TV sets and VCRs. Also the sister brands like Finlux and Salora used this protocol. Nowadays the protocol is mainly used in Nokia satellite receivers and set-top boxes.


Set top boxes?. Bother ! :-)

Playing dirty.
 First the 0 &amp; 1.


The protocol uses bi-phase (or so-called NRZ - Non Return to Zero) modulation of a 38kHz IR carrier frequency. All bits are of equal length of 1ms in this protocol, with half of the bit time filled with a burst of the 38kHz carrier and the other half being idle. A logical one is represented by a burst in the first half of the bit time. A logical zero is represented by a burst in the second half of the bit time. 
The pulse/pause ratio of the 38kHz carrier frequency is 1/4 which helps to reduce power consumption. 




Sample message:



No problem ! :-)

But, do note the pre-pulse spaced 3  mS before the message proper.


The first pulse is called the pre-pulse, and is made up of a 500µs burst followed by a 2.5ms pause, giving a total of 3 bit times. 
Then the Start bit is transmitted, which is always a logic "1". This pulse can be used to calibrate the bit time on the receiver side, because the burst time is exactly half a bit time. 
The next 8 bits represent the IR command, which is sent with LSB first. The command is followed by a 4 bit device address. Finally a 4 bit sub-code is transmitted, which can be seen as an extension to the address bits. 
A message consists of a 3ms pre-pulse and 17 bits of 1ms each. This adds up to a total of 20ms per message.




Impossible is nothing!

So, having assimilated that


Every time a key is pressed on the remote control a start message is transmitted containing a command of $FE and address/sub-code of $FF. The actual message is sent 40ms later, and is repeated every 100ms for as long as the key on the remote control remains down. When the key is released a stop message will complete the sequence. The stop message also uses the command $FE and address/sub-code $FF. 
Every sequence can be treated as one single sequence at the receiver's end because of the start and stop messages. Accidental key bounces are effectively eliminated by this procedure. 
The receiver may decide to honour the repeated messages or not. E.g. cursor movements may repeat for as long as the key is pressed. Numerical inputs better don't allow auto repeat.


And more.