[FFmpeg-devel] [RFC] unix socket protocol and our proto situation
Sat Sep 18 11:22:04 CEST 2010
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.
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
1. creating a dedicated thread for reading UDP, read packets are passed
buffered and queued for the main thread where they are
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
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
now my application can send/receive MPEGTS over UDP without loss, while
stock ffmpeg cant
More information about the ffmpeg-devel