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

ISSUE-6: Temporal clips that require transcoding

From: Media Fragments Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Tue, 7 Apr 2009 14:35:11 +0000 (GMT)
To: public-media-fragment@w3.org
Message-Id: <20090407143511.D76E46B62C@kent.w3.org>

ISSUE-6: Temporal clips that require transcoding


Raised by: Jack Jansen
On product: 

Not all temporal clippings are representable exactly without transcoding the original  media. I think original media come in three flavors:

1. For some container formats (such as Ogg with Ogg Skeleton) there is no issue: the container allows encoding the finer-granularity clipping and synchronisation. 

2. Other container formats are at the other end of the spectrum: there is no way we can address a certain point in time  consistently for all tracks. These formats will always require transcoding (or we must say that MF cannot be used to clip these formats).

3. Some container formats are at the half-way point: they have the concept of Random Access Points, and these are the only points in time where you can seek (or clip) with the knowledge that you're at an I-frame and with audio/video in sync.

We need to come up with some general rules for what is allowed:
- can an implementation do transcoding?
- are there situations where transcoding is forbidden?
- are there situations where transcoding is required?

It may be good enough to define two parameters: MAX_OFFSET and MAX_SYNC_ERROR. MAX_OFFSET would define the maximum difference between the requested point in time and the actual point in time (with the actual always being before the requested for clipbegin, and after it for clipend).
MAX_SYNC_ERROR would define the maximum inter-stream synchronisation error introduced by the fragmenting.

With these two parameters we could then state that if a non-transcoded fragment is possible that fits the parameters transcoding is not allowed, and if such a fragment is not possible transcoding is required.

But: it may be that we want to treat things differently server-side (where the results could be cached by an intermediate caching server) and client-side (where the results will be directly user-visible).
Received on Tuesday, 7 April 2009 14:35:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:42 UTC