[whatwg] More YouTube response
Philip Jägenstedt
philipj at opera.com
Tue Jul 6 07:12:53 PDT 2010
On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson
<marques at displague.com> wrote:
> On Mon, Jul 5, 2010 at 10:25 PM, Henri Sivonen <hsivonen at iki.fi> wrote:
>
>> On Jul 5, 2010, at 13:10, Marques Johansson wrote:
>>
>> > For the content that is not protected the download or stream is
>> metered
>> so the client can be charged only for the time they spent watching the
>> content. We error on the customer's side for things like buffering and
>> misreported play segments.
>>
>> There'd be no problem if you were selling content by title (plus free
>> trailer for sampling) instead of selling it by minute.
>
>
> If a user is paying for bandwidth why should they need to pay for a
> download
> of the full movie when they are only interested in a few scenes or a few
> key
> seconds of the video.
>
> A friend of mine called this weekend to confirm that a scene in Back to
> the
> Future 3 that has been popping up online was actually in the movie and
> not
> just some Internet hoax. He called to have me watch a particular
> segment on
> the DVD. I watched all of 3 minutes of the movie to confirm the original
> scene contents. Doc Brown's young blond haired train companion (who only
> appears at the end of the movie) displays a very preverse set of
> gestures in
> his 10 seconds of screen time that should have been edited out (I dodged
> all
> spoilers). There is a market for this kind of viewing habit that does
> not
> insist on the consumer purchasing a full right/license to the entire
> video
> nor the bandwidth or storage to accommodate it.
>
> When you are selling adult content - many users are much happier to pay
> for
> a few minutes of content that they seek through rather than a full movie
> that they will have little interest in watching again. The difference
> can
> easily be $.16 versus $16. As for trailers, many of our plans include
> additional time and all users that have ever purchased get 3 free 30
> second
> plays weekly. That being said, I don't think the business models of one
> of
> the largest online video markets should put be on trial through a by a
> standards list.
>
>> I think the discussion that DRM is irrelevant has its merits, but the
>> contracts and services at play have a real value regardless of how
>> distribution is restricted.
>>
>> I think the technology providers shouldn't feel an obligation to cater
>> to
>> particular contract models--especially when it complicates the
>> technology.
>> It makes more sense to draft contracts that are reasonable given the
>> technology. (An example of a contract that I think technology providers
>> shouldn't attempt to cater for is a content licensing contract that
>> tries to
>> distinguish between desktops, mobile devices and TVs. Such a contract
>> makes
>> no sense when devices of any kind can support the same standards.)
>
>
> I think providers cater to the technology that's available. At the time
> these contracts were drawn up Windows Media player and Real were leading
> the
> streaming video market. The contracts and services in place now were
> created pre-Youtube, when most users accessed the site with a 56 modem or
> less. The service was geared toward online streaming and streaming
> rentals
> rather than downloads - which could take some users days to complete - or
> longer when coupled with bad re-try behaviors in browsers. Cell phones
> couldn't play let alone download a video over their 14kbps connection.
>
>
>> > For my purposes I am interested in application-controlled video
>> delivery.
>> I want to be able to deliver unprotected mp4, webm, or ogv content in a
>> metered way. If the user has payed to watch the entire video once and
>> has
>> managed to work around HTTP no-cache and the other constraints that a
>> normal
>> browser viewed experience would have, then they will have succeeding in
>> downloading a copy of the video - a task which they could have
>> accomplished
>> with a VM session or through other means regardless of DRM.
>>
>> If the customers pay for seeing an entire title, why is it a problem if
>> a
>> customer once in a while downloads the bytes twice? Surely it is
>> simpler to
>> bake the average bandwidth cost into the price and not complicate the
>> way
>> the delivery technology behaves.
>
>
> We have different plans available. Some allow a user to stream a chosen
> video as often as they want. There are plans that allow users to stream
> an
> entire studios selection of videos on demand. This likens the service
> to a
> monthly membership site and the company I work for has found that many
> users
> prefer to not have that sort of commitment - preferring instead to pay
> for
> what they watch when they watch it. The choice is determined by the
> content
> provider and the user - we accomodate both parties to the best of our
> ability.
>
>
>> > These requests can be seen as generally allowing servers to reduce
>> load
>> for video or large file downloads. Since a client may be able to
>> download 5
>> minutes of video in under a minute I would like to see the client
>> disconnect
>> from the server and reconnect in 5 minutes to get the additional
>> content.
>>
>> Wouldn't this be a non-problem if the customers paid by title? In that
>> case, it would seem pointless to worry about the content getting
>> downloaded
>> faster than it is played.
>>
>> It seems to me that your problem is picking a pricing model that's
>> unnatural for the technology.
>
>
> Partial requests are native to HTTP and seeking is natural for a healthy
> streamed viewing habit - I'm look for a way to get the browser to take
> the
> servers recommendation that the content be fetched in a particular way -
> we
> have content negotiation of transfer encoding and image quality, why not
> allow the server to negotiate the transfer size for the benefit of the
> user
> and the server?
Is preload="none" not enough? I can't imagine the actual bandwidth savings
of more fine-grained control to be significant, probably any attempt by
the browser to stop buffering after some time is good enough.
--
Philip Jägenstedt
Core Developer
Opera Software
More information about the whatwg
mailing list