Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00

[Basil Mohamed Gohar <[e-mail]>]

I think the value of including the use-case of VOD in conjunction with 
RTCWeb is that, in most cases, the application which will be playing VOD 
will be the same one used for VOD (e.g., the web browser).  Targeting 
both will reach a wider audience, and there are cases in the life cycle 
of RTCWeb content were it will begin as an RTCWeb session but then 
end-up as VOD.  An education might do a live session for students using 
RTCWeb for video conferencing to a wide audio, and then archive that 
same video to serve as VOD later.  Many "live" examples can fit this 
method of usage as well.  Being able to use the exact same bits, and not 
need to reencode, would add a lot of value to spec and open-up a lot 
more opportunities.

I think this doesn't subtract at all from the "significant driver" 
aspect, but to ignore it is to cut out an enormous segment of the 
potential usage and benefit of having a RF, standardized video codec.

On 12/04/2012 10:50 PM, Kevin Gross wrote:
> Good stuff. Thanks for including the DiBona rebuttal - good points 
> made there, but, like you say, you have significant experience that 
> indicates the less optimized approach is not successful in the 
> "market". We should not ignore that.
>
> We do need to decide how important VOD is. I'm not sure that wasn't 
> ironic understatement in your response. My understanding is that a 
> significant driver for this codec effort is RTCweb and there's not 
> much VOD there.
>
> Kevin Gross
> [phone]
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org 
> <http://www.X192.org>
>
>
> On Tue, Dec 4, 2012 at 4:40 PM, Timothy B. Terriberry 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Kevin Gross wrote:
>
>         There are 8 applications listed in section 3. VOD is the only
>         one that
>         clearly benefits here. How much emphasis do we want to put on that
>         application?
>
>
>     I've seen estimates that at peak hours this constitutes 50% of the
>     Internet bandwidth usage of the United States [1]. That might be
>     worth emphasizing.
>
>
>         Why? The motivation for bandwidth efficiency is never convincingly
>         substantiated in the draft. I'm aware that bandwidth
>         efficiency is a
>         very respected metric among codec developers. I'm questioning how
>         important it actually is for applications and users given that
>         available
>         network bandwidth is increasing much faster than required media
>         bandwidth and the efficiency increases we expect to be able
>         to achieve with a new codec are comparatively modest.
>
>
>     The users seem to think it is pretty darn important. See, for
>     example, Chris DiBona's claims that switching to Theora would
>     break the internet [2] (rebutted [3], for the record, but the
>     quality bar has moved beyond where it was in 2009, and will have
>     moved farther before we're done).
>
>     I'll cite our experience with Opus as another example: it always
>     had excellent latency and scalability, but people did not start to
>     get really excited about it until the quality started to exceed
>     that of the best high-latency codecs (this is not quite true: I
>     gave a presentation on CELT, one of the predecessors of Opus, at
>     LCA 2009, and after explaining that bitrate efficiency was
>     explicitly a non-goal, had a number of excited people come up to
>     me and ask, "How long until this compresses better than Vorbis?").
>     If you want people to use your codec, this matters.
>
>     We've tried twice now to get people to use codecs that were
>     substantially less complex than their competitors but which did
>     not resoundingly beat them in bitrate efficiency (to put it
>     generously). It hasn't worked.
>
>     I'll also point out that HEVC's target was 50% less bitrate than
>     H.264 High Profile at > HD resolutions. I don't have numbers on
>     how close they got off-hand, but I think most users would agree
>     that that is not a modest number. If we don't at least match this
>     performance, I'm not going to say we've failed, but we should
>     _certainly_ be doing better than the RF options we already have.
>
>     [1] http://www.sandvine.com/news/pr_detail.asp?ID=312
>     [2]
>     http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020380.html
>     [3] http://people.xiph.org/~greg/video/ytcompare/comparison.html
>     <http://people.xiph.org/%7Egreg/video/ytcompare/comparison.html>
>
>     _______________________________________________
>     video-codec mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/video-codec
>
>
>
>
> _______________________________________________
> video-codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/video-codec


-- 
Libre Video
http://librevideo.org