Transcoding (was: Action 53 - Check whether ffmpeg can be used from clipping and cropping)

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