Re: [rtcweb] Alternative decision process in RTCWeb

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

On 12/04/2013 02:25 AM, David Singer wrote:
> On Dec 2, 2013, at 18:36 , Stephan Wenger <stewe@stewe.org> wrote:
>
>> 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.
> 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.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb