Re: Review: Use Case & Requirements Draft

Well Silvia, It seems to me not a technical issue but sorts of political and
business issues in the market. Recomposition of fragmented pieces can be a
new media to the user, and that can make a new business model. In that
sense, presumably someone who have a copyright of each pieces will claim
their licence for the new media.

BTW, it is not scope of media-fragments WG though...

My 0.02 cents,


Daniel Park [at] Samsung Electronics


On Tue, Dec 16, 2008 at 4:27 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> 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,
> Silvia.
>