- From: Jack Jansen <Jack.Jansen@cwi.nl>
- Date: Wed, 25 Mar 2009 21:41:46 +0100
- To: Davy Van Deursen <davy.vandeursen@ugent.be>
- Cc: "'Media Fragment'" <public-media-fragment@w3.org>
- Message-Id: <118D4684-ACF8-493D-8C06-B928FBE6BBE7@cwi.nl>
On 25-Mar-2009, at 17:14 , Davy Van Deursen wrote: > Hi Jack, > > very interesting! However, other issues/thoughts I can imagine: > - spatial cropping is obtained by transcoding the media files, but > (lossy) > transcoding is not allowed to extract media fragments > - is there any transcoding involved in case of temporal cropping? In > other > words, does ffmpeg look for the closest previous intra coded frame > (i.e., no > transcoding) or does it create an intra coded frame from the current > frame > (i.e., transcoding)? Interesting... Apparently we have a different view the "no transcoding" statement. I had interpreted it as "we will not standardise any type of fragmenting that we think cannot be implemented without using transcoding". You seem to interpret it as "an implementation is not allowed to do any transcoding". I could go both ways on this. There's definitely advantages to disallowing transcoding, because it means we can guarantee lossless recombination. OTOH, using transcoding as a last-ditch approach, especially client-side, is convenient for end-users (or, probably, end- user-application programmers). As a thought experiment, let's assume a boundary case: a 1-hour video that has an I-frame at the beginning, an I-frame at the end and only B- frames in between. If I ask for a 10-second fragment in the middle, what would the original server send to a caching server? Always the full video? What would a media API deliver to the end-user application? The full video? The requested 10 seconds, with synthetic I-frames at both ends and original B-frames in between? What would an application like curl or wget store on the users' local disk? -- 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 20:42:33 UTC