Re: More issues with non-transcoding

Dear Jack,
   I think what you're requesting is that the fragment shall point to  
a random access point (RAP) and if not possible, playback shall start  
at the next random access point. Per definition a RAP should allow the  
synchronized playback of the media resource at the given timestamp.

Best regards,
  -Christian

On Mar 25, 2009, at 11:54 PM, Jack Jansen 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.
> --
> Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma  
> Goldman
>
>
>