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

Re: More issues with non-transcoding

From: Conrad Parker <conrad@metadecks.org>
Date: Thu, 26 Mar 2009 10:46:51 +0900
Message-ID: <dba6c0830903251846q3450cc7fn8032404c3eeb7d0c@mail.gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>
2009/3/26 Jack Jansen <Jack.Jansen@cwi.nl>:
> 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.

yes, that's why we developed Ogg Skeleton, which ffmpeg does not yet support.


The problem generalizes to different codecs. For Ogg, we have already
solved the start/end timestamps and the HTTP details in the Annodex

Received on Thursday, 26 March 2009 01:47:31 UTC

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