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.
From the perspective of my employer (Mozilla), for example, we need a codec that works in the <video> tag and in WebRTC, and we currently see a lot more usage of the former than the latter.
Focusing on interactive first may still be smart, but "success" for us means solving both problems. I don't think anything we write in our requirements draft precludes the WG from deciding to publish a codec that only solves one of them, though, if we later decide the other is too hard.
_______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
