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

[Howard Chu]

aviad rozenhek wrote:
> 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

Lowering the send buffer size sounds like a reasonable solution for local 
sockets. That really should be all that's necessary to deal with unix domain 
sockets.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/