We're currently using the MediaElement.js HTML5 video player for site viewing on tablets and are using DFP to serve pre-rolls via VAST. The main parts of this works fine (playback, tracking of views and clicks), but we are encountering an issue where pre-rolls will not serve at all when frequency capping (i.e., max once per 5 minutes for each line item) is enabled for them in DFP. This does not appear to be specific to playback in tablet browsers (e.g., based on default cookie security settings), as testing in desktop browsers returns the same results. Has anyone else experienced a similar issue, and if so, what was done to resolve it? Thanks.
We were able to solve this by not pulling the DFP XML file directly, but by using the Google IMA HTML5 library to do so. As soon as we did this, frequency capping no longer became an issue.
Related
I running tests on Youtube with Selenium Webdriver Firefox and Chrome and i observed that Youtube not count views from automation browsers. They surrely have a bot detection sistem and somehow detect users who use webdriver.
In youtube live analytics I can see the country from which I accessing:
Also i tried without success this with Chrome
How they can detect someone using Webdriver and Chromedriver?
Thanks
In youtube's TOS they state any automated system running against the site as a violation in section 4H.
https://www.youtube.com/static?template=terms
I have a feeling they coded the detection of webdriver acting on youtube to prevent exactly this behavior from happening. Especially since having bots artificially increase views I am sure caused them a lot of trouble in the past.
I would suggest to try using IP Spoofing/proxing and change your IP address dynamically every time before launch your web driver. I guess they detect your machine's IP and doesn't increment the counter if trying to view same video multiple times, hope this can't be achieved even manually if you try. Google has million times better minds than us, they knew users would develop the scripts and increment the view counter and they can't pay for fake views as well, just my thoughts!
There is no Selenium detection on Youtube. You just need IPs that are good for YT. Big companies like Google, Amazon etc blacklist most data center IPs. There's no way for them to know you're using Selenium unless they use a system like Distil networks which tests many elements to obtain your browser fingerprint using machine learning to ban you over time. YT does not run distil or anything similar.
For the welcome screen of my app, we are trying to serve up a webpage in a webview that consists of a video and some text. (We want to go this route so that we could quickly update the welcome screen and test changes on the fly, versus having to submit and get approval each time.)
The video is only 8.6mB and is currently being played via HTML5 , hosted on an S3 and served via CloudFront. However, the playback still tends to be a bit choppy at times. Does anyone have any recommendations as to an optimal way to host and serve up the video to make it play smoothly? Are there any specific settings for the S3 or CloudFront anyone would recommend that could help?
Thanks in advance for any help anyone can provide.
The most common technique currently is to use ABR in parallel with a CDN to provide smooth playback.
ABR, Adaptive Bit Rate, involves making multiple copies of the video at different bit rates, from low to high and hosting these on the server.
The client receives an index file for the videos, e.g. an m3u8 manifest file, and then chooses the best bit rate for the current conditions to allow smooth playback without buffering.
If network conditions improve the client will 'step up' bit rates and if it gets worse it will 'step down' bit rates.
Typically a low or medium bit rate is chosen as the first one to allow quick and smooth start up.
You can see this effect on services like Netflix as they start up, and you can also see it on YouTube if you right click the video and select 'Stats for Nerds'.
Some links for ABR in AWS Elastic transcoding - you can set the bit rates you want, for e.g. see the note below from their FAQ re HLS jobs:
Specify that the transcoding job create a playlist that references the outputs. You should order your bit rates from lowest to highest, with the audio only stream last, since this order will be maintained in the generated playlist file. Once your transcoding job has completed, the output bucket will contain a proper arrangement of your master and individual M3U8 playlists, and MPEG-2 TS media stream fragments.
Take a look at the sample request on this page here which includes two different bit rates (video service providers will generally have more than 2 but this gives you a feel for the approach):
http://docs.aws.amazon.com/elastictranscoder/latest/developerguide/create-job.html
Azure Media Services has a built in "Adaptive Streaming" preset that is content-adaptive and can adjust the encoding settings to meet your content that is coming in.
See the following - https://learn.microsoft.com/en-us/azure/media-services/media-services-autogen-bitrate-ladder-with-mes
I have developed a site that hosts user videos. I store the video files in AWS S3, I deliver them through AWS Cloudfront and I use video.js as the site's player with HTML5 as default and flash as fallback.
Generally the video streaming seems to work fine but in some cases I receive complaints from users for slow or choppy video playback. I want to create some tests to measure the performance of streaming in order to be able to distinguish user problems (e.g. slow connection at the user side) or with my service.
Are there any best practices or tools to collect video delivery metrics? I'm interested in open source solutions or something that I can implement myself because it's just a personal project, but I don't want to rediscover the wheel.
Testing progressive download implies checking the transmission bandwidth and its continuity. For example for a high transmission rate the initial client buffer will be filled faster and the playback will start sooner. However, losing that transmission capacity at some later time can cause re-buffering. The total transmission time of your file must be lower than the video duration.
To identify potential issues you can start with the S3 bucket logs and the CloudFront cache statistics and access logs.
There's a load testing tool written in Java called Apache JMeter. It cannot use JavaScript so it must be configured to request the files directly.
The disadvantage of using a load test tool in a single location is pretty evident. Different geographical areas and carriers have different characteristics and test results will be different.
There are online, non open-source tools that can load test from multiple locations but they are generally paid though some offer free trials.
Here's another way to look at this.
but in some cases I receive complaints from users for slow or choppy video playback.
If you're using an Adaptive HLS stream, and you're CloudFront, and the video is still choppy to some users, that's probably because of their own internet connection speeds.
In that case, you can encode your video in multiple resolutions (using just one AWS MediaConvert job, btw) - like 1080p, 720p, 360p, 240p, 144p etc.
And then Videojs has a stream switcher plugin that will 1) automatically start playing the highest possible resolution - and no higher - that's right for the viewer's connection and 2) give the user the option via a "Settings" (gear) icon in the control bar that they can use to switch resolutions manually.
That way, even those with really poor internet connections should be able to watch your video.
Of course, the other alternative is to use progressive download videos that the viewer can simply click play, then immediately click pause, and wait for the video to buffer, and then play it after it's fully downloaded.
Check out the Videojs Resolution Switcher demo here.
-- Ravi Jayagopal
Trying to roll out a video to a client with limited bandwidth. The client is concerned that the video will eat up all the bandwidth at their field office. In testing, I've discovered that even though my video is encoded at 420kbps, when downloading the client it still utilizes about 1.5mbps. Is there a way to control the maximum bandwidth used by video.js or the video tag?
Unfortunately no. The html5 video element doesn't have any throttling options. It's completely up to the browser to decide how to fetch the video data. Some will download the whole thing at once, others will download pieces as you need them. All I think will use as much of the pipe as you give them.
The media source extensions proposal hopes to add some ability here, but that won't be available for a while.
I would find somewhere else besides the office to host the video, like Amazon S3.
I've finished writing my first Sencha app and released it in Android market place. This is basically for a conference being held in Metro Detroit Area next week. I'm also introducing Sencha in my company as a viable mobile option.
However once released into the market, it does not seem to load on certain devices. How to find out what is wrong on the device? It works great on desk top and also on certain android phones and nexus pad but does not load ( the user keeps seeing the loading page for ever) in certain other phones. I would like to know how to debug this issue? Does Sencha log the console log exceptions in logcat? Any help in this direction is highly
appreciated!
I'm using Internet permissions to access twitter feed and google maps. Kind of guessing that the issue could be because of accessing Internet but how to find that out?
Thanks
From experience, this is generally due to javascript errors before sencha has been properly set up. This can be missing functionality or include issues, picky parsers etc. There is no real good way to debug this more than to get ahold of an affected device and set window.error = alert before any other javascript is run.