Re: [video-codec] draft-filippov-netvc-requirements-01

["Ali C. Begen (abegen)" <[e-mail]>]

-----Original Message-----
From: video-codec on behalf of Thomas Daede
Date: Tuesday, July 21, 2015 at 5:10 PM
To: "[e-mail]"
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01

>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?

And please tell me where Opus is used in the entertainment world?

>
>> 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.

And where is the borderline?

>- 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.

I still argue iptv should be removed entirely.

>- The big list of resolutions is overly verbose and not necessary. A
>simple range of resolutions and frame rates would be better.

Agreed.

>- Game streaming needs to be split into high latency (twitch) and low
>latency (steam remote play) applications.

Indeed.

>
>> 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.

Are you interested in re-encoding of pre-encoded content? If so, why? If not, why bother with this test?

>
>_______________________________________________
>video-codec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/video-codec