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.

http://wiki.xiph.org/OggSkeleton

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

Conrad.
Received on Thursday, 26 March 2009 01:47:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:32 GMT