W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2009

RE: More issues with non-transcoding

From: Davy Van Deursen <Davy.VanDeursen@ugent.be>
Date: Thu, 26 Mar 2009 08:41:58 +0100
To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc: "'Media Fragment'" <public-media-fragment@w3.org>, "'Jack Jansen'" <Jack.Jansen@cwi.nl>
Message-ID: <DAE406E937A247CB9F45D34BBAD5291E@elis.UGent.be>
Hi Silvia,

>-----Original Message-----
>From: public-media-fragment-request@w3.org [mailto:public-media-fragment-
>request@w3.org] On Behalf Of Silvia Pfeiffer
>Sent: donderdag 26 maart 2009 8:24
>To: Jack Jansen
>Cc: Media Fragment
>Subject: Re: More issues with non-transcoding
>On Thu, Mar 26, 2009 at 9:54 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>> I spent most of the evening battling ffmpeg to get it to do what I want,
>> with only limited success. I can get it to leave the data intact (by
>> the "copy" codecs), but the command line utility will always muck up the
>> timestamps. This is solvable, but it would involve creating a new
>> application (ffclip?) to do exactly what I want.
>> But in the process I have learned something interesting. ("interesting"
>> used here in the same sense as in the Chinese curse "may you live in
>> interesting times!":-).
>> If our original media is well-behaved and has both audio and video
>> at exactly the same timestamp, and we disallow transcoding we lose this
>> property.
>> Our audio packets will, in general, not have the same timestamps as our
>> video packets, so the resulting fragment has audio and video starting at
>> different times. This is not only a burden on the playback implementation
>> (which isn't all that much of a burden: it'll probably have audio resync
>> code anyway), but it also means that in our HTTP extension we cannot use
>> single timestamp to denote the start (or end) of our fragment: the audio
>> video stream will have slightly different start timestamps.
>What codecs/encapsulation formats did you try this with?
>These issues are indeed issues that we solved in Annodex/Xiph with a
>lot of discussion and thinking.
>Apparently, there are other codec/encapsulation format combinations
>than ogg that are also capable of doing the fragment delivery. At
>least Flash is capable of it - otherwise the hosting services would
>not provide it.
>I think the problem that you're seeing is not a problem to be solved
>by a hack to ffmpeg, but rather through working with the encapsulation
>format providers to see how best to solve it for the particular
>OTOH, it seems that Davy has a solution, which I am looking forward to
>seeing. :)

I'm afraid I have to disappoint you at this point :-(. We do have an
adaptation and delivery solution, but our platform itself does not solve the
above described problem, it rather relies on the capabilities of the
delivery formats to handle this issue... Note that you can already test this
platform at [1], but the demo only works on Internet Explorer (we only got
the combination of Silverlight and VLC working on IE). The web page as it is
today is also a bit outdated, since we already have a new version of our
platform and a new client application. An update is coming soon. I will give
a technical explanation of the platform during the F2F.

Best regards,


[1] http://multimedialab.elis.ugent.be/NinSuna 

Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems Multimedia Lab
URL: http://multimedialab.elis.ugent.be
Received on Thursday, 26 March 2009 07:42:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:42 UTC