Thank you for your feedback.
>Ali C. Begen (abegen) wrote: >> I understand that part but what I am saying is that developing a codec that >> will both perform enough well for interactive video and streaming video is a >> tedious task. Focusing on two different things will increase the risk of >> failure for this wg. Maybe the wg should consider solving the first (and the >> more important) problem first and then see whether it can tackle the second >> problem. > >Well, I agree we can probably significantly narrow the set of use cases >we want to consider, but I think narrowing it down to one is too extreme. I agree that use cases such as screencasting and game streaming considerable differ from other. As Mr. Zanaty proposed, a separate profile can be developed for them in future (if needed). There are two options: - I can remove them - I can keep them in the draft but I'll explicitly write that they don't have a high priority and a separate profile will cover them I prefer the 2nd option because screencasting and game streaming are use cases relevant to Internet video codec. > Maybe the wg should consider solving the first (and the more important) > problem first and then see whether it can tackle the second problem. Anyway, we should fix the requirements first (maybe making some of them optional). I guess WG roadmap could be worked out properly but it's the next step. >> 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: >Fair enough, but then I have to say that I disagree on some of the reqs >mentioned in the sections I suggested for removal. Most of them are not even >reqs but just a collection of what is in the market today. Obviously if those >sections are to stay, they need quite a bit work. That's true, they need quite a bit of work . That's what all of us are currently doing actually. >- All of the use cases should specify either a high latency or low latency >requirement I agree with it. By default, I assumed high latency. Where a low-delay configuration is needed, I mentioned it. I can write it explicitly > And where is the borderline? The borderline is the necessity of feedback. For example, in the case of video conferencing, replies are needed. In the case of IPTV broadcasting, user is switching between channels and doesn't want to wait long enough (more, than 1 sec). If a person selected a movie and wants to watch it, there is no reasons for any feedback. >- 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) I agree that this requirement is caused by the necessity of low-delay configuration. Of course, error resilience mechanisms can be implemented on transport level but they can be implemented on the codec level as well (e.g., redundant frames). For some use cases, such error resilience mechanisms can work more efficiently than error protection on the transport level. I propose to consider it as an optional requirements that should be complementary to the mechanisms implemented on the transport level. >> I still argue iptv should be removed entirely. >I would be fine with this. If it stays, it needs a much clearer use case >definition. IPTV is a very popular use case for Internet users. If it will be removed, it is reasonable to discuss not an Internet video codec but a codec for interactive video. I agree that use case definition should be described more clearly but I disagree that this application should be removed. >- The big list of resolutions is overly verbose and not necessary. A >simple range of resolutions and frame rates would be better. Agreed. >FWIW, I argue that interlacing should not be considered in this WG (or at all >for any video codec) moving forward. Agreed
_______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
