jrsnen
commented
1 year ago Hello and thank you for interest in uvgRTP.
What you are describing is to my knowledge the default way uvgRTP works, giving all possible frames that did not lose fragmentation units to the user. The fragments belonging to frames that were not completed are deleted with garbage collection. There are plans for discarding frames lacking reference frames, but those have not been implemented yet and will be done via additional flags.
As for the latency, there is no way to get information for the reception of the first fragment, but when all the fragments are received, the installed hook in media_stream is called immediately so this can be used to measure last fragment timing.
I added a few lines of documention for packet loss.
Hope this clarifies issues, Joni
Consti10
Hello,
What's the default behaviour when rtp streaming via udp on packet loss, and can it be controlled ?
E.g. in our application, we stream via a lossy unidirectional wifibroadcast link that is protected by FEC but allows for rtp packet loss.
If we lose parts of a h264 frame (e.g. one or more rtp fragmentation units of a frame) we drop it. But if the next frame is complete, we feed it to the decoder anyways, which might / almost always results in artifacts, but this behaviour is actually preferred in our case.
Can we do that using uvgRtp ?
Also, is there a way to measure the following delay "first fragment of a fragmented rtp frame is read from the udp port" -> rtp_receive_hook() is called and/or "last fragment of fragmented rtp frame is read from the udp port" -> rtp_receive_hook() is called
Becasue we like to keep an exact track of the latency as frames travel through our display application.
Hope this isn't documented somehwere and I missed it, Constantin @ OpenHD