[x264-devel] Behaviour of Annex B encoding: bug or not?

Philip Spencer pspencer at fields.utoronto.ca
Mon Jan 11 17:10:52 CET 2010


On Thu, 7 Jan 2010, Jason Garrett-Glaser wrote:

> This is unrelated.  Simply due to random chance

I'm not sure what you were meaining by "unrelated", but my point was this:
Certainly a buggy endpoint that doesn't do escaping will, during 
communication with a non-buggy endpoint that does, end up with a small 
fraction of corrupt packets due to escaping being required by random 
chance a small fraction of the time.

However, that would simply result in a few discarded video frames 
and would likely not be noticed by a casual user.

By contrast, what we were seeing when using the ekiga softphone to talk to 
our buggy hardware was a 100% failure rate, not just a few dropped 
packets. This is because the software was using x264 to send a very 
complete Sequence Parameter Set NAL, including timing information (which, 
as this was a live stream, was always zero and hence always required 
escaping).

Knowing this, and knowing that our hardware DOES sucessfully establish 
connections to other models of hardware, led me to initially believe that 
there must be a lot of other brands of buggy hardware out there.

However, after I observed that our hardware unit chooses to send a less 
complete form Sequence Parameter Set, once which doesn't suffer from the 
unhappy state of always needing escaping, I realized it is know much more 
conceivable that the bug might be limited to our particular hardware brand 
(LifeSize) -- that it interoperates seemingly well with a wide range of 
other hardware simply because they too don't use a form of SPS that will 
always need escaping, and hence will establish connections succesfully and 
merely drop a few frames every now and then.

That's all I was trying to say: that now I realize it is possible for a 
buggy unit to connect to a non-buggy one in a way that would only trigger 
the bug a small fraction of the time rather than all the time, it is now 
much more conceivable that the bug is limited to our hardware brand than I 
originally thought.

It also means it's more likely I may be able to persuade the manufacturer 
to fix it than I originally thought (I knew there was no way they could be 
persuaded to fix something if that fix would render their units unable to 
connect to older, unfixed ones!)

- Philip

--------------------------------------------+-------------------------------
Philip Spencer  pspencer at fields.utoronto.ca | Director of Computing Services
Room 336        (416)-348-9710  ext3036     | The Fields Institute for
222 College St, Toronto ON M5T 3J1 Canada   | Research in Mathematical Sciences


More information about the x264-devel mailing list