Re: Comparing two pcap files for latency

[Martin Visser <martinvisser99 () gmail com>]

H.263 is the compression standard and defines how the video is
encoded. It doesn't define the transport AFAIK. However it seems that
H.263 is commonly transported in RTP. The first RFC to define this was
RFC 2190.

Anyway if your stream is over RTP (which in turn is carried on RTP)
Wireshark should be able to help you out. All you need to do is find a
packet containing the stream, right-click and select Decode As.., and
selecting the destination port choose RTP as the transport protocol.
If that works you can use the Telephony:RTP analysis mentioned above.


Regards, Martin

MartinVisser99 () gmail com



On 2 February 2011 12:10,  <jobhunts02 () aol com> wrote:
> Since it is my H.263 video that Is being
> corrupted, is there a similar way to
> analyze H.263 streams?
>
>
> On Feb 1, 2011, at 11:22 AM, Martin Visser <martinvisser99 () gmail com> wrote:
>
> > All streaming media protocols need to deal with latency (or delay),
> > but more importantly variation in latency (or jitter). (Or as you put
> > it, fluctuation of latency). They accomplish this by having a jitter
> > buffer. When you start a stream, the receiver will buffer a certain
> > amount of data before playing it out. That way, if packets are delay,
> > a little, the receiver has something to play while it waits for the
> > outstanding data.
> >
> > As such, absolute latency isn't  important Provided that the buffer is
> > large enough to accommodate for the maximum jitter, it will always
> > have something to play. The receiver can wait as long it likes for the
> > first packet, as long as it doesn't start playing until it has enough
> > to accomodate with the variation in delay. Wireshark can show jitter
> > if the stream is carried inside RTP. Just look in Telephony:RTP. If
> > Jitter is exceeding your buffer size you have a problem.
> >
> >
> >
> > Regards, Martin
> >
> > MartinVisser99 () gmail com
> >
> >
> >
> > On 2 February 2011 04:03,  <jobhunts02 () aol com> wrote:
> > > The reason I want this information is that I am streaming video over a communications link and am getting poor 
> > > quality video.  I used the program TPCAT and found that no packets are being lost.  I assume that the poor video 
> > > must be due to latency.  I'd like to look at the total latency from source to destination and see if it fluctuates. 
> > >  If it does, I will then see if there is a backlog in Linux on either end or in the link.  TPCAT is supposed to be 
> > > able to measure latency but it stops responding when there are large numbers of packets like in a video stream.  
> > > The author told me this is a known issue.  I was hoping there might be an alternative tool to measure latency 
> > > similar to TPCAT that compares pcap files for latency.
> > >
> > >
> > > On Jan 31, 2011, at 4:44 PM, Guy Harris <guy () alum mit edu> wrote:
> > >
> > > > On Jan 31, 2011, at 3:20 PM, Martin Visser wrote:
> > > >
> > > > > As Guy has said, you can't use the absolute times unless you can
> > > > > ensure the machines at each end are millisecond synchronized.
> > > >
> > > > ...and that the time stamps given to transmitted and received packets correspond to the times you're interested 
> > > > in.  If you care *only* about transit time on the network - e.g., the time from the point at which the first bit 
> > > > of the packet is put onto the first network hop and the time at which the last bit of the packet is received from 
> > > > the last network hop - then those time stamps almost certainly do *not* correspond to the times you're interested 
> > > > in.  If you care about latency *including network stack latency*, it might be better, although the time stamp 
> > > > applied to outgoing packets is probably later than the time at which the outgoing packet was initially handed to 
> > > > the network stack, and the time stamp applied to incoming packets is probably earlier than the time at which the 
> > > > incoming packet was handed up from the network stack.
> > > >
> > > > =
> > > > ___________________________________________________________________________
> > > > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > > >             mailto:wireshark-users-request () wireshark org?subject=unsubscribe
> > > ___________________________________________________________________________
> > > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > >             mailto:wireshark-users-request () wireshark org?subject=unsubscribe
> > ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >             mailto:wireshark-users-request () wireshark org?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe