Re: [rtcweb] Agenda time request for draft-dbenham-webrtcvideomti

[Stephan Wenger <[e-mail]>]

Hi Adam,

I generally agree with your comments, and also with Randell's comments
posted somewhat later in this thread.  Unfortunately, there is no good way
to compare bitstream efficiency (in contrast to encoder quality) without
theoretical analysis.  A few bits and pieces of theoretical analysis
exist, have been cited in this discussion already, and generally come out
in favor of H.264 (even baseline), but they are arguably tainted by their
respective authors' commercial interest.

That said, I somewhat disagree with your comment on the influence of
hardware support for the moderate complexity of H.264 or VP8.  Yes, the
search tree of the syntax even of a 10 year old standard like H.264 is so
large that you can max out a fairly large number of any CPU or DSP or FPGA
in existence today.  However, the quality gain you get by throwing really
large amounts of processing power to an encoder, over what is common on a
desktop PC today, is rather limited.  For video conferencing content, I
would wager a guess that it is less than 1 dB.  That is an invisible
quality difference to almost all non-expert viewers.  The reason is that
those encoders nowadays got their search and mode decision heuristics
right.  Mode decision and motion search rarely take more than a few dozen
per cent of the overall cycle budget.  The rest goes to things like DTC
and entropy coding, and is dependent only on factors chosen by the
application (picture size, frame rate, bitrate).  So for the purpose of
comparing real-time H.264-generation video encoding with picture sizes up
to, say, 720p60, it does hardly matter whether you run your encoder on a
dedicated platform or an a desktop class CPU.  And we are very close to
the time where it does not matter any more for 1080p60, either.

For modern codecs, like H.265, some hardware acceleration will continue to
be desirable for a few years, especially with picture sizes of 4K and
beyond.  But eventually, and I believe almost certainly over the
commercial lifetime of the standard, general purpose CPUs will catch up.

Finally, no one I know uses DSPs for video encoding anymore.  Those
dedicated hardware H.264 encoders are almost all hardware-acceleration
units for things like motion search and CABAC, placed around a fairly
powerful general purpose CPU that runs heuristics not much different from
what a pure software implementation uses.

Stephan 



On 2.26.2013 12:29 , "Adam Roach" <[e-mail]> wrote:

>I want to caution people about what they are -- and are not -- seeing in
>the demonstration videos pointed to by this draft. I don't think the
>draft is intentionally deceptive on this point, but a casual reader
>might fail to make a somewhat subtle (but catastrophically important)
>distinction.
>
>The videos in section 4 are a pretty convincing comparison between
>hardware encoding and software encoding on same-class platforms. They
>happen to use different codecs, but that's a non-factor compared to the
>overwhelming difference between encoding horsepower.
>
>What they absolutely don't show is a comparison of H.264 to VP8. I don't
>beleive the authors intend to do so, but other parties might be tempted
>to construe the videos in that light. Doing so would be a
>straightforward application of "trick 3b" from "How to cheat on video
>encoder comparisons" (http://x264dev.multimedia.cx/archives/472). Of
>*course* coding on a DSP will look better than coding on a CPU that
>draws roughly the same power.
>
>I'm not discounting the availability of H.264 hardware encoders as a
>factor, and the videos do a pretty good job of showing off the
>advantages of hardware encoding. But that's all they show.
>
>/a
>
>On 2/26/13 12:08, Cullen Jennings (fluffy) wrote:
>> I would like 25 minutes for presentation of information key to
>>draft-dbenham-webrtcvideomti that is not interrupted and 15 minutes for
>>Q/A for the work.
>>
>> We have spent many hours of meeting time discussing the way we were
>>going to make a decision around codecs and information needed, but we
>>have not yet spent time discussing the actually information to make the
>>decision. This draft addressees several very key issues, including the
>>actually quality comparison of VP8 and H.264. I think that spending any
>>less time than this would result in a situation where the WG was not
>>making an decisions with the information available. Similarly, other
>>people that have written other drafts with similar or different views
>>also need to speak up about how much time they need and that we make
>>sure everyone has time to explain the key information, people have time
>>to ask questions about it, and we can make an informed decisions instead
>>of having to discuss the video codecs at many future meetings.
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb
>