[X3D-Public] DASH-X3D new profile - Interoper abilitypoint
doug sanden
highaspirations at hotmail.com
Sat May 10 14:54:29 PDT 2014
Kostas,
Thanks for the detailed explanation. Some interesting possibilities we'll have to keep an eye on. Keep up the good work.
-Doug
________________________________
> From: kapekost at gmail.com
> Date: Sat, 10 May 2014 17:27:52 +0300
> Subject: Re: [X3D-Public] DASH-X3D new profile - Interoper abilitypoint
> To: highaspirations at hotmail.com
> CC: x3d-public at web3d.org
>
> Dear Sanded,
> I think we could include the .x3z format when it becomes web3d
> standard, it solves many problems regarding the X3D distribution. Your
> statements were reasonable and completely understood. Very interesting
> method to deliver a complete scene with all the required files (images
> etc). The local storage can also take place for browser players (using
> the HTML5 storage mechanism)
>
> Additionally, we could consider the BASEurl (or a new) element of the
> MPD file (manifest), as base url for the required files. Even better if
> a server side application could be used to generate the representations
> (Several quality instances). It could export the path for its resources
> (in the MPD file)--less work for the clients. The described layers of
> the MPD allow us to consider a 3D scene as a mixture of 3D objects, and
> split the references according to their resolution.
> The scenario with the proximity sensor may be included only if we have
> some information about the position of the object in our MPD file in
> each representation(calculate it during its generation process)
>
> The MPEG-DASH in our minipages is using a video element (texture), to
> provide adaptive smooth HD video stream in the 3D world.
> The streaming example on the other hand (websocket) triggers a web
> service to deliver the chunks which we also used for real-time chunking
> in a fast example which we did not conduct speed measurements yet.
> (this implementation runs for Indexed faces, and color vectors as
> texture). We need more research on the chunking algorithm.
>
> At this point I focus on a general description for the X3D in DASH for
> a simple scenario, with an existing repository of the multiple quality
> instances per model, for a scene. The proximity sensor as I searched
> quickly is not implemented in X3DOM and the player I was considering to
> provide (for the interoperability point (profile)) to the DASHif
> community is an extended DASH.js player for the web. To begin with ,
> we can calculate the available bandwidth, and/or make some assumptions
> using the FPS measurement from the X3DOM runtime... and help the
> browser keep a good FPS value using the proper models depending on each
> case. ..
>
>
>
>
> On Sat, May 10, 2014 at 4:21 PM, doug sanden
> <highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>>
> wrote:
> Kostas,
> freewrl implements .x3z using a common opensource C library minizip
> that just unzips the contents to a local folder, so freewrl can do what
> it normally does for local files. x3z isn't in the web3d standards
> (yet) - it's an experiment to see if 'bundling' catches on.
> OK I see the MPEG-DASH on your page
> www.medialab.teicrete.gr/index.php/minipages<http://www.medialab.teicrete.gr/index.php/minipages>
> I gather X3D-DASH is conceptually similar -smooth transition between
> resolutions- except for whole scenes, or parts of scenes?
> -Doug
> more..
>
> web3d ProximitySensor node
> www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/envsensor.html#ProximitySensor<http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/envsensor.html#ProximitySensor>
> in combination with a Switch node, can be used to switch between
> resolutions of parts-of-scene as the avatar approaches/recedes.
>
> more..
> .x3z was implemented in freewrl in 2013 -it's not part of any standard
> yet. When porting freewrl to Blackberry tablet, I noticed the tablet
> didn't use browser plugins. Instead it would download a file for you,
> to 'disk', and offer to open it with a standalone app. The problem was
> in the .x3d scene file if image urls were relative, then the app
> couldn't find them, because they weren't downloaded too, and -unlike a
> browser plugin- the app wasn't handed the absolute url of the scene
> file. Somewhere between downloading the file to local, and opening with
> an app the absolute url is lost. For example scene
> http://dug9.users.sourceforge.net/web3d/tests/26.x3d
> refers image resource:
> absolute
> url='http://dug9.users.sourceforge.net/web3d/tests/helpers/front.gif'
> relative url='helpers/front.gif'
> x3d allows for multiple urls
> multiple url='"helpers/front.gif'
> 'http://dug9.users.sourceforge.net/web3d/tests/helpers/front.gif'"
> so if the browser can't find one it can try another. But not everyone
> authors their scenes that way. It seemed like the Blackberry tablet
> would prefer to download a BLOB (Binary Large OBject) all in one shot.
> Which reminded me of GoogleEarth's .kmz zipped files. So I did the
> equivalent for x3d.
> For browsers to do this, have the browser register the mimetype for
> .x3z model/x3d+zip when installing. Then when opening the .x3z, use
> function library like minizip to open, and write all the files to a
> temporary folder on disk, and remember the folder and delete it when
> closing. Then open doc.x3d and all the urls are relative and all the
> files are local and relative.
>
> However if instead of downloading a BLOB/.x3z, a manifest was
> downloaded as file to local disk, and the app opened the manifest as a
> local file, and the manifest had absolute URLS to scene files, then the
> browser app could open the manifest and see the absolute part of the
> url, and before forgetting the absolute part it could concatonate the
> absolute part to all the relative image urls.
>
> So, much like we did with
> www.cloudvr.net/x3z.html<http://www.cloudvr.net/x3z.html> (implemented
> with node.js code on the server) there could be a web service that
> generates a manifest for a legacy .x3d file 'on the fly'.
> Perhaps there could be a web service that generates reduced resolution
> images and meshes/geometry/indexedfacesets on the fly, so a manifest
> can refer to different resolutions that don't yet exist, but will be
> created on demand by the web service on request.
>
>
>
>
> ________________________________
>> From: kapekost at gmail.com<mailto:kapekost at gmail.com>
>> Date: Sat, 10 May 2014 04:26:02 +0300
>> Subject: Re: [X3D-Public] DASH-X3D new profile - Interoper abilitypoint
>> To: highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>
>> CC: x3d-public at web3d.org<mailto:x3d-public at web3d.org>
>>
>> x3z seems to be interesting, we might include it in future
>> implementations, or as additional mime-type in the DASH
>> interoperability point. Are there any players supporting this format?
>> or the developer has to temporary download the zip, uncompress and then
>> give the sources to the player?
>>
>> In our example we focused more on the delivery protocols, and less on
>> chunking methods, for the partial streaming tests we used serial and
>> area short chunking mechanisms, generating autonomous chunks of indexes
>> and indexedFaceSet.
>>
>> Regarding the DASH Interoperability point: To begin with, we will
>> consider an existing repository with existing versions of a model in a
>> variety of qualities. (the file format can be described as a mime time
>> of the representation, and the chunking mechanism should inform the
>> client on how to dynamically compose the final model)
>>
>> The client will decide according to the available resources which chunk
>> will be requested, on a second pass the delivered (low quality) models
>> will be replaced with higher-quality ones (or a transformation -
>> morphing algorithm at this point would be interesting, sacrificing
>> hardware resources to minimize the network bandwidth demand) . The
>> replacing process has to be transparent to the user to maintain good
>> Quality of Experience (e.g. smooth interaction). In a future work we
>> might consider the significance of each model to prioritize the most
>> significant.
>>
>>
>> On Fri, May 9, 2014 at 10:13 PM, doug sanden
>>
> <highaspirations at hotmail.com<mailto:highaspirations at hotmail.com><mailto:highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>>>
>> wrote:
>> Kostas,
>>> http://www.medialab.teicrete.gr/index.php/minipages
>> Very interesting - I'll take a closer look.
>>
>> Q. what about the .x3z scene zipping
>> www.cloudvr.net<http://www.cloudvr.net><http://www.cloudvr.net>
>> which is like googleEarth .kmz - a doc.x3d in the root of a .zip file,
>> and /images subfolder - or other docx style resource bundling - does
>> that fit with the manifest and chunking methods you use, or does your
>> method replace/obsolete these bundling methods?
>> -Doug
>>
>>>
>>> Dear Sanden,
>>>
>>> The MPEG-DASH approach we are currently working on (for my master's
>>> dissertation) will present 3d models in several resolution instances
>>> and inspite of the BASEurl, the MPD will provide proper information for
>>> dynamic adaptation mechanisms to 3D players (browser-based or not). The
>>> content will be delivered and rendered client-side, as X3DOM originally
>>> works right now (and any other plug-in based player).
>>>
>>> ...
>>> The approach with html5 canvas and gesture messages to a remote
>>> renderer having sessions, is one of the implementations we performed
>>> using Java X3D player, during our research in a project we are working
>>> in collaboration with other departments, (i-promotion) (greek content
>>> description : http://www.ipromotion.gr/) . There is a lot of
>>> optimization needed for such an application to be published, the delay
>>> is almost unacceptable.
>>>
>>> There is a procedural streaming approach we tested and published in a
>>> minipage (during model loading you can navigate in the world).
>>> Utilizing Websockets, simple http requests and a batch request
>>> http://www.medialab.teicrete.gr/minipages/x3domstream/
>>>
>>> furthermore, if you are interested some of our research demos are here:
>>> http://www.medialab.teicrete.gr/index.php/minipages
>>>
>>>
>>>
>>> On Fri, May 9, 2014 at 8:57 PM, doug sanden
>>>
>>
> <highaspirations at hotmail.com<mailto:highaspirations at hotmail.com><mailto:highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>><mailto:highaspirations at hotmail.com<mailto:highaspirations at hotmail.com><mailto:highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>>>>
>>> wrote:
>>> Kostas,
>>> Not sure how you use DASH with x3d. What does it look like?
>>> -Doug
>>> more..
>>> I had an idea -and may get to it in the next year- for something I call
>>> 'Server-Side Rendering' or SSR for short. If you've got beautiful Crete
>>> 3D tourist scenery -in X3D format- and want web surfers to be able to
>>> go around in 3D -but without heavy-duty x3dom .js, and without plugins-
>>> then the idea is that the client swipes/drags a 2D Html5 canvas which
>>> causes a 3D grid of construction lines to be redrawn as if navigating
>>> through the grid in 3D. When they lift their finger/mouse button at the
>>> end of the swipe/drag, the cumulative navigation is sent to the server,
>>> which moves the avatar in the scene and renders the snapshot from the
>>> new viewpoint pose, and ajaxes the view back to the client.
>>> This would need an x3d renderer capable of holding session state -if
>>> the scene state is different for each user- or else passing back the
>>> cumulative navigation in a cookie or restful url after correcting for
>>> collision and gravity to the cumulative navigation.
>>> Perhaps DASH-X3D is something like that, except the client has no
>>> control over the path, and instead of ajaxing snapshots a movie-like
>>> MPEG stream is sent.
>>>
>>>
>>>>
>>>> to whom it may concern,
>>>>
>>>> In multimedia content laboratory of TEI of Crete, we are working on a
>>>> new profile/interoperability point, for 3D scenes delivery (X3D).
>>>> My first approach is based on ISO/IEC 23009-1.
>>>> I would kindly ask if anyone else is currently working on 3D scene
>>>> delivery for MPEG-DASH to contact me. Additionally, I would like more
>>>> information on how to describe a new interoperability point (the
>>>> documents which should be delivered for review according to
>>>> http://dashif.org/identifiers/how-to-register/ ).
>>>> Best Regards,
>>>>
>>>> --
>>>> Kostas
>>>>
>>>> Kapetanakis
>>>>
>>>>
>>>> Project coordinator - R&D
>>>> McLab - Informatics Engineering
>>>>
>>>> TEI of Crete
>>>>
>>>
>>>
>>>
>>> --
>>> Kostas
>>> Kapetanakis
>>
>>
>>
>>
>> --
>> Kostas Kapetanakis
>>
>> Project coordinator - R&D
>> McLab - Media Content Laboratory
>> Informatics Engineering
>>
>> TEI of Crete
>>
> www.medialab.teicrete.gr<http://www.medialab.teicrete.gr><http://www.medialab.teicrete.gr/>
>
>
>
>
> --
> Kostas Kapetanakis
>
> Project coordinator - R&D
> McLab - Media Content Laboratory
> Informatics Engineering
>
> TEI of Crete
> www.medialab.teicrete.gr<http://www.medialab.teicrete.gr/>
More information about the X3D-Public
mailing list