- From: Daniel Park <soohongp@gmail.com>
- Date: Wed, 17 Dec 2008 11:43:16 +0900
- To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "Davy Van Deursen" <davy.vandeursen@ugent.be>, "Media Fragment" <public-media-fragment@w3.org>
- Message-ID: <f7c7d76e0812161843u5d2910cfia42565317af4bbd2@mail.gmail.com>
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. >
Received on Wednesday, 17 December 2008 02:43:57 UTC