[whatwg] More YouTube response

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

Received on Tuesday, 6 July 2010 07:12:53 UTC