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

[Gili <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb