Re: Review of use cases and requirements

Hi Guillaume,

On Wed, Nov 19, 2008 at 12:59 AM, Guillaume Olivrin
<golivrin@meraka.org.za> wrote:
>> In any case, I think this is academic and of little practical use. If
>> I see a media resource on the Web and want to address a time range
>> into it, I am not going to try and understand its physical encoding
>> packets/blocks just to find the closest keyframe to the time range I
>> am interested in. I cannot really see a practical use case in
>> addressing encoding units. But please correct me if I'm wrong.
> The main use case is to select time ranges and even space ranges as
> accurately as possible. I presume that if I ask a specific time range,
> what I would receive in return would always be some sort of a
> self-contained media fragment well rounded to the closest codec logical
> block.

Yes, that's true. It's the best we can do in a compressed world.

> So yes: we could overlook the whole packet/block business because
> we want high level usage and leave the work to the server and client to
> agree on something. On the other hand, the user, via the URL, might want
> a little bit more control over what he is asking for/retrieving. He
> might like to have a more determinist behaviour by linking right to the
> specific keyframe if he knows that's it's there in the media.

They could be used for tabbing/browsing through a large file. But I
think the user would generally not care where keyframes are situated -
he/she would just want some arbitrary landmarks to jump through - be
that time or keyframes or semantically created landmarks. I would
actually prefer if there was an authoring tool that could create cue
ranges by listing keyframes to the editor. The editor can then select
which keyframes actually have a semantic meaning.


> We don't want to bother with codec particularities but it may be good to
> recognise that all codecs tend to use blocks and that those constitute
> the more general self-contained units.

Absolutely. I believe it is the way in which Yves looks at units in a
web proxy's cache to allow it to do the 2-way caching approach. So,
yes, it has it's place.


>> This was more what I was talking about - apart from having
>> hierarchical subdivisions. I was simply talking about identifier of
>> time ranges - often related to e.g. a piece of text, such as a piece
>> of caption text that has an identifier. If this identifier was
>> "chaper_1_section_2_sentence_5", then my suggestion for addressing
>> that as above would be video?name=chaper_1_section_2_sentence_5
>> (however, using "segment" as parameter name is ok, too).
> Agree, this refers back to the earlier case of naming time ranges. The
> naming of time ranges may be made to occur as caption text and it would
> be desirable to address these (use them as some sort of anchors).

I agree, caption text can provide one kind of markers. Any other
textual annotation could, too. Not our mandate here though. All we can
do is to enable addressing of such "segments" if such naming exists.


Cheers,
Silvia.

Received on Tuesday, 18 November 2008 19:19:16 UTC