On 07/21/2015 04:22 PM, Ali C. Begen (abegen) wrote: > This WG should spend whatever energy it has to focus on the primary use case > (interactive video) like RTCweb, conferencing, etc. I dont think we have the > energy to create a codec that will satisfy world’s all video demands.
I think that this would dangerously narrow the adoption of the codec. Would Opus have done nearly as well if it was only SILK? > So IPTV, game streaming and video sharing should be removed from the reqs > document. I am not so sure about video monitoring, though, as it has quite > many similarities to interactive video. I have many issues with the categories in the requirements draft: - All of the use cases should specify either a high latency or low latency requirement. - Error resilience should be moved out of the use cases. It can be implied by low latency, as can a lot of other things (transport, etc) - IPTV seems to intend to describe UDP multicast sorts of IPTV, which is not very common in the US but has some traction in other countries / as a backend for cable distribution. If this is the case, it really needs to be made clear. - The big list of resolutions is overly verbose and not necessary. A simple range of resolutions and frame rates would be better. - Game streaming needs to be split into high latency (twitch) and low latency (steam remote play) applications. > FWIW, I argue that interlacing should not be considered in this WG (or at all > for any video codec) moving forward. I think that interlacing tools should not be supported by the video codec, but it would be good to test on content that was originally provided in interlaced format and then run through a deinterlacer. How this is done exactly should be specified. _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
