[Live-devel] Larger streams breaking when opened through live555ProxyServer
Roman Gaufman
hackeron at gmail.com
Thu Jun 6 15:50:28 PDT 2013
I also tried:
sysctl -w net.core.rmem_max=8388608
sysctl -w net.core.wmem_max=8388608
sysctl -w net.core.rmem_default=65536
sysctl -w net.core.wmem_default=65536
sysctl -w net.ipv4.tcp_rmem='4096 87380 8388608'
sysctl -w net.ipv4.tcp_wmem='4096 65536 8388608'
sysctl -w net.ipv4.tcp_mem='8388608 8388608 8388608'
sysctl -w net.ipv4.route.flush=1
followed by restarting live555ProxyServer, it made no difference :(
You can see the videos being recorded with ffmpeg from live555ProxyServer
here: http://monitor.zanview.com
ny ideas at all what is causing this?
On 6 June 2013 14:55, Roman Gaufman <hackeron at gmail.com> wrote:
> I tried to change increaseReceiveBufferTo() in:
> liveMedia/BasicUDPSource.cpp liveMedia/MediaSession.cpp
> liveMedia/MultiFramedRTPSource.cpp groupsock/GroupsockHelper.cpp
>
> To be 2129920 instead of 50 * 1024.
> I also ran: sysctl -w net.core.rmem_max=2129920
>
> Is there anyway to use increaseReceiveBufferTo() directly in
> proxyServer/live555ProxyServer.cpp? - I'm not a developer and was not able
> to figure it out, I tried adding it in a few different places but proxy
> server wouldn't compile.
>
> After the above the result is the same :( - I can open several ffplay
> processes on the same machine reading from the IP camera directly and the
> image does not break, however if I start live555Proxy and play through that
> the image breaks every few seconds or so.
>
> What else could be different reading with ffplay directly and reading with
> ffplay through live555proxy? - I know the FAQ says: "There's nothing in our
> code that can be 'losing' packets." but something is causing this loss?
>
> I've eliminated network and followed the advice about OS but it's still
> breaking.
>
> I'm tearing my hair over this, please help :(
>
>
> On 5 June 2013 19:41, Roman Gaufman <hackeron at gmail.com> wrote:
>
>> Here is a short video of it in action:
>> https://www.youtube.com/watch?v=ShscnaNvNgw
>>
>> Output from live555ProxyServer: http://pastie.org/8011182
>>
>> Opening directly with ffplay 'rtsp://admin@192.168.88.13/media/video1' I
>> very occasionally see:
>>
>> [h264 @ 0x7f9c7c003a00] Missing reference picture, default is 0/0
>> [h264 @ 0x7f9c7c003a00] decode_slice_header error
>>
>> But the image doesn't break and plays perfectly.
>>
>> When I open through live555ProxyServer the output is completely packed
>> with stuff like this:
>>
>> [h264 @ 0x7fd93b024200] RTP: missed 1 packets
>> [h264 @ 0x7fd93b024200] RTP: missed 2 packets
>> Last message repeated 1 times
>> [h264 @ 0x7fd93b024200] RTP: missed 3 packets
>> [h264 @ 0x7fd93f80f600] negative number of zero coeffs at 77 33/6
>> [h264 @ 0x7fd93f80f600] error while decoding MB 77 33
>> [h264 @ 0x7fd93f80f600] concealing 4172 DC, 4172 AC, 4172 MV errors in I
>> frame
>> [h264 @ 0x7fd93b024200] RTP: missed 1 packets32KB sq= 0B f=6/6
>> Last message repeated 14 times 0KB vq= 469KB sq= 0B f=6/6
>> [h264 @ 0x7fd93f80e400] out of range intra chroma pred mode at 57 43
>> [h264 @ 0x7fd93f80e400] error while decoding MB 57 43
>> [h264 @ 0x7fd93f80e400] concealing 2992 DC, 2992 AC, 2992 MV errors in I
>> frame
>> [h264 @ 0x7fd93b024200] RTP: missed 1 packets42KB sq= 0B f=6/6
>> [h264 @ 0x7fd93b024200] RTP: missed 2 packets
>> [h264 @ 0x7fd93b024200] RTP: missed 1 packets
>> [h264 @ 0x7fd93b024200] RTP: missed 2 packets
>> Last message repeated 1 times
>> [h264 @ 0x7fd93b024200] RTP: missed 1 packets
>> [h264 @ 0x7fd93b024200] RTP: missed 2 packets
>> Last message repeated 1 times
>> [h264 @ 0x7fd93b024200] RTP: missed 1 packets
>> [h264 @ 0x7fd93f80f000] out of range intra chroma pred mode at 104 43
>> [h264 @ 0x7fd93f80f000] error while decoding MB 104 43
>> [h264 @ 0x7fd93f80f000] concealing 2945 DC, 2945 AC, 2945 MV errors in I
>> frame
>>
>> If I reduce the resolution from 1920x1080 to 640x480 and reduce the
>> bandwidth from 5mbit to 1mbit, I see no corruption through the proxy. It
>> seems to only happen with large resolution/bitrate.
>>
>> This is not a bandwidth issue as I have a gigabit switch and both the
>> camera and PC are connected straight to the switch.
>>
>> Also, I can open the camera stream multiple times from multiple instances
>> of ffplay (also from multiple machines) and there is no corruption, the
>> corruption only happens if opening through live555.
>>
>> The only modifications to the live555ProxyServer source code is ability
>> to change the listening port and: OutPacketBuffer::maxSize = 500000; //
>> bytes -- anything less and I see a bunch of errors like
>> MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too
>> large for our buffer size (60804). 316669 bytes of trailing data was
>> dropped!
>>
>> I can reproduce this on 4 different IP cameras: ACTi E32, ACTi D71,
>> Chinese noname and Sony SNC-CH210: ffplay works beautifully, live555proxy
>> works only on small resolutions and causes corruption on anything 720P or
>> up :(
>>
>> Any ideas?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130606/400a009c/attachment-0001.html>
More information about the live-devel
mailing list