[FFmpeg-devel] [RFC] unix socket protocol and our proto situation

[aviad rozenhek]

On Fri, Aug 13, 2010 at 10:46, Luca Barbato <lu_zero at gentoo.org> wrote:

> Our network protocol layer is pretty much ineffective and can lose quite
> easily packets. Usually the system buffer would hide the issue with tcp
> based protocols and udp based might hide well the problem till we call
> url_read often enough. Losing data over loopback is something we do
> experience already when we test rtp.
>
> Here yesterday stab at the unix sockets, it shows pretty well how much
> our current proto layer rely on system buffers instead doing its proper
> buffering itself.
>
> Way to use it:
>
> ./ffplay -f mpegts unix:///tmp/ff.socket &
>
> sleep 2 && ./ffmpeg_g -re -i something -vcodec copy -acodec copy -f
> mpegts unix://tmp/ff.socket
>
> Expect to lose lots of frames.
>
> I'm pondering which would be a good solution:
>
> - do nothing and expect downstream apps cope with it somehow.
> - implement a generic fill thread within proto and change the interface
> so it could use a proper polling system.
> - something else glaring simpler that I hadn't thought.
>
> lu
>
>
I'm using libav* UDP layer quite extensively in my application, and packet
loss over loopback was a big problem for me. I solved it in the application
layer by:


   1. creating a dedicated thread for reading UDP, read packets are passed
   buffered and queued for the main thread where they are
   demuxed/analyzed/handled etc
   2. increasing the thread scheduling priority of the reading thread
   3. using pkt_size=1316 so that MPEG-TS data is not split over multiple
   UDP packets
   4. reducing the UDP buffer size of the sending application from 32K to
   8K, (ie in ffmpeg -i <input> -f mpegts udp://localhost:1234?buffer_size=8000
   ) this makes writing into the UDP socket block when data is written in
   bursts.

now my application can send/receive MPEGTS over UDP without loss, while
stock ffmpeg cant