Subject: Re: [rtcweb] Alternative decision process in RTCWeb

From: Roger Jørgensen <[email-masked]>
Date: Sat, 30 Nov 2013 14:45:10 +0100

On Thu, Nov 28, 2013 at 2:52 PM, Eliot Lear <[email-masked]> wrote:
> While I appreciate the difficult position the chairs are in, I don't
> agree with the approach and I believe it is inappropriate for the
> working group to make such a decision.  Working groups don't vote.  Want
> to change that process?  Better gain IETF consensus first.  And I will
> argue against any such attempt.  There are plenty of other standards
> bodies that do vote.  Go to one of them if that's what you want.

Have to agree on this, no voting.

And if the problem is that bad, that it's impossible to reach
consensus in the WG, what about replacing the chairs? ...

--- Roger J ---

> Eliot
>
> On 11/28/13 2:35 PM, Hervé wrote:
>> Dave Cridland wrote:
>>
>>> 2) If the Working Group does want to mandate a single codec, is there
>> consensus for one of the alternate decision-making processes described
>> in RFC 3929? This is our best guess at what to do here; despite it being
>>  a (presumably expired) Experimental track RFC.
>>
>>
>> RFC 3929 has been mentioned on the rtcweb mailinglist and during the last meeting.
>> http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html
>> http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_II
>>
>>
>>> If nobody else appeals the decision, then I will - assuming I'm allowed to - if it gets this far.
>>> it's not clear to me that there is a consensus surrounding the voting
>> rules - they've certainly yet to be summarised in one place based on the
>>  discussion that has occurred so far.
>>
>> No decision yet. Per
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html today
>> is the last planned day for comment/discussion on the _proposal_ to vote,
>> before the proposal gets updated. A further call for consensus to use
>> the proposal would follow after updating.
>> Perhaps you'd like to get involved now rather than later.
>>
>>
>> Here's what I sent to someone else regarding the proposed schedule:
>> Nov 28          last day of comment/discussion period on proposed _voting process_ http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html
>>
>> after Nov 28    WG chairs will update, if necessary, the process proposal
>> after update    normal IETF process to reach consensus about adopting the (updated) process proposal
>>
>> +2 weeks        last day of the consensus call about adopting the voting process
>>
>>
>> IF consensus was reached to use the voting process in those 2 weeks after the update for that process, ONLY THEN would the (2 week) voting period start (if that wasn't changed in the update/concensus call).
>>
>> So the voting process can theoretically _start_ Dec 13 at the earliest, if accepted. Probably later (if ever), given that updating the proposal is unlikely to be instantaneous.
>>
>>
>> I hope that made it clearer. The source for this is the bottom section of http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html
>>
>>
>> - Hervé
>>
>

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Mary Barnes <[email-masked]>
Date: Mon, 2 Dec 2013 09:34:41 -0600

On Thu, Nov 28, 2013 at 1:27 PM, Michael Richardson
<[email-masked]>wrote:

>
> Ted Lemon <[email-masked]> wrote:
>     > On Nov 28, 2013, at 11:29 AM, Dave Crocker <[email-masked]> wrote:
>     >> As merely one obvious example, people can simply be tired of the
>     >> impasse and eagerly seek progress and be willing to settle on any
>     >> mechanism they think will fairly break it -- even if it works
> against
>     >> the outcome they prefer.
>
>     > The one tidbit you may be missing is that the working group
>     > specifically chose not to do a coin toss.  So "willing to settle for
>     > any mechanism" clearly doesn't apply in this case.
>
> That tells me that the participants are not willing to live with losing and
> move on, and so no voting process will work either.
>
[MB] Exactly. [/MB]

>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 02 Dec 2013 20:27:20 +0100

* Ron wrote:
> 2. Can anybody show a sustainable objection for why we _can't_ use H.261.
>
>   If they can, we're probably doomed.  If they can't we have an initial
>   choice for MTI.

I have not seen a convincing argument that H.261 performs well enough to
permit real-time video communication at reasonable quality and bitrates.

I have not seen recent statistics for Germany but I suspect it is common
that household members share a line with an upstream of around 640 kbps,
that would basically allow for two 320x240 H.264 CBP + Audio streams at
30 fps in good quality. Would H.261 permit at least one stream at the
same quality? If not, then nobody would use H.261-only WebRTC products,
and people are not going to appreciate if a VP8 product connecting with
a H.264 product falls back to H.261 to avoid negotiation failure.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Mon, 02 Dec 2013 15:16:38 -0500

> a H.264 product falls back to H.261 to avoid negotiation failure.

The problem with your problem is that you've set an ambiguous bar that
is also irrelevant - "reasonable quality".  That is not the purpose of
an MTI codec.  Rather, an MTI codec is there to prevent the absolute
worst case of two endpoints being unable to communicate via video at all
due to codec negotiation failure.  And MTI codec is also not mandating
that it be the ONLY codec or even the BEST codec to be used.  It's there
specifically to ensure communication can ALWAYS happen, no matter what.

It's a codec of last resort, and should not be compared against the
state of the art that's available elsewhere.

It also has the added bonus of being ridiculously simple to implement,
both for encoding and decoding, compared to what's out there.

It really fits the bill as being something to serve as the worst case
scenario that's not catastrophic.

And as stated elsewhere on this list, some tests have been done on CIF
videos (352x288) at lower framerates at 256kbps, and got acceptable
results.  In fact, it was designed in the area of ISDN (64k + 64k), so
it will, in fact, work at the stated bitrates you're talking about here.
 We'd need also to add only about 16kbps for a killer Opus speech
channel, and you'd be set.

The fight against H.261 as MTI is really not about quality or
efficiency, but rather, about forcing a royalty-bearing format on what
should be an open standard and to save a few big players some
implementation dollars because they might want to reuse some existing
hardware, all of which are secondary points in this charter compared to
a universally applicable MTI video codec.

-- 
Libre Video
http://librevideo.org

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 02 Dec 2013 23:52:26 +0100

* 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:[email-masked] · 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/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Dec 2013 14:59:40 -0800

> video if I do not have to.

I love playing devil's advocate...  But you need to remind yourself
that a) you do the audio equivalent just about every time you make a
phone call on the PSTN (which I grant, you might not do, the world is
moving on), and b) those specific problems can be addressed with the
application of more bandwidth or by having teeny postage-stamp videos.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 3 Dec 2013 10:07:32 +1100

> a universally applicable MTI video codec.

I guess one thing that the vote should determine is whether implementers
are more accepting of falling back to an old codec (Theora, h.261, etc)
over implementing decoding for 2 modern codecs (h.264 & vp8) plus encoding
of one of them.

Is the vote set up in a way that will let us answer this question in the
end?

Silvia.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 03 Dec 2013 03:00:36 +0100

>specifically to ensure communication can ALWAYS happen, no matter what.

I think it is highly relevant whether the mandatory-to-implement codec
supports two people in typical German households communicate via video
in sign language, and how it does so relative to non-mandatory options,
as a simple example. If H.264 supports the scenario and H.261 does not,
then selecting H.261 does not in fact prevent the absolute worst case
and does not ensure that communication via video can always happen.

>a universally applicable MTI video codec.

Like I said, I have not seen a convincing argument that H.261 performs
well enough, and the implementation techniques that can reasonably be
assumed to be unencumbered are old enough that I think it is fair to
assume without investigating myself that selecting H.261 as only manda-
tory-to-implement video codec could work on paper, but not in practise.

I read the "irrelevant" responses as essentially advocating that we may
just as well make sending raw and unencoded RGB data the MTI codec. I'm
more than willing to hear better arguments. The same goes for the H.263
option that has been suggested.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 3 Dec 2013 02:36:19 +0000

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Dec 2013 18:43:52 -0800

> I think it is highly relevant whether the mandatory-to-implement codec supports two people in typical German households communicate via video in sign language...
 
[BA] This isn't just an issue for Germany.   An inability to support sign language would be "highly relevant" to compliance with the proposed Section 255/508 revision in the US.  
 
From: http://www.access-board.gov/attachments/article/490/draft-rule.pdf, Section 408.8: 
 
"408.8 Video Communication.  Where ICT that provides two way voice communication includes real time video functionality, the quality of the video shall be sufficient to support communication using sign language."

---

From: cowwoc <[email-masked]>
Date: Mon, 02 Dec 2013 21:46:47 -0500

On 02/12/2013 9:00 PM, Bjoern Hoehrmann wrote:
> in sign language, and how it does so relative to non-mandatory 
> options, as a simple example. If H.264 supports the scenario and H.261 
> does not, then selecting H.261 does not in fact prevent the absolute 
> worst case and does not ensure that communication via video can always 
> happen. 

Bjoern,

I'd like to point you to http://www.netindex.com/upload/allcountries/ 
for two reasons:

 1. It states that Germany has an average upload rate of 3.13Mbps.
 2. It shows that upload speeds are increasing over time.

> option that has been suggested.

H.261 is meant as a fallback only in the case that the market cannot 
agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the 
market cannot agree at runtime, what makes you believe that that same 
sizable portion can agree on a MTI codec? And a final question, in case 
you disagree with everything I've written so far: How do you advocate we 
proceed in light of the fact that we already tried to (and failed) to 
reach consensus around VP8 and H.264?

Gili

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Mon, 02 Dec 2013 22:10:14 -0500

On 12/02/2013 09:43 PM, Bernard Aboba wrote:
>  > I think it is highly relevant whether the mandatory-to-implement
> codec supports two people in typical German households communicate via
> video in sign language...
>  
> [BA] This isn't just an issue for Germany.   An inability to support
> sign language would be "highly relevant" to compliance with the proposed
> Section 255/508 revision in the US. 
>  
> From:
> http://www.access-board.gov/attachments/article/490/draft-rule.pdf,
> Section 408.8:
>  
> "408.8 Video Communication.  Where ICT that provides two way voice
> communication includes real time video functionality, the quality of the
> video shall be sufficient to support communication using sign language."

I believe this is a moot point for H.261, as even at relatively low
bitrates, in an unoptimized configuration, it can produce sufficiently
high quality to clearly convey a person communicating with sign
language.  Please see my recent post entitled, "H.261 encoding samples
at typical bitrates - sign language example" or the actual examples here
(please see the text file that explains the real rates that ffmpeg
ended-up using):

http://media.basilgohar.com/rtcweb/

-- 
Libre Video
http://librevideo.org

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 03 Dec 2013 14:15:46 +0100

> 2. It shows that upload speeds are increasing over time.

That seems extremely unlikely to me, basic offerings like Vodafone's
"DSL 6000" come with around 640 kbps upstream, Telekom's "Call & Surf
Basic" comes with "up to 1 mbps", where I am right now the best DSL
available has less than 384 kbps *downstream*; that does not add up
to a situation where the median household has 3 mbps without extra-
ordinary evidence ("average" over ones that care to test can naturally
be expected to be much higher than the median over the population.)

>reach consensus around VP8 and H.264?

If I were to believe VP8 and H.264 are not royality-free options that
can be used in Free implementations of the protocol then the mandatory-
to-implement codec is likely their only option to communicate with
commercial implementations. If the only option is "not good enough", I
might prefer the Working Group say so instead of offering a fig leaf.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Max Jonas Werner <[email-masked]>
Date: Tue, 03 Dec 2013 14:35:51 +0100

On 03.12.2013 03:46, cowwoc wrote:
[...]
>  1. It states that Germany has an average upload rate of 3.13Mbps.

This statement does not say anything about the upload rate of the
majority of users.

>  2. It shows that upload speeds are increasing over time.

Probably, but they are still extremely low in comparison to the
downstream rate.

/max

---

From: John Leslie <[email-masked]>
Date: Tue, 3 Dec 2013 09:16:14 -0500

Bjoern Hoehrmann <[email-masked]> wrote:
> commercial implementations.

   We have strong evidence that implementors believe there is significant
IPR risk in either of these. That is what matters -- not whether someone
else thinks they're "royalty-free".

> If the only option is "not good enough", I might prefer the Working Group
> say so instead of offering a fig leaf.

1: There's always more than one option. If folks think H.261 is as bad
   as you think it, transcoding services will arise, and I expect most
   folks that care about video quality to find browsers which support
   VP8 _and_ H.264;

2: Any codec will be "good enough" for some uses, and not for others;

3: Nothing prevents the Working Group from adding language about the
   limitations of H.261;

4: This is not about "offering a fig leaf" -- it's about preventing
   negotiation failure until the market can settle on some better way:
   I remind you that codecs better than VP8 and H.264 are already
   starting to see use;

5: Whatever _you_ might prefer, there are others who would prefer to
   get this specification out the door and widely implemented.

--
John Leslie <[email-masked]>

---

From: cowwoc <[email-masked]>
Date: Tue, 03 Dec 2013 10:57:23 -0500

Bjoern,

I don't understand. What is the practical benefit of declaring "No MTI" 
(as you seem to be implying) over considering H.261 as MTI?

 1. What you could accomplish with with "No MTI" you could accomplish
    with H.261 as MTI (and more).
 2. What might not be good enough for one business/use-case will be for
    another. Why penalize all use-cases?
 3. What might not be good enough in Germany (today) might be good
    enough in North America and Asia. Why penalize the rest of the world?

Things *will* improve in Germany (supply will follow demand). Up until 
recently, Canada was stuck with 1MBps upload rates for over a decade. 
Out of nowhere we started getting upload rates of 10MBps, 20MBps and 
even 50MBps. The technology is there. The only thing holding it back are 
politics (monopolies in our case) and demand.

Gili

---

From: cowwoc <[email-masked]>
Date: Tue, 03 Dec 2013 10:57:26 -0500

> This statement does not say anything about the upload rate of the

The source data is here: http://www.netindex.com/source-data/

It should be possible to calculate the median from there.

> Probably, but they are still extremely low in comparison to the

Why does that matter?

Thanks,
Gili

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Dec 2013 11:40:35 -0800

On 11/29/2013 12:22 AM, Roberto Peon wrote:
> The only reason to specify a must-implement is to increase interop; if
> mandating a codec does not increase the amount of interop, why do it?

If the base specification does not provide enough information for basic 
interoperability, what is the benefit in standardizing it?

An alternative that I believe has already been mentioned is to 
standardize /both/, but separately.

Under two different names, which then lets the market decide on whether 
either will succeed.

Letting the market decide amongst competing choices used to be something 
the IETF did more commonly.  One of the more colorful examples was SNMP 
vs. CMOT.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Dec 2013 15:12:33 -0500

> permit real-time video communication at reasonable quality and bitrates.

That is irrelevant.

If someone can support HD video over a 300 BAUD connection, the technology
is almost certain to be proprietary. That does not mean that the IETF has
to accept the proprietary technology as MTI because it is the only one that
supports the needs of 300 BAUD users, it means that that group of users may
not be supported by the MTI CODEC.

MPEG2 will come out of patent in the nearish future and it is a not
terrible choice. It is certainly not the best choice but it isn't a
horrible one.

People would use H.261 if that is all the clients at either end supported.
The value of the H.264 patent pool would be reduced from the ability to
perform the application to a quality issue for some subset (a clear
minority) of the user base.

We knew that there were real security and performance problems with 3DES
when we made it MTI in TLS 1.0 but that was the best choice available at
the time.

If there was an optimal technical choice that had no other consideration
there would be no need for MTI clauses at all.

-- 
Website: http://hallambaker.com/

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Dec 2013 17:11:27 -0500

>>>>> "Ron" == Ron  <[email-masked]> writes:

    Ron>  2. Can anybody show a sustainable objection for why we _can't_
    Ron> use H.261.

    Ron>    If they can, we're probably doomed.  If they can't we have
    Ron> an initial choice for MTI.

This is a fine approach, but you also need to get consensus that
least-objectionable-choice is a good decision mechanism.
That doesn't follow directly from we want an MTI codec.

If you think you can get consensus behind the process you propose then
go for it.
However don't skip important steps.

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 3 Dec 2013 15:51:39 -0500

Well I think we need to convene the Supreme Court of Protocol Engineering
Standards ..aka SCOPES.

Use the noncom process to empanel a tribunal of 9 individuals who have never
ever subscribed to a RAI list.  That might be hard..I admit. 

We have the briefs... we just need oral arguments.  London ... black robes.
Or at least black t shirts.

Then an impartial verdict can be rendered and we can get on with the rest of
our lives. 

Of course any resemblance to the Scopes trial in Tennessee would be purely
coincidental.

http://en.wikipedia.org/wiki/Scopes_Trial

I want to do the ..

"Oyez! Oyez! Oyez! All persons having business before the <fill in the
blank> , of the Supreme Court of Protocol Engineering Standards, are
admonished to draw near and give their attention, for the Court is now
sitting.  IPv6 forever..."

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Monday, December 02, 2013 5:11 PM
To: Ron
Cc: IETF Discussion; Michael Richardson; [email-masked]; Dave CROCKER; Eric
Burger; [email-masked]
Subject: Re: [rtcweb] Alternative decision process in RTCWeb

If you think you can get consensus behind the process you propose then go
for it.
However don't skip important steps.
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: David Singer <[email-masked]>
Date: Tue, 03 Dec 2013 17:25:24 -0800

> offers inter picture prediction on top of that.

That may be true, but everyone has a JPEG implementation, its status is clear, and it does convey pictures.  The RTP carriage is trivial, error resilience is excellent (all I pictures).  Yes, you get low frame rates or small pictures, but it’s a fallback.

Motion JPEG is not as bad a choice as all that.  Anyone could implement it, and we could terminate this endless discussion with a decision that could, in fact, be respected by implementations.

I still doubt whether people would consider it worthwhile spending engineer time and so on, on developing an H.261 solution, whereas JPEG (as a codec) is still in heavy use elsewhere.

Nonetheless, I still think H.263 deserves a more careful look.  I know Stephan is negative, but so far, he’s the only one.  For those who DON’T currently implement H.263, could/would you?

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Maik Merten <[email-masked]>
Date: Wed, 04 Dec 2013 10:22:30 +0100

> Nonetheless, I still think H.263 deserves a more careful look.  I know Stephan is negative, but so far, he’s the only one.  For those who DON’T currently implement H.263, could/would you?

Quite clearly H.263 is not yet in the "so old it's as safe as it can 
get" realm, and the MPEG-4 visual patent pool lists numerous patents 
tagged as "H.263".

Of course, this does not necessarily mean that these patents read on the 
proposed H.263 baseline, but this is certainly difficult to assess 
without legal consultation. An interesting, if not conclusive, data 
point would be if those who deploy H.263 have a licensing agreement of 
any sorts in place.

Then again I wonder if the IPR-situation of H.263 (or MPEG-1 Part 2, or 
Theora, ...) can be simplified by mandating support only for 
Intra-frames (a decoder would be allowed, but not required, to skip 
decoding other frame types). This would mostly boil down to "mimick 
MJPEG", but with a clear upgrade path to "real video codec" for those 
who feel that the IPR situation for additional bitstream features is 
under control (by age of the codec, by IPR research, by licensing, ...).

Best regards,

Maik

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 04 Dec 2013 14:05:22 +0100

One interesting aspect of Motion JPEG is that several cameras implement 
it when they have enough resolution that naked YUV is going to overload 
the USB bus, but they don't want to spend the silicon (or licensing) to 
go all the way to real video codecs. So there are software decoder 
implementations around.

http://en.wikipedia.org/wiki/Motion_JPEG#Digital_cameras

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 5 Dec 2013 08:08:34 +1100

Such an "iframe"-only codec has interesting properties for seeking and
video analysis, too, so might even be of general interest as a supported
publishing format in the <video> element and certainly for recording.

Silvia.
On 5 Dec 2013 00:05, "Harald Alvestrand" <[email-masked]> wrote:

> it when they have enough resolution that naked YUV is going to overload the
> USB bus, but they don't want to spend the silicon (or licensing) to go all
> the way to real video codecs. So there are software decoder implementations
> around.
>
> On Dec 2, 2013, at 18:36 , Stephan Wenger <[email-masked]> <[email-masked]> wrote:
>
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 05 Dec 2013 18:07:51 -0500

> application of more bandwidth or by having teeny postage-stamp videos.

Agreed.  And prior experience with hardware videophones on DSL lines 
(128K max up) is that fuzzy is ok, even errors are ok (if recovery is 
fast), but framerate rules for user perception of conversation. QCIF 
30FPS @ 40-60Kbps was perceived by users as "better" than CIF @ 10fps @ 
150Kbps (more or less), though it has 1/2 -1/3 or less bits-per-pixel, 
so long as you don't scale up too far (scaled up to 70+% of a 7" LCD 
(~854x480ish) was ok, 3-4x scale).  That may be an extreme example, but 
you get the idea.

-- 
Randell Jesup -- rjesup a t mozilla d o t com