Re: [rtcweb] H261/MPEG-1 video quality

Gili <cowwoc@bbs.darktech.org> Thu, 14 November 2013 20:31 UTC

Return-Path: <cowwoc@bbs.darktech.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9811E810D for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 12:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.48
X-Spam-Level:
X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60yQxVGsUjjY for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 12:31:45 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B267011E8119 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 12:31:45 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id to1so3596759ieb.3 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 12:31:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lr70W2kR2XHLZ6nPGmptjLuA46VoNJ36/tjofEua5yg=; b=JscXDOrVB2oF96VdyIeC+uRXlJ5BHS/Fgbt8AATrtNK6H0IeWz1SabioYRxn/xtvqL +uiH8CZE0rwiBEfuZ1gXFjLM0Dr/Lta7Gy63yhEp6TE7O8uKzgjx6g9WzOkZ3kQ0NYyD 9i+Gve5XT5OwbQqXRC7EdYq08P3+DnT2+8381AKlIEqF/0Yyk9y/U26DpUz9H7Hu4YlP 1wjzA74qrvr4MwfDPMKkN5S7lBbSskMzDr1L9/cNp/c8QsLyBuDzFZ0mjhImlqoGM4jF G3DAuEV5gLmDIpsSvPwYxJdQJWMPDxo2mN7UetnKQPWhUSpYM//vwt7kvL+NhMRxnjZb ExVA==
X-Gm-Message-State: ALoCoQk1VcXHfugoOuQwEKYSznnT5Wsrg7z5Npz1vNWQ8/miReC9g4k9SGbFxPgSl2bYW5WQrmhc
X-Received: by 10.50.4.35 with SMTP id h3mr2619311igh.19.1384461105137; Thu, 14 Nov 2013 12:31:45 -0800 (PST)
Received: from [192.168.42.220] (out-pq-194.wireless.telus.com. [216.218.29.194]) by mx.google.com with ESMTPSA id j16sm38792429igf.6.2013.11.14.12.31.43 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 12:31:44 -0800 (PST)
Message-ID: <52853325.5030805@bbs.darktech.org>
Date: Thu, 14 Nov 2013 15:31:33 -0500
From: Gili <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com> <CAGgHUiSROwRznKZWD4kjn8Vu7SrUVwOnHN1EJ-PTgR=WQmcxAQ@mail.gmail.com> <52852910.9090508@bbs.darktech.org> <52852A67.2090008@googlemail.com>
In-Reply-To: <52852A67.2090008@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2013 20:31:50 -0000

In that case, excellent point :)

Gili

On 14/11/2013 2:54 PM, Maik Merten wrote:
> I included the JavaScript MPEG decoder so that people can have a quick 
> look. I don't propose that videos should be decoded in JavaScript for 
> WebRTC. If anything this merely demonstrates that old codecs have low 
> processing requirements (duh!).
>
> Maik
>
> Am 14.11.2013 20:48, schrieb Gili:
>>
>> Just a reminder: Native applications don't necessarily have access to
>> Javascript (they're running outside of a browser) so a Javascript-based
>> solution sounds problematic to me. Everything we need should be
>> accessible from WebRTC's Native API. If that happens to include a
>> Javascript engine under the hood, so be it, but I just want to make sure
>> this is understood.
>>
>> Thanks,
>> Gili
>>
>> On 14/11/2013 2:35 PM, Leon Geyser wrote:
>>> >>This includes a completely JavaScript-based MPEG-1 player for those
>>> that don't happen to have a fitting decoder installed >>(also, yay,
>>> JavaScript is fast enough now for simple video decoders!). I recreated
>>> the encoded files to ensure there are no >>b-frames and documented the
>>> encoder settings accordingly.
>>> Thanks for sharing. Looks better than what I expected.
>>>
>>> On 14 November 2013 21:12, Maik Merten <maikmerten@googlemail.com
>>> <mailto:maikmerten@googlemail.com>> wrote:
>>>
>>>     Hello again,
>>>
>>>     to allow for having a quick look at some test sequences I put
>>>     together a very very sloppy overview page at
>>>
>>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html
>>>
>>>
>>>     This includes a completely JavaScript-based MPEG-1 player for
>>>     those that don't happen to have a fitting decoder installed (also,
>>>     yay, JavaScript is fast enough now for simple video decoders!). I
>>>     recreated the encoded files to ensure there are no b-frames and
>>>     documented the encoder settings accordingly.
>>>
>>>     Best regards,
>>>
>>>     Maik
>>>
>>>
>>>     Am 14.11.2013 11:52, schrieb Maik Merten:
>>>
>>>         Hello all,
>>>
>>>         in
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html
>>>         a
>>>         sample of H.261 video was provided, connected to a 
>>> (rhetorical?)
>>>         question if this provided quality would be acceptable for
>>>         users. Clearly
>>>         that provided sample is of very low and unacceptable quality.
>>>
>>>         Just for comparison, here are two CIF samples at roughly 256k
>>>         created by
>>>         a somewhat modern encoder (ffmpeg with rate/distortion
>>>         optimization):
>>>
>>>
>>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg
>>>
>>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg
>>>
>>>
>>>         (encoded as MPEG-1 video, as the "h261" encoder in ffmpeg
>>>         crashes when
>>>         using rate/distortion optimization. I understand MPEG-1 if
>>>         used without
>>>         b-frames is similar to H.261 in coding efficiency, but mostly
>>>         adds more
>>>         flexibility regarding frame sizes.
>>>
>>>         ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd
>>>         -trellis 2 -cmp
>>>         2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )
>>>
>>>         Even without formal testing it is obvious that H.261 and/or
>>>         MPEG-1 video
>>>         is clearly outperformed in terms of coding efficiency by H.264
>>>         and VP8.
>>>         However, personally, speaking as an end-user, I would very
>>>         much prefer
>>>         this video quality over audio-only calls (in cases where
>>>         transcoding is
>>>         not available), as the video produced still carries useful
>>>         information.
>>>         Also H.261/MPEG-1 is blazingly fast, can be dealt with in
>>>         software, and
>>>         is not exceedingly difficult to implement.
>>>
>>>         Of course a MTI codec with higher coding performance is much
>>>         preferable.
>>>         However, if no such high-performance codec with licensing
>>>         terms that are
>>>         acceptable for all communities can be agreed on I think it may
>>>         be wise
>>>         to seriously evaluate the option of implementing an outdated
>>>         codec for
>>>         the sake of interoperability. In practice, most calls will
>>>         negotiate to
>>>         H.264 and VP8 anyways, but sporadic negotiation failures 
>>> that are
>>>         difficult to account for by the user are still to be expected
>>>         if no MTI
>>>         codec is defined at all.
>>>
>>>
>>>
>>>         Best regards,
>>>
>>>         Maik
>>>
>>>
>>>     _______________________________________________
>>>     rtcweb mailing list
>>>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb