Re: [Live-devel] Fragmented intra frames

2016-09-23 Thread Ross Finlayson
> In some of my tests which are rtp over tcp, the lost packets can be > re-transmitted. The ReorderPacketBuffer then can take the rtp packets inside > that may be out of sequence RTP packets that are sent using RTP-over-TCP should never be ‘out of sequence’ - because a TCP stream always deliver

Re: [Live-devel] Fragmented intra frames

2016-09-23 Thread Jeff Shanab
I have been using a network emulator to introduce network issues to test the robustness of our code and found this conversation timely. In some of my tests which are rtp over tcp, the lost packets can be re-transmitted. The ReorderPacketBuffer then can take the rtp packets inside that may be out o

Re: [Live-devel] Fragmented intra frames

2016-09-23 Thread Ross Finlayson
> I have never quite got the advantage of frame fragmentation, i.e. let's > consider a large intra frame and the two cases: > > 1) Sending the intra frame as a single huge packet > > 2) Sending the intra frame as a series of smaller packets Your use of the word ‘packet’ here is strange (and, I

Re: [Live-devel] Fragmented intra frames

2016-09-23 Thread sampsa
Thanks Ross, Still one tiny bonus question / discussion, please. I have never quite got the advantage of frame fragmentation, i.e. let's consider a large intra frame and the two cases: 1) Sending the intra frame as a single huge packet 2) Sending the intra frame as a series of smaller packet

Re: [Live-devel] Fragmented intra frames

2016-09-23 Thread Ross Finlayson
> The only logical way of making sense of all this is .. > > UDP packets: max ~ 65 kB Yes, in principle. However, our code, by default, sets a maximum UDP packet size of about 1500 bytes. (You can change this by calling "MultiFramedRTPSink::setPacketSizes()”, but you should do so only if you

Re: [Live-devel] Fragmented intra frames

2016-09-23 Thread sampsa
Dear Ross, As always, thank you for your thorough explanation. Regarding this same thing, today I stumbled upon a situation where "afterGettingframe" is passing me an I-frame that is 73kB+ big ! I have read this post: http://lists.live555.com/pipermail/live-devel/2013-April/016816.html and

Re: [Live-devel] Fragmented intra frames

2016-09-05 Thread Ross Finlayson
> However, with ffmpeg casted stream, I get frames along these lines (this is > what "afterGettingFrame" of my modified DummySink passes me): > > nal_unit_type : 7 ( Sequence parameter set ) > nal_unit_type : 8 ( Picture parameter set ) > nal_unit_type : 5 ( Coded slice of an IDR picture ) > nal_