W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2010

[whatwg] What is not possible with HTML5

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 8 Jun 2010 08:42:09 +1000
Message-ID: <AANLkTikbaxWGWw1l0fwlN81rPzBTI58Fj-DVkOBiRtHQ@mail.gmail.com>
I think what you call "multi-format video" is being implemented as
HTTP adaptive streaming, where you have multiple different
bandwidth-versions of the same media resource on the server and they
have synchronisation points (usually the keyframes of the video) at
which the user agent can switch over from one resource to another
using byte range requests depending on the user agent's situation.

I still wonder whether we should standardise HTTP adaptive streaming
across video formats here or somewhere else. At this moment, several
different solutions exist for MPEG video and none for Ogg or WebM.

Cheers,
Silvia,


On Tue, Jun 8, 2010 at 1:18 AM, Bruce de Graaf <WeBMartians at verizon.net> wrote:
> 3D Video and Real-time Multi-format Video! Ooops... My "bad." It doesn't
> seem feasible even outside of HTML!
>
> Apologies for being facetious and trying to be a "wag," but that latter
> point (multi-format video) is a good candidate for attention ... and that is
> what the query (What is not possible with HTML5) is about, right? "To what
> have we failed to pay due consideration?"
>
> A Statement of the Problem (apologies aforehand for offensive terminology):
> Real-time, multi-format video (there must be a better term for this) is the
> acquisition of audio and video in one form (say, 1920 x 1080 with 7.1 sound)
> and its propagation in native as well as other formats (say, 160 x 112 with
> monaural sound). This is the "Fat Man's Trousers" problem - How do you stuff
> that belly into such small pants? [and THAT is the most polite of the
> various titles] Right now, with either H.264 or with Ogg, no matter which,
> this task is Sysiphean. Simply put, it is the difficulty in cramming 8+ Mb/s
> through a 300 kb/s pipe (to a display that cannot present, anyway, the high
> resolution image) and then randomly "adjusting" the bandwidth. Think of
> being in a car, watching an iPad (as a passenger, we hope and pray) and
> trying to watch a video as the feed wobbles from several megabits to mere
> kilobits per second and back again. ...and then being foolish enough to
> recommend the video to an iPhone user...
>
> Just recode ... on-the-fly? Oh, you have not begun to address the problems!
> You see, when your feed collapses, your clients lose compression
> synchronization: compressed audio and video that depend on a particular
> client state must be halted until some form of re-atunment occurs ...
> possibly several seconds (hopefully not minutes). ...not good in a
> commercial environment (somebody's not getting that for which he/she is
> paying...).
>
> There have been related discussions (focused on reporting actual bandwidth)
> on this forum about the challenges. Some have said, with good reason, that
> it is outside of the HTML5 envelope. Yet, the current need is so great and
> that need's growth is of such magnitude (it could reach, quickly, the major
> portion of all traffic) as to warrant some cycles in its discussion.
>
> ...and, not to complicate and confuse matters, deserving of attention is an
> analogous problem with mere layout of HTML pages: view a commercial page
> (say, Bloomberg or Der Spiegel) on a decently sized screen and then try to
> view such pages on an iPhone or Droid ... not a pleasant experience. Whilst
> not dynamic as the described media feed problem is, the difficulties are
> analogous (again, even if "spatial rather than temporal"). If the
> documentation could offer some guidance, it would be well received and yield
> great returns.
>
> What say ye?
> ===
> On 2010-06-07 10:01, Nikita Eelen wrote:
>
> I believe video telephony is not possible due to security limitations in
> browser, but it was in spec but never acted upon as of yet (IE device access
> using something like a microphone/camera etc.), however i believe this is
> possible to work around (with individual browser extensions, like firefox
> extensions, or
> a native plugin (flash comes to mind but sucks for mobile devices in terms
> of battery life), so I think for all those as of now need to be written as
> either
> A.) An application that acts as a plugin (ex: Flash)
> B.) An extension to a browser (Firefox extension/active x control etc.)
> C.) A native application that reads the camera/microphone for a given device
> when the above is not possible (Ex: iPhone/iPad),
> if this is possible any other ways I would be very interested if anyone
> could comment,
> Thanks,
> Nikita
>
> On Mon, Jun 7, 2010 at 5:34 AM, narendra sisodiya
> <narendra at narendrasisodiya.com> wrote:
>>
>> May someone explore what is not possible with HTML5 in spec and in
>> Implementations
>> For example video telephony in browser is possible ? we draft DAP spec but
>> no implementations. So not possible at this moment.
>>
>>
>> --
>> ???????????????????????????
>> ? ? ?Narendra Sisodiya
>> ? ? ?http://narendrasisodiya.com
>> ???????????????????????????
>
>
>
> --
> Nikita Eelen
> Network Manager
>
> AVE INTERVISION LLC
> 6 4 0 West State Street
> Alliance, Ohio 4 4 6 0 1
>
> Office: 330-821-7117 ?ext. 108
> Cell: 330-257-9647
> email: neelen at amvonet.com
>
>
Received on Monday, 7 June 2010 15:42:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC