[Asterisk-video] H264 and rtp
Damian Minkov
damencho at damencho.com
Tue Nov 18 09:35:16 CST 2008
Hi again,
I tried today with asterisk 1.6 and this problem does not exist.
damencho
Damian Minkov wrote:
> Hi,
>
> sorry for the trouble, as I was sending it I tried to align everything
> with spaces to
> avoid such a problem. Obviously it didn't work out. So here is csv file.
>
> Let me know if it doesn't work
> damencho
>
>
> Dan Julius wrote:
>> can you reformat the table? it's hard to follow and I'm not getting
>> your observations.
>>
>> Dan
>>
>> On Mon, Nov 17, 2008 at 12:14 PM, Damian Minkov
>> <damencho at damencho.com <mailto:damencho at damencho.com>> wrote:
>>
>> Hi all,
>>
>> I'm not sure is this is the right place to ask a question but the
>> question is about asterisk and video so :)
>> I have problem with h264 codec (I am integrating the codec into an
>> application). For the tests I use to call asterisk and the echo
>> application, but I came up with strange results using it.
>> The sent packets are not received in the right order(I mean even the
>> sequence numbers).
>> As said in the RFC one frame is sent in multiple packets and the
>> last
>> one is with set RTP Marker flag and all packets are with same time.
>> But that packet with marker flag set is received as first packet
>> of the
>> frame sequence and with changed sequence number.
>> Here is an example of which is extracted from wireshark dump
>> (start of a
>> call).
>> The first four packets are sent and received in right order. But
>> you can
>> see that packet number 20 is received as packet 5.
>> Also some of the packets are missing(3 of them) but the sequence
>> numbers
>> are all there :
>>
>> Sent
>> Received
>> Length Sequence Time Mark Length
>> Sequence Time Mark
>> 1 525 116 0 no
>> 525 23215 0 no
>> 2 42 117 0 no
>> 42 23216 0 no
>> 3 24 118 0 no
>> 24 23217 0 no
>> 4 264 119 0 yes
>> 264 23218 0 yes
>> 5 1004 120 34830 no 798
>> 23219 35730 yes
>> 6 1004 121 34830 no 1004
>> 23220 35730 no
>> 7 1004 122 34830 no 1004
>> 23221 35730 no
>> 8 1004 123 34830 no 1004
>> 23222 35730 no
>> 9 1004 124 34830 no 1004
>> 23223 35730 no
>> 10 1004 125 34830 no 1004
>> 23224 35730 no
>> 11 1004 126 34830 no 1004
>> 23225 35730 no
>> 12 1004 127 34830 no 1004
>> 23226 35730 no
>> 13 1004 128 34830 no 1004
>> 23227 35730 no
>> 14 1004 129 34830 no 1004
>> 23228 35730 no
>> 15 1004 130 34830 no 1004
>> 23229 35730 no
>> 16 1004 131 34830 no 1004
>> 23230 35730 no
>> 17 1004 132 34830 no 1004
>> 23231 35730 no
>> 18 1004 133 34830
>> no
>> 19 1004 134 34830
>> no
>> 20 798 135 34830
>> yes
>>
>> When I make peer-to-peer call without using asterisk everything is
>> fine.
>>
>> What can be the cause of the problem ? Any ideas where to look for ?
>>
>> As the received packets time and sequence is changed so is
>> changed and
>> the checksum - all I'm using to compare packets
>> is their length,time and order of sending. The asterisk version I'm
>> testing with is 1.4.11 (its a production server thats why its
>> pretty old).
>>
>> Thanks in advance
>> damencho
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-video
>
More information about the asterisk-video
mailing list