Re: More issues with non-transcoding

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 UTC