Subject: [rtcweb] DRAFT minutes for RTCWEB day two

From: Ted Hardie <[email-masked]>
Date: Fri, 29 Mar 2013 16:01:51 -0700

Attached are draft minutes for the second day of the RTCWEB meetings at
IETF 86, please review and send comments to the list.

thanks,

Ted

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 29 Mar 2013 16:26:45 -0700

> IETF 86, please review and send comments to the list.

I predict that a lot of people that are not familiar with the core group of
RTCweb participants will read this minutes, so I would suggest to check that
the first time a name appears in the minutes, it is the full name of the
person, not just the first name (and perhaps with the full name all uppercase
so it is easier to find).  E.g. in the first paragraph, "Martin" should be
replaced by "Martin Thomson" or "MARTIN THOMSON".  Same for "Giri", "Gaelle",
"Daryl", "Kalyani", "Hadriel".

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Leon Geyser <[email-masked]>
Date: Sat, 30 Mar 2013 09:47:22 +0200

In the meething it was mentioned that 'rate control' was used for the
encodings. Does the 'rate control' constrain the encoder to stay within a
certain bitrate without spiking too much? If that is the case then we
should test with 'rate control'. If for example I have a 256Kbit/s upload
speed and the encoded stream is sent at 240Kbit/s then we don't want it to
spike to 280Kbps for a second or two. The encoders need to be tested with
settings that would be used in real-world scenarios.

Ted Hardie from the floor then said that the point of an MTI in this
> working group was to avoid negotiation failure and that you would always be
> able to negotiation away to a different one you share with the peer...

I agree, if both browsers have VP8 or both have H.264 then the MTI will be
skipped. The MTI is only there in case of negotiation failure. Instead of
ASCII art why can't we fall back to 24 year old H.261 or are there also IPR
issues with it?

Does anyone know the IPR status of H.261?
On the ITU website it lists some patents registered 11 years after the
other patents: http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS

Here are some of my opinions:
- If Google resolves the IPR issues around VP8 then VP8 should be MTI. (No
negotiation failure)
- If it can't be resolved and H.261 can be freely implemented then H.261
should be MTI. (Browsers will still implement H.264 or VP8)
- If H.261 also has IPR issues then no codec should be MTI. (Browsers will
still implement H.264 or VP8, but there will be negotiation failures. Audio
only.)
- If H.264 is MTI then not all new browsers will be willing to implement
WebRTC. Only the popular browsers will use WebRTC. So much for an open
web...Also other programs interfacing with WebRTC would need licensing for
H.264.

On 30 March 2013 01:26, Marc Petit-Huguenin <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJRViMzAAoJECnERZXWan7End0P/1z11JwuljlRMNPrT7urE584
> OwP4oQ5ayj+e9/E05NCoMMCk6guLSlPEvpcoBKeEjTFeLuN1k+R0HC9X35zYYX+F
> hsMq5px5+sN4GfoYCHkg9bT9lA9y718kSBhoUw2IBoYS3xPI3dnQwvXjzWV4UevU
> xNP7HP0VPBm/wTTVaohX2kU3VcJTBol0FsdkIJPVJ/+19KpFm6cqLaPIGx39atW3
> AQzjEhd7BzlxOEn5xK4FOy0tje9v3Hf+ifGihCDJDMTid9bFI4fGbOdKv/jkr9lG
> XHA/Uv0C31FMMBbQ1Xtni3/xTTFKuHNhcaaBDPX/yuKLbmWBEuOtycsBCUviUPs5
> //88tT2Y1WVWUNvc6WHfEjmpGeThT3YmRjDkFRZAnVSq8rKnxJlnDJdUzvFkBdVg
> /B2wh86C6lvkh6B48d322EEJ1iMnAjWSOs2+S1x6kkTR/ckk1MwEzxl8/cpkPOJ/
> UMmCzQW5abwRA84IV2LPSemuSnUBfShWxAN50JEIUBuJPD/8rEH1vOoZkBE+SF0g
> bPJswDJN/maJjXb12GEaKhZMp/ghZqIQapoaBNLVAmWetTkOhRcICLpF4tF5yGkW
> 6lLgSOUwF4RoK68r5sP0RaHHDE1tzUt4Tp2WsTf6yONOaYM4jpjCKF1/8j7JjClk
> vnk5NuNAHxsq06pnuA1p
> =WN5e
> -----END PGP SIGNATURE-----
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>