YouTube App: Microsoft got the blame for Google's actions .

[eugie]

It is because Google want to have Google search engine built on windowsphone not just bing on search button options.. That's Google act like that but it's not a big problem..

 

[SlimAndShady]

Delete your Gmail, don't use google search, g+, YouTube, Google maps. Boycott google NOW!

 

[Lurchorama]

The relevant difference is that Chrome for Android and Safari iOS can support HTML5. WP cannot.

Yes, but Google isnt *making* them use it.
Thats the difference.

 

[dang121]

Quote Originally Posted by Lurchorama View Post

More correctly:

"We're gonna make you re-create your app for our service in HTML5 even though we know your platform is not ready for it AND we're not making anyone else do it"
"Well, thats a bit unfair"
"Stiff s**t"
"How long we got?"
"Yesterday"
"Well, thats REALLY unfair"
<insert evil laugh here>

Again I reiterate: Google does not screw with Metrotube or other 3rd party providers. I am unsure why nobody considers that fact. This means to me that Google does not want to deny WP users, just that they want MS to play by the rules. And the fact that the platform is not ready, after TWO years, is whose fault?

Google doesn't have a history of going after small developers.

There's a difference between a third party app which doesn't use the service's real name, made by an indie somewhere, and an app that looks like and claims to be an Official app made by a company like Microsoft. That is important.

So in previous post you claim that there is third party app that exist and it play by Google rule and Google just want MS to play by the rule. In another post people pointed out that all third party app does not play by the rule. And you come back with "but it ok because Google does not goes after small developers". How do you change your story so fast or you just forgot your argument and everything is MS fault.

 

[ImmortalWarrior]

You're completely wrong. The HTML5 API does all this with zero effort. You're just another MS apologist with no understanding of the technical issues here.

Completely wrong. Doubt it. Technically I could explain in detail, right down the the HTTP 1.1 or 2.0 transport protocol but it's inconsequential.

Fact - the HTML 5 video standard does not include considerations for client side control of advertisements.

Fact - advertisements can be made to work in HTML from the server side.

Fact - advertisements can be handled by an app - native or HTML 5 - on the client side IF an API is provided to pull the ad videos. The client can then run the ads first.

I am not familiar with the YouTube public API. However, my point is this:

If a public API is available to get advertisements for video requests then why did Microsoft raise a stink about not having access to it? There are only these options for this situation:

1.) The public API does NOT include a means to access content aware advertisements. If this is the case, Google would have to provide Private API access. If Google has provided this private API access for others and not for MS then Google is unnecessarily making this out to be a big deal. They have every right to withhold the private API access, but they shouldn't be whining if they are.

2.) The public API does include a means to access content aware advertisements. If this is the case, Microsoft is incompetent and/or deliberately causing drama at the expense of their customers.

I seriously doubt it's number 2.

EDIT: I took the liberty of reading the Javascript and IFrame players APIs Google provides for YouTube. The Javascript API is specific to embedded Flash so the IFrame API is what we are looking for.

Nowhere in the IFrame API documentation does it specify anything about advertisements, nor does it bother to include any sort of code reference on how to include or call up advertisements. The documentation shows that you are using the API to call up the video feed. That's it. This exactly supports what I previously stated.

However, I know that won't be enough for you. So I dug some more. I know from experience in client server systems that, if the video stream is not made to include the add in the same stream from the server side, then the API must provide a way to respond to asynchronously posted information from the server. If it does, I can imagine a way in might allow the user to respond and display the appropriate advertisement prior to playing the requested video stream.

I found something that the API uses that is close to that, but not the same. From the documentation:

"The end user must be using a browser that supports the HTML5 postMessage feature. Most modern browsers support postMessage, though Internet Explorer 7 does not support it."

HTML5 postMessage allows cross domain posts from IFrames. Cool. I can see how they might use that, but there is no end user code for them to use this it seems. It appears to be simply required by the embedded player for the browser. Unrelated to the ads it seems.

So onward to addEventListener. If a message comes from the server to display an add there must be an event listener for it.

https://developers.google.com/youtube/iframe_api_reference#Events

None of those are related to advertisements. So we find ourselves back where I said we were in the first place. There is no client side control for advertisements in the public API. If I missed something, please feel free to check it yourself.

Also, try to know what you are talking about before attempting to insult me.

 

[ag1986]

Ah. Apologies for my tone.

There is no need for client-side control for an ad to be played; have you seen Youtube ads playing before videos embedded on random third-party sites? This is basically the same thing. The app needs to include an HTML5 iframe within itself - the app can be on whatever framework you like. The request for a given video is passed to YT, and that is all the information they need - the ad is streamed followed by the video. Playing the app within the HTML5 iframe is what is essential. Try viewing an embedded HTML5 vid in IE on WP - it launches the native media player to handle the stream because IE is not capable of playing the video inline. The same would happen with an embedded iframe in an otherwise-native app. Verification:

""There is also an inherent behavior of Windows Phone where playback of an HTML5 video through a web page opens the built-in media player to host the video,"" -- Michael Choeung, Metrotube dev. Inside the bitter YouTube battle between Microsoft and Google | The Verge

So. Google would definitely be able to serve ads to WP devices, but that is it. No other data about that ad view because the native player, unlike an HTML5 frame, is not capable of reporting any other data to Google. That's a problem because of the nature of Google's video ad offerings.

They sell something called Trueview Instream, where if you skip the ad, the advertiser doesn't pay anything. If the ad is >30s long, that is. That's why the Skip Ad button on YT ads exists. They can't do this in the native player.

Next up, Google reports not just number of times that video ad was viewed, but also percentage duration it was played. That is, it was played to 0-25% n0 times, 25-50% n1 times and so on. Again, native player does not report this and they are contractually bound to report this.

These are the reasons why I believe that the problems with YT arise from a problem with WP8.

 

[ImmortalWarrior]

Makes sense, and thank you for the extra details.

I understand the issue from Google's perspective, but there is one issue in regards to their demand for HTML5. The HTML5 video standard has no considerations for advertisements. Essentially, Google uses other HTML 5 features ("post message") and JavaScript to relay that information back to them. Neither MS nor Google have done anything wrong with their use of HTML 5 but the choices MS made make it so that client side metrics cannot be transmitted to Google.

From Google's perspective, if they provided API capabilities for this, a native app could be made to send these metrics.

Anyways, I suppose the point is that Google is making MS's choice for a better mobile video experience look like an intentional attempt to circumvent ads, and MS is right to bite back.

On a side note, I've seen ads in my html5 videos from cbcnews on my Windows Phone. So it's entirely possible. Google is just mad that they can't get the metrics they want.

 

[ag1986]

Makes sense, and thank you for the extra details.

I understand the issue from Google's perspective, but there is one issue in regards to their demand for HTML5. The HTML5 video standard has no considerations for advertisements. Essentially, Google uses other HTML 5 features ("post message") and JavaScript to relay that information back to them. Neither MS nor Google have done anything wrong with their use of HTML 5 but the choices MS made make it so that client side metrics cannot be transmitted to Google.

From Google's perspective, if they provided API capabilities for this, a native app could be made to send these metrics.

Anyways, I suppose the point is that Google is making MS's choice for a better mobile video experience look like an intentional attempt to circumvent ads, and MS is right to bite back.

On a side note, I've seen ads in my html5 videos from cbcnews on my Windows Phone. So it's entirely possible. Google is just mad that they can't get the metrics they want.

Yup, and they do have contractual obligations to report those numbers back to whoever's paying. More important IMHO is that the content creators will not be paid their share if TrueView skip metrics especially are not reported correctly.

I agree that this is a hack to get around HTML5's limitations on Google's part, but the lack of inline video in IE is also an issue MS should fix. I would not call it an intentional attempt to circumvent ads too, but I was disgusted that they made it look as if the entire issue was Google's fault, that's all. This kind of slimy tactic is what makes me not want to use MS.

CBCnews possibly doesn't use Google's video ads system, so that's not truly related to the issue at hand.

One last question - how do you think this improves the mobile video experience? I really haven't used my NL920 much for video so I'm not sure.

 

[ImmortalWarrior]

One last question - how do you think this improves the mobile video experience? I really haven't used my NL920 much for video so I'm not sure.

I think the ability to have the videos all managed through the native WP8 player improves the experience. Videos can't auto run for instance and you will never get stuck with that webpage that has a hidden video playing.

However, it would be nice to have the option to play in-line as well.