[FFmpeg-devel] [RFC] unix socket protocol and our proto situation
Howard Chu
hyc
Sat Sep 18 11:39:38 CEST 2010
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/
More information about the ffmpeg-devel
mailing list