W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2008

Re: Review: Use Case & Requirements Draft

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 16 Dec 2008 18:27:59 +1100
Message-ID: <2c0e02830812152327j4e016c7et703de75822fb6d6e@mail.gmail.com>
To: "Daniel Park" <soohongp@gmail.com>
Cc: "Davy Van Deursen" <davy.vandeursen@ugent.be>, "Media Fragment" <public-media-fragment@w3.org>

On Tue, Dec 16, 2008 at 6:13 PM, Daniel Park <soohongp@gmail.com> wrote:
>> >>> * Section 1.4:
>> >>>  - This use case is again for me an application of 1.1, that is this
>> >>time
>> >>> linking for recomposing (making playlist)
>> >>
>> >>Recompositing poses very different challenges to an application that
>> >>just playback. I can see where you come from - for you it is just a
>> >>piece of content delivered to a user agent and you don't really care
>> >>what the user agent does with it. However, I am looking at use cases
>> >>from the user's POV. A user would not regard watching a video as the
>> >>same use case as editing clips together. I am just weary that we might
>> >>oversee some things if we throw these use cases together too much.
>> >
>> > Note that there is another issue with the recomposition of media
>> > fragments.
>> > For instance, consider scenario 3 where video fragments (possibly all
>> > having
>> > different parent media resources) are put together. Since different
>> > parent
>> > resources implies potentially different underlying media formats, things
>> > become complicated if we expect a smooth playback of a mashup of media
>> > fragments. This is because different underlying media formats require
>> > the
>> > (re-)initialization of the decoder(s) during playback of the mashup.
>> > Therefore, I think we should make clear that in this scenario, we do not
>> > expect smooth transitions between the different media fragments in the
>> > playlist, because otherwise, this use case is far from trivial to
>> > implement.
> I've read this UC&Req. document and looks good to me. Particularly, Section
> 1.4 is a close related to my research in conjunction with IPTV business. I
> am saying this UC as *storytelling*. There are lots of widely spreaded
> pieces on the web, and if we can recomposit them into one media to be palyed
> on TV screen, that would be good for IPTV viewers since IPTV viewers fully
> make sense to watch out these long video in their living room. Merging those
> fragments media allow me to make a entirely new media to IPTV users. If it
> can play very smoothly, it's also great of course.
> One concern in my mind is how to deal with copyright of each fragment. If I
> missed this threads, I am sorry about that...:-)

No you haven't missed anything. Copyright is a legal matter that may
disallow you from doing what a technology like media fragment URIs
enables you to do. It is something that has to be dealt with at a
different level - maybe through metadata attached to the media
fragments or provided on the original publishing site of the video.
With the media fragment URI spec at least you can make sure that the
metadata of a video is not removed or disconnected, since the URI is
continuing to point to the original data and not to a copy of it that
may have had copyright information stripped. It is certainly not
something we should need to deal with in media fragments WG, IMHO.

Best Regards,
Received on Tuesday, 16 December 2008 07:28:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:41 UTC