Once the video has been uplaoded to vimeo, how do i know that processing has been completed through API. So that i can embed the video into Iframe?
The API representation of a video contains a field, status. This field will contain a string representing the status of the video. It can be one of the following
available
uploading
transcoding
quota_exceeded (can not play because the quota was exceeded before uploading this video)
uploading_error
transcoding_error
So if you request https://api.vimeo.com/me/videos, each video will contain the status field with one of the above values.
Send a HEAD request to the {upload.upload_link} URL in the returned payload.
and you set these headers
Tus-Resumable: 1.0.0
Accept: application/vnd.vimeo.*+json;version=3.4
Find below link to there documentation usage.
https://developer.vimeo.com/api/upload/videos#resumable-approach
The response returns the HTTP 200 status code and the Upload-Length and Upload-Offset headers, among others. Determine the completeness of the upload by comparing the values of Upload-Length and Upload-Offset:
If Upload-Length and Upload-Offset are equal, we've received the entire video file.
If Upload-Length is larger than Upload-Offset, we haven't.
Related
Response time for web steps (of a web scenario) indicates the time that it takes to load since the request is done until the HTTP code is received (200,302,404, etc) or until all the content is loaded? (images, css, javascripts, etc).
According to the docs: "Response time is counted from the beginning of the request until all information has been transferred." But "information" includes linked content??
Thanks!
Just the page content is evaluated: the HTML body, not the linked content. It's the same time it would take curl or wget to download the page, without recursive options.
I have uploaded an mp4 video animation to Azure Blob Storage. The headers are are all default apart from setting the Content-Type to video/mp4. The video can be accessed at http://paddingtondev.blob.core.windows.net/media/1001/animation_default_headers.mp4
I have an Azure CDN sitting over that blob storage account. The URL for the same video through the CDN is http://az593791.vo.msecnd.net/media/1001/animation_default_headers.mp4
When I access the blob-stored video through an HTML5 video element on a web page, the browser (have tested in FF and Chrome) receives the entire video in a 200 HTTP response. Further requests for that video then receive a 304 response from blob storage.
However, when you request the video through the Azure CDN, it helpfully returns it to you as a series of HTTP 206 partial responses. This is in response to the browsers specifying a Range header with the request.
However, further requests for the video through the CDN are NOT cached, and the whole video is re-downloaded by the browser (through a series of further 206 requests).
How do I ensure the video is cached? I understand the usefulness of partial responses, but in our case the video won't be seekable and we only play it when the whole file is downloaded. I can see a few approaches here, but none have helped so far:
Forbid Azure CDN from returning partial responses
Remove range header from original browser request somehow
Persuade browsers to cache 206 partial responses
I have tried adding a max-age Cache-Control header to the file but this had no impact. Ideally we wouldn't even hit Azure at all when re-loading the video (as it will never change), but I'm happy to accept the cost of the HTTP request to Azure if it subsequently returns a 304 .
Caching 206 responses is tricky. The RFC for the client requires that in order to cache the content the ETAG and the range requested must match exactly.
There are a couple of things you can check -
1) Verify that the ETAGS did not change on the request. From the description of your environment (and setting the content expiration date), this sounds unlikely, but it may be an avenue to pursue.
2) More likely is that the range requests are not lining up. A request for byte range 1000-->2000 and a second request of 1500-->2000 would not (per RFC) be served from the client cache. So you may be in a situation of seeing exactly what is supposed to happen with that particular format/client.
I'm pretty sure HTML5 only supports progressive download, so unless you wanted to reconsider the delivery this may be expected behavior.
I am trying to check the data loading into search listing in this page link below :
http://www.tigerdirectwireless.com/ecommerce/phones/?r=tigerdirect&filterbycarrier=68
We could not find the product details(name, price etc.) in page source. I have inspected in both Charles and Fiddler , but not able to view a log of any http request or response for this data.
Even after saving a complete webpage will not not download the listing products details, nor HTTrack Website Copier we help us identifying this.
We actually want the know the link from where this response data in generating in text/markup format.
Thanks Guys.
The data is sent back in JSON and the page is built up dynamically using JavaScript. For instance http://www.tigerdirectwireless.com/eCommerce/Service/CoreServicesProxy.asmx/GetPartnerPhoneList is the JSON response that contains the list of phones and details, while http://www.tigerdirectwireless.com/eCommerce/Service/CoreServicesProxy.asmx/GetPartnerPricedPhoneList contains the phones and prices.
In the context of HTML5 audio, if the server is sent a request with the following header:
Range:bytes=0-
Will responding with
Content-Range: bytes 0-499/1234
Be handled correctly by all modern browsers? When byte[500] is needed, will the browser automatically know to request the next chunk? Am I interpreting the following spec correctly?
If all of the preconditions are true, the server supports the Range
header field for the target resource, and the specified range(s) are
valid and satisfiable (as defined in Section 2.1), the server SHOULD
send a 206 (Partial Content) response with a payload containing one
or more partial representations that correspond to the satisfiable
ranges requested, as defined in Section 4.
I've been reading from the following spec: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p5-range-22
If that request was generated internally by the browser by assigning the src attribute of an audio of video tag, then yes, the media element knows how to handle byte range requests and make subsequent requests for the next segments. No additional logic needed.
It sounds like you're interpreting the spec correctly. However, examples of ServiceWorkers responding to Range Requests suggests that the expected response to open-ended requests like 0- is the entire byte range. Browsers then stream the response up to some heuristic, and if the user seeks to a range outside of what has been streamed the initiate a subsequent open-ended request.
In order words, if there's a file with 1000 bytes: the first request is always Range: bytes=0-. The browser decides to load 100 bytes. The user seeks toward the end, and the browser sends another request Range: bytes=900-.
I've actually never seen instances where browsers request explicit, closed ranges like Range: bytes=0-100. They also don't seem to use the range size, i.e. 1234 in Content-Range: bytes 0-499/1234. I'm guessing this is because some servers may send * for files of unknown duration (or continuous, real-time playback).
Word of caution: this is based on my observations, predominantly of Firefox, Chrome, and iOS Safari. Behavior may vary based on browser vendor, version, etc.
Im wondering if there is anyway to get scores from a gamecast that uses javascript or flash to update the content dynamically. Here's an example: http://www.cstv.com/gametracker/launch/gt_wlacros.html?sport=wlacros&camefrom=&startschool=md&event=952412&school=cs&
How could I pull the scores from the teams out of this page?
Really what you need to do is sniff the requests being made under the hood. You can get any sort of HTTP sniffer. I use Live HTTP Headers extension for firefox. You start capturing, then click the link above. You'll see all sorts of requests. The underlying data seems to be coming from http://origin.livestats.www.cstv.com. I got this request that has a lot of useful player stats from the game:
http://origin.livestats.www.cstv.com/livestats/data/w-lacros/952412/player_stats.xml?344026907808
http://origin.livestats.www.cstv.com/livestats/data/w-lacros/952412/summary.xml?644493847800
(note the second url throws an XML parse error, but you could still try to parse it manually)