Re: [AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension

[Roni Even <[e-mail]>]

Hi Mo,
About the low motion, it can work with combination of low priority. So low dropping low priority with low motion is better than low priority with high motion.
As for the priority, this is intended for the non-scalable case where we do not provide any information about the content of the video frame which can provide better discard policy for implementations

We did some tests and this works well enough.

Roni

From: Mo Zanaty (mzanaty) [mailto:[e-mail]]
Sent: יום ב 26 יוני 2017 22:12
To: Roni Even; [e-mail]
Subject: Re: [AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension

Hi Roni,

Low motion can be inferred from low bitrate. But I don't see how any low motion indicator is useful for discard decisions. If you discard the wrong packets, the distortion will be even more extreme for low motion/bitrate content, since the focus is concentrated on one or few regions of low motion which are very easy to corrupt with a single discarded packet. If you get lucky and discard the right packets (skip blocks of static regions), that is just plain luck with no help from frame marking.

Priority bits are arguably more useful for discard decisions. However, when multiple frames are truly discardable (e.g. they are never used as references), there is usually a temporal layer hierarchy that can be used to infer the priority from TID.

I would like to hear from others if there is any strong argument for including or excluding a low motion indication bit or priority bits.

Thanks,
Mo


From: avt <[e-mail]<mailto:[e-mail]>> on behalf of Roni Even <[e-mail]<mailto:[e-mail]>>
Date: Thursday, May 18, 2017 at 5:11 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension

Hi,
The current support for non-scalable frame marking provide limited information for making good decisions about which packets to drop in congestion case. Currently there is only 1 bit for marking discardable packets.

I propose using three of the remaining  four bits (currently 0000) with the following semantics:

Low motion bit (M) – specifying that this stream or the current packets have low motion (example – a conference room meeting ), removing them will just reduce the frame rate with less artifacts comparing with a live video of a basketball game.
Priority (P) two bits – allowing to prioritize frames in a stream. For example if we have a sequence (IBBBBPBBB…) even though all B frames may be defined as discardable, they may have different relation to the other frames and by using priority we can make better discarding decisions.

The way it may work for example  is that when there is a need to discard packets  the middlebox will choose from the discardable packets the ones with low motion and low priority and continue dropping low motion and higher priority. The dropping policy should be implementation dependent.


Roni Even