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

Re: More issues with non-transcoding

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 26 Mar 2009 18:23:59 +1100
Message-ID: <2c0e02830903260023l13d21cd5y19f94b87069cfc61@mail.gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>
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 using
> 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" is
> 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 starting
> 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 a
> single timestamp to denote the start (or end) of our fragment: the audio and
> 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. :)

Received on Thursday, 26 March 2009 07:24:53 UTC

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