The VideoLAN Forums

Is there any guarantee that video frame transmitted (UDP) are not lost on receiving?
Thanks

No guarantee. UDP is an ACK-less protocol -- the individual frames don't get ACKed by the client, the server doesn't retransmit them.
(That's a good part of what makes multicast UDP possible -- the server is opening a multimedia stream, that anyone can listen in on. The server neither knows, nor cares, who the receivers are.)

Inidividual packets have checksums. If there is a problem -- corrupted packet and/or packets arrive at the wrong time (say an individual packet went through a much longer set of router hops than the others), a frame may be dropped on the floor. Multimedia, however, is inherently fault tolerant. If you lose one or even two frames, it tends to be fairly imperceptible to the viewer.

That's why UDP is not recommended for pure data transmission -- the lack of data quality guarantees. (you can get around some of that by adding forward error correction, similar to what's done for RF, or adding other, higher level, acknowledgement type functionality, but it quickly gets to the point where you should just switch to TCP)

I wonder if anyone have tested the performance of received video during packet loss?

for instance, if the UDP packets contain incomplete MPEG data the device will have to wait for the next GOP/Keyframe before video clears up again.
Just reading data and sticking it onto an earlier frame will probably end up as green pulsating goo on the screen.

If I only had a proper line tester that could perform packetloss and noise insertion >_>

Is there any protocol that guarantee from packet loss (for example http,ftp)?
Suggestion for programmers of Videolan: is there any possibility to add a loss counter? It would be useful for "scientific" applications.

http://www.linktionary.com/t/tcp.html is a nice little backgrounder on packet formation in TCP.

I believe http includes ACKs, though could be wrong.

Any TCP session would handle ACKs and retransmits of lost packets. unless it times out...
But it will create more overhead and is not really well suited for broadcast type streams.
On the other hand it is usually established from the client instead so firewall rules are easier to handle in general.
An example is http streaming.

UDP has no inherent handling of lost packets, but the receiving client can have session control using out of band signalling (too technical for this forum )

Cheers!