W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2009

More issues with non-transcoding

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Wed, 25 Mar 2009 23:54:24 +0100
Message-Id: <FB36C014-7438-409F-BD59-B7BF4116A341@cwi.nl>
To: Media Fragment <public-media-fragment@w3.org>
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
Received on Wednesday, 25 March 2009 22:55:05 GMT

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