Re: [rtcweb] Alternative decision process in RTCWeb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

A few data point re video codecs (most of them were made already on the
rtcweb list):

1. A reasonably well tuned H.261 codec (including pre/post filters etc.)
will under almost any circumstance produce a better picture than MJPEG.
The intra coding tools of H.261 have a lot in common with JPEG, and H.261
offers inter picture prediction on top of that.

2. At 48 kbit/s, we (and anyone else who had products at the time) got
reasonably good looking video conferencing QCIF pictures (176x144 samples,
15 fps) on Pentium P54C hardware back in 1996.  The Pentium was also
loaded with an ISDN software stack, G.728 audio (which took the rest of
the 64 kbit/s of one ISDN B channel), rudimentary echo cancellation, and a
user interface based on Windows 95.

3. I¹m confident that a competent video coding engineer could clean-room
implement a complete, reasonably well tuned H.261 codec in less than a man
year.  If starting from the existing H.261 sources that can be found in
various software packages, it should take much less than that.

4. In pretty much all video coding algorithms, factors such as blurriness
and framerate are a function of the bitrate you allow the encoder to use.
Throw a megabit at H.261, and it will produce a good CIF picture.

5. The bitrate required per sample (for the typical picture sizes in use)
have approximately halved between each generation of video codecs.  That
is, to achieve the same visual quality, one needs approximately half the
bitrate when moving on one generation.  I wrote ³per sample² and ³for
typical picture sizes in use², because newer video codecs tend to be
optimized for larger picture sizes.  H.261 was clearly optimized for QCIF
and CIF, whereas H.265 shines at 1080p and above.

Many use the following generations in discussions like this:
1st (ca. 1989): H.261
2nd (ca. 1993): MPEG-1, MPEG-2,  (aka H.262)
3rd (ca. 1996): H.263, MPEG 4 part 2, VC1
4th (ca. 2003): H.264, VP8
5th (ca. 2013): H.265, VP9

5. Patent claims allegedly covering technologies in video coding according
to the 2nd and 4th generation standards are *today* actively litigated.

Stephan
  

On 12.2.2013, 14:52 , "Bjoern Hoehrmann" <derhoermi@xxxxxxx> wrote:

>* Phillip Hallam-Baker wrote:
>>MTI does not need to be a good choice, it merely needs to achieve
>>interoperability.
>
>The Working Group seeks interoperability in the area of real-time video,
>not in the area of slide shows or scaled animated icons. I suggested
>earlier to compare H.261 to sending a series of JPEG images or sending
>animated GIFs in terms of resolution, framerates, bitrates, and so on.
>If H.261 is shown to be much closer to H.264 CBP than it is to those, I
>would be willing to consider it.
>
>>People would use H.261 if that is all the clients at either end
>>supported.
>
>If they were unable to use other clients and really need low-resolution
>slide shows and there are no other factors to consider -- then perhaps.
>I myself would not voluntarily watch low-framerate or extremely blurry
>video if I do not have to.
>-- 
>Björn Höhrmann · mailto:bjoern@xxxxxxxxxxxx · http://bjoern.hoehrmann.de
>Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
>25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]