Re: Review: Use Case & Requirements Draft

It is indeed a legal and business issue - I thought I made that clear
in my reply, but obivously didn't. :)

Cheers,
Silvia.

On Wed, Dec 17, 2008 at 1:43 PM, Daniel Park <soohongp@gmail.com> wrote:
> 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 07:53:14 UTC