- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 7 Apr 2009 08:30:01 -0400 (EDT)
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- cc: Davy Van Deursen <Davy.VanDeursen@ugent.be>, Jack Jansen <Jack.Jansen@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
On Sat, 28 Mar 2009, Silvia Pfeiffer wrote:
>> I agree with Davy: I don't think ffmpeg will do fragmented versions
>> from the original file, but I expect it to rather create transcoded
>> versions from it. This will be a problem when we get to caching, since
>> there will be very little if any overlap between the original file and
>> the newly created one which claims to be a fragment of the original
From RFC3986:
<<
3.5. Fragment
The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource defined or described by those representations.
>>
"some view on representations of the primary resource" seems to allow
transcoding. In the case of transcoding, there won't be any emrge possible
in a cache, but it is not always desirable to do so anyway (as it may
require more work than just retrieving the whole resource than doing all
the merge work, especially if the cache is on a fat pipe).
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Tuesday, 7 April 2009 12:30:11 UTC