More issues with non-transcoding

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