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 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
format.

OTOH, it seems that Davy has a solution, which I am looking forward to
seeing. :)

Cheers,
Silvia.

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