[FFmpeg-user] constant rtp stram

Tue Mar 25 13:32:28 CET 2014

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
>>
>
>
>