In general hardware decoders have a problem with the bursty nature of FFmpeg's UDP. I have fixed this by buffering to disk and sending it with my own program. ISO131808-1 does not specify the maximum jitter allowable in packets, but I have found up to 500 micro seconds to be acceptable for a 4mbps mux. The problem is bursty UDP datagrams cause underflow and overflow of the input buffer in hardware decoders.
The pacing solution I used for my own program was to make an event loop thread that only ever performs "short" operations. This thread is simply a loop which checks a timer with nanosecond resolution. If it is less then 1/3 the way through the period, I process other operations, but as it nears the time to transmit, it just functions as a simple wait loop. We really need someone familiar with the UDP code to rework the transmit pacing. Zach On Fri, Oct 16, 2015 at 9:21 AM, [email protected] <[email protected]> wrote: > > I had a patch once that would "slow down" udp output if you'd like to > > try it...what is the problem though, are you unable to receive it on > > the receiving side? > > Do you happen to still have that patch around? I just ran into a problem > where ffmpegs udp output is too bursty for the used receiver. Would be > interesting to try your patch. > > -Julian > > > > -- > View this message in context: > http://libav-users.943685.n4.nabble.com/Libav-user-ffmpeg-burst-traffic-problem-tp4658964p4661598.html > Sent from the libav-users mailing list archive at Nabble.com. > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user >
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
