[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