On 12. okt. 2013, at 08:53, Varun Singh <[email protected]> wrote:
> Hi Michael, > > In my experience, Video telephony applications do not generate any > b-frames. So #2 packets do not exist. Secondly some generate I-frames > only when they really have to (scene change or decoding packet chain > is corrupted) otherwise their GOP is set to infinity. But packet importance is more than just I- vs. P- vs. B-Frames - there are blocks that depend on each other, and the more data depends on data in a packet, the more important that packet gets. > For sending I-frames, there are many tricks that a sending endpoint > can play, it doesn't need to burst the whole frame immediately, it can > pace out (there are 10s of milliseconds) before the next frames is > generated. Alternatively, if the frame is too large, they can send > parts of the I-frame with the subsequent frames, this potentially > delays rendering. I don't know if any of these have been standardized. Probably no need to standardize this? > If a part of a frame is lost, the receiver can send a NACK or packet > loss indication Or reference picture selection. > > Another way is that the sending point uses unequal level of protection > (ULP) ie., not all packets or frames are FEC'ed. > Lastly it can vary the packet size, ie., it may do this by varying the > size of slices (combinations of macro blocks). > > Applicability of ARQ typically depends on observed end-to-end delay > and observed losses. The endpoint won't send a nack or a > retransmission if there are too many losses or if it thinks it won't > reach in time for decoding. Yes - the choices are really: 1. add FEC for the more important packets 2. do ARQ when applicable for the more important packets 3. somehow tell the network about the more important packets (but you can't, normally) and there are trade-offs between these choices. I just wonder if we need 3. as a part of the API to transport? Cheers, Michael
