[FFmpeg-user] constant rtp stram

Anshul anshul.ffmpeg at gmail.com
Tue Mar 25 19:19:44 CET 2014



"the..." <ttmgybta at gmail.com> wrote:
>We are still struggling with this problem, that we cant send a
>continues
>rtp stream to a destination.
>The packets are always send in burst of about 12 packets in 0.6 ms.
>We cant find a parameter were we could regulate the stream regularity.
>
>Ideas, hints or just tell us that it wont work as wished, so we don't
>have
>to search anymore...
>
>
>
>2014-03-20 14:50 GMT+01:00 the... <ttmgybta at gmail.com>:
>
>>
>> Thanks for your answer.
>>
>> The network and the server hardware are not the problem. The problem
>is
>> that ffmpeg streams the packets in burst.
>>
>> We are looking for a way that the stream is send in real-time. So all
>19
>> to 20ms one packet!
>> Any Idea?
>>
>>
>> 2014-02-28 19:45 GMT+01:00 Anshul <anshul.ffmpeg at gmail.com>:
>>
>>
>>>
>>> "the..." <ttmgybta at gmail.com> wrote:
>>> >Yes it is always the case.
>>> >
>>> >The log below is a part of the csv which I exported from the
>wireshark
>>> >rtp
>>> >analyzer.
>>> >
>>> >As you can see from Sequence 0 to 11 we have a delta from about
>0.02ms
>>> >the
>>> >244ms and the about 0.02 abayn and then 244ms...
>>>  >
>>> >
>>> >
>>> >
>>> >
>>> >"Packet","Sequence","Time stamp","Delta (ms)","Jitter
>>> >(ms)","Skew(ms)","IP
>>> >BW (kbps)","Marker","Status"
>>> >
>>> >"28","0","3893850368","0.00","0.00","0.00","1.60","","[ Ok
>>> >]","02/20/2014
>>> >16:17:57.511","214"
>>> >
>>> >"29","1","3893850528","0.02","1.25","19.98","3.20","","[ Ok
>>> >]","02/20/2014
>>> >16:17:57.511","214"
>>> >
>>> >"30","2","3893850688","0.03","2.42","39.95","4.80","","[ Ok
>>> >]","02/20/2014
>>> >16:17:57.511","214"
>>> >
>>> >"31","3","3893850848","0.10","3.51","59.85","6.40","","[ Ok
>>> >]","02/20/2014
>>> >16:17:57.511","214"
>>> >
>>> >"32","4","3893851008","0.02","4.54","79.83","8.00","","[ Ok
>>> >]","02/20/2014
>>> >16:17:57.511","214"
>>> >
>>> >"33","5","3893851168","0.08","5.50","99.75","9.60","","[ Ok
>>> >]","02/20/2014
>>> >16:17:57.511","214"
>>> >
>>> >"34","6","3893851328","0.05","6.41","119.70","11.20","","[ Ok
>>> >]","02/20/2014 16:17:57.511","214"
>>> >
>>> >"35","7","3893851488","0.04","7.25","139.66","12.80","","[ Ok
>>> >]","02/20/2014 16:17:57.511","214"
>>> >
>>> >"36","8","3893851648","0.08","8.04","159.59","14.40","","[ Ok
>>> >]","02/20/2014 16:17:57.511","214"
>>> >
>>> >"37","9","3893851808","0.04","8.79","179.55","16.00","","[ Ok
>>> >]","02/20/2014 16:17:57.511","214"
>>> >
>>> >"38","10","3893851968","0.06","9.49","199.48","17.60","","[ Ok
>>> >]","02/20/2014 16:17:57.511","214"
>>> >
>>> >"39","11","3893852128","0.04","10.14","219.45","19.20","","[ Ok
>>> >]","02/20/2014 16:17:57.511","214"
>>> >
>>> >"46","12","3893852288","244.30","23.53","-4.86","20.80","","[ Ok
>>> >]","02/20/2014 16:17:57.755","214"
>>> >
>>> >"47","13","3893852448","0.05","23.30","15.09","22.40","","[ Ok
>>> >]","02/20/2014 16:17:57.755","214"
>>> >
>>> >"48","14","3893852608","0.01","23.09","35.07","24.00","","[ Ok
>>> >]","02/20/2014 16:17:57.755","214"
>>> >
>>> >"49","15","3893852768","0.08","22.90","54.99","25.60","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"50","16","3893852928","0.04","22.71","74.95","27.20","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"51","17","3893853088","0.07","22.54","94.89","28.80","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"52","18","3893853248","0.04","22.38","114.85","30.40","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"53","19","3893853408","0.07","22.23","134.78","32.00","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"54","20","3893853568","0.09","22.08","154.69","33.60","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"55","21","3893853728","0.04","21.95","174.65","35.20","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"56","22","3893853888","0.06","21.82","194.60","36.80","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"57","23","3893854048","0.04","21.71","214.56","38.40","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"58","24","3893854208","0.07","21.60","234.49","40.00","","[ Ok
>>> >]","02/20/2014 16:17:57.756","214"
>>> >
>>> >"63","25","3893854368","255.35","34.96","-0.86","41.60","","[ Ok
>>> >]","02/20/2014 16:17:58.011","214"
>>> >
>>> >"64","26","3893854528","0.05","34.02","19.09","43.20","","[ Ok
>>> >]","02/20/2014 16:17:58.011","214"
>>> >
>>> >"65","27","3893854688","0.01","33.14","39.08","44.80","","[ Ok
>>> >]","02/20/2014 16:17:58.011","214"
>>> >
>>> >"66","28","3893854848","0.07","32.32","59.01","46.40","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"67","29","3893855008","0.06","31.54","78.95","48.00","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"68","30","3893855168","0.06","30.82","98.89","49.60","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"69","31","3893855328","0.04","30.14","118.86","51.20","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"70","32","3893855488","0.08","29.50","138.78","52.80","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"71","33","3893855648","0.09","28.90","158.69","54.40","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"72","34","3893855808","0.04","28.34","178.65","56.00","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"73","35","3893855968","0.03","27.82","198.61","57.60","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"74","36","3893856128","0.10","27.32","218.51","59.20","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"75","37","3893856288","0.02","26.86","238.50","60.80","","[ Ok
>>> >]","02/20/2014 16:17:58.012","214"
>>> >
>>> >"81","38","3893856448","255.38","39.90","3.12","62.40","","[ Ok
>>> >]","02/20/2014 16:17:58.267","214"
>>> >
>>> >
>>> >2014-02-28 17:02 GMT+01:00 Anshul <anshul.ffmpeg at gmail.com>:
>>> >
>>> >>
>>> >>
>>> >> "the..." <ttmgybta at gmail.com> wrote:
>>> >> >We see in the tcpdump that when we stream a wav file
>>> >> >
>>> >> >*ffmpeg -analyzeduration 0 -re -i /tmp/test.wav -vol 512 -c g722
>-ar
>>> >> >16000
>>> >> >-f rtp rtp://[destIP]:[destPort]*
>>> >> >
>>> >> >That the stream is sending in burst in to the wire.
>>> >> >
>>> >> >First about 12 packages in 0.6ms then about 144ms delta and then
>the
>>> >> >next
>>> >> >12 package in 0.6ms delta for about 144ms and so on...
>>> >> >
>>> >> >Is it possible to send the stream with a constant delta between
>the
>>> >> >packages?
>>> >> >
>>> >> >
>>> >> >Thanks
>>> >> >
>>> >> >Roman
>>> >> >_______________________________________________
>>> >> >ffmpeg-user mailing list
>>> >> >ffmpeg-user at ffmpeg.org
>>> >> >http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>> >>
>>> >> Is this case is allways same? i mean have you tried many times,
>>> >because
>>> >> some time diffence in latency is by underlying operating system
>which
>>> >have
>>> >> an unreliable network latency.
>>> >>
>>> >> -Anshul
>>> >> --
>>>
>>> Please dont post, it become difficult for other users searching for
>>> similar problem they cant understand the context, even it for other
>user.
>>> Who would have helped you bur cant since the context get lost
>>>
>>>
>>> According to ur ws log, i dont have sollution so that you can make
>delta
>>> equal, to me it look like one frame of audio takes 12 packet to get
>>> transmitted, so delta in 12 packet is only due network latency,
>while there
>>> is some time taken by transcoder for each frame so after each frame
>u get a
>>> bigger transcoder.
>>> There are 2 way to decrease delta
>>> Either buy more fast hardware so that transcoder take less per frame
>time.
>>>
>>> Keep transcodec audio at your server end, only add rtp header when
>you
>>> required streaming.
>>>
>>> There is also an misunderstanding that lower the bitrate faster will
>be
>>> the transfer, u should keep in mind that lower is the bitrate more
>hardwork
>>> on encoder so lower the production of frame, whenever u have to
>transcoder
>>> and stream then there must be good balance of bitrate, most of the
>time
>>> selection of bitrate is done by system to be used.
>>>
>>> Try -avcodec copy for not transcoding.
>>>
>>> -Anshul
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> ffmpeg-user at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>
>>
>>
>_______________________________________________
>ffmpeg-user mailing list
>ffmpeg-user at ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Please dont top post, your mail is too hard to understand. 

It is 12 packet are sent at once, this is related to block size or some time said page size. This is assumed by rtp protocol.

please provide me any libray refrence where you have seen 
That rtp is not giving 12 packet.
I have used proprietary rtp library they also gave 12 packet. Though I have not read rfc of rtp.

-Anshul
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


More information about the ffmpeg-user mailing list